After a dump of the stack for all threads, the server initiates a shutdown of the SQL Server process.
A race condition occurs where multiple threads involved in the parallel query may try to unlock the same resource. After the first thread successfully frees the lock, other threads encounter error 1203, but are unprepared to handle this. A default error handler within the server causes the process to exit.
You can prevent a parallel plan by setting the "max degree of parallelism" option in sp_configure to a value of one. Even if there are available CPU resources, the query is processed serially.
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 3 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
274799 INF: How to Obtain Service Pack 3 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0
For more information, contact your primary support provider.
Parallel queries are only considered when there are one or more idle processors available to SQL Server. On a heavily used system, the optimizer should not choose a parallel plan for any queries.
Setting the "max degree of parallelism" to force a serial plan may cause some performance degradation, but only during those periods of time when the number of simultaneous connections running queries is less than the number of available processors, and those queries would otherwise be eligible for a parallel plan.
SQL Profiler can be used to determine what queries are using a parallel plan. The "Event Sub Class" column for the DELETE, INSERT, SELECT and UPDATE operators shows the degree of parallelism used. To monitor lock escalation, add the Lock Escalation event to your trace. Note that this event is only listed when you go to the Tools menu, choose Options, and then select All event classes.