This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 354751 (SHILOH_BUGS)
Multiple processor SQL Server installations that run with Address Windowing Extensions (AWE) enabled, may experience Latch Timeout warnings, 845 errors and slow response time. The error messages that may occur include:
2001-06-28 13:12:17.62 spid92 Time out occurred while waiting for buffer latch type 4, bp 0x1c69dfc0, page 6:24196), stat 0xb, object ID 2:3:1, EC 0x3AB69570 : 0, waittime 300. Not continuing to wait.
2001-06-28 14:24:16.95 spid6 Error: 845, Severity: 17, State: 12001-06-28 14:24:16.95 spid6 Time-out occurred while waiting for buffer latch type 1 for page (27:124576), database ID 7..
A SQL Server worker thread encounters a non-yielding loop condition, which leads to worker thread starvation conditions.
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 theMicrosoft Knowledge Base:
290211 INF: How to Obtain the Latest SQL Server 2000 Service Pack
NOTE: The following hotfix was created prior to Microsoft SQL Server 2000 Service Pack 2.
The English version of this fix should have the following file attributes or later:
File name Platform ------------------------ S80414i.exe Intel
NOTE: Due to file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.
If possible, avoid the use of AWE for SQL Server purposes until you can obtain the correction.
Microsoft has confirmed this to be a problem in SQL Server 2000. This problem was first corrected in Microsoft SQL Server 2000 Service Pack 2.
The condition corrected by this build of SQL Server is extremely rare. For the problem to occur you must have a multiple processor computer cause a simultaneous collision on a given procedure cache page allocation by separate threads. At the same time, the computer also must require AWE umap/map activities while traversing a data chain, and the thread that eventually results on the CPU spin must be assigned to the same UMS Scheduler.
NOTE: The following DBCC command (DBCC STACKDUMP)is unsupported, and may cause unexpected behavior. Microsoft cannot guarantee that you can solve problems that result from the incorrect use of this DBCC command. Use this DBCC command at your own risk. This DBCC command may not be available in future versions of SQL Server. For a list of the supported DBCC commands, see the "DBCC" topic in the Transact-SQL Reference section of SQL Server Books Online.
To identify if you are encountering the problem, execute the following script: