FIX: SH_PAGE Lock Not Released After Fetch Operation on Keyset Cursor (245552)

SYMPTOMS

When fetching a row from a keyset-driven server side cursor, this operation may leave a SH_PAGE lock on a data page of the base table of the cursor, which does not get released until this client session terminates.

CAUSE

A keyset-driven cursor maintains a worktable containing the row ID (RID) of all qualifying rows. Whenever a row from the keyset is fetched, a SH_PAGE lock is being acquired on the data page identified by the pertaining RID and the page is read from disk. If the row has moved after populating the keyset upon cursor open (for example, by a page split), the row will not be found on this page and therefore an index-based scan must be performed on the table to find the page holding the row. Again, a SH_PAGE lock has to be acquired on this new data page. After the fetch operation has returned the row to the client, the SH_PAGE lock on the new page is being released, but not the one on the page scanned in the first step.

For additional information on how a keyset-driven cursor works, click the article number below to view the article in the Microsoft Knowledge Base:

168678 INF: Understanding Worktables Used by Server Side Cursors

STATUS

Microsoft has confirmed this to be a problem in SQL Server version 6.5. This problem has been corrected in the Post Service Pack 5a Update for Microsoft SQL Server version 6.5. To install the Post Service Pack 5a Update, you must have either SQL Server 6.5 SP5 or SP5a installed.

For information about how to download and install the SQL Server 6.5 Service Pack 5a, refer to the following article in the Microsoft Knowledge Base:

197177 INF: How to Obtain SQL Server 6.5 Service Pack 5a

If you already have SQL Server 6.5 SP5 or SP5a installed, you can download the Post SP5a Update from the following article in the Microsoft Knowledge Base:

274036 INF: How to Obtain SQL Server 6.5 Post Service Pack 5a Update

For more information, contact your primary support provider.