FIX: Parallel Modification Operation May Spin Trying to Release Locks (293166)

SYMPTOMS

A parallel query that performs a modification operation (INSERT, DELETE or UPDATE), which also undergoes lock escalation during the transaction, may spin when it tries to release some locks at the end of the statement. The server process ID (spid) shows that the query is in a rollback state, and it consumes all of the CPU on the processor where it is running. The spid does not respond to the Transact-SQL KILL command or to a query timeout. The query never completes, and the SQL Server server must be stopped to resolve the problem.

RESOLUTION

To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

290211 INF: How to Obtain the Latest SQL Server 2000 Service Pack

Hotfix

NOTE: The following hotfix was created prior to Microsoft SQL Server 2000 Service Pack 1.

The English version of this fix should have the following file attributes or later:

   Version      File name   
   -------------------------

   8.00.261     s80261i.exe

NOTE: Due to file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.

WORKAROUND

To workaround this issue either:

Disable parallel queries by setting the max degree of parallelism option to 1.

-or-
Use a query hint OPTION (MAXDOP 1) in the affected query.

MORE INFORMATION

You can use SQL Profiler to determine whether a query runs in parallel and whether lock escalation occurs. To watch for parallelism, watch the Execution Plan or Showplan statistics events under the Performance event class. For lock escalation, monitor the Lock:Escalation event under the Locks event class. There are also Degree of Parallelism events under the Performance event class to monitor for parallel queries.