The information in this article applies to:
BUG #: NT: 16936 (6.50) SYMPTOMS
Joins via a dynamic cursor may execute considerably slower than the same
query would when run using a different type of cursor, or if run outside of
a cursor.
CAUSEThe optimizer is failing to properly analyze the cost of the various join possibilities when choosing a query plan. The resulting plan may be different from what would be picked if the same query were executed outside of the cursor, or if executed using a different type of cursor. WORKAROUNDUse a different type of cursor, such as a keyset cursor. If possible, consider changing the process to not use a cursor, as set operations are typically much faster than using any type of cursor. STATUSMicrosoft has confirmed this to be a problem in Microsoft SQL Server version 6.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available. MORE INFORMATION
If you evaluate the showplan output, a dynamic cursor will print out two
different query plans. The first plan is displayed when the cursor is
declared, the second plan at the first FETCH. The second plan is the one
used to perform the query. If the query plan from these two outputs is
different, you may experience the slow performance possible with this bug.
Additional query words: upgrade performance slow
Keywords : SSrvTran_SQL kbbug6.50 |
Last Reviewed: April 10, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |