Article ID: 293166 - View products that this article applies to.
This article was previously published under Q293166
BUG #: 352297 (SHILOH_bugs)
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.
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:
(http://support.microsoft.com/kb/290211/EN-US/ )INF: How to Obtain the Latest SQL Server 2000 Service Pack
HotfixNOTE: 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:
NOTE: Due to file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.
Version File name ------------------------- 8.00.261 s80261i.exe
To workaround this issue either:
Microsoft has confirmed that this is a problem in Microsoft SQL Server 2000. This problem was first corrected in SQL Server 2000 Service Pack 1.
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.