This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 362939 (SHILOH_BUGS)
SQL Profiler or SQL Server Performance Monitor may report many extent lock time-outs, possibly exceeding several hundred thousand time-outs per second, if all the following conditions are true:
A query performs an operation that requires a large amount of space to be allocated, such as SELECT INTO, INSERT..SELECT, CREATE INDEX, or DBREINDEX.
The allocation occurs in a filegroup that contains at least two files.
An active transaction has deallocated many extents in the files, and the number of deallocated extents is large compared to the remaining free space.
In extreme cases, the lock time-outs may continue for several minutes, CPU utilization may be very high, and the routine that is performing the allocation is very slow.
Service pack information
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 How to obtain the latest SQL Server 2000 service pack
The English version of this fix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
Note Because of file dependencies, the most recent hotfix or feature that contains these files may also contain additional files.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.This problem was first corrected in Microsoft SQL Server 2000 Service Pack 4.
To see the number of extent lock time-outs that are occurring on the system, monitor the SQL Server:Locks object in SQL Server Performance Monitor. Select the Lock Timeouts/sec counter and the Extent instance. Alternatively, SQL Profiler reports the time-outs by using the Lock:Timeout event type with the BinaryData column containing the lock resource type.
When a filegroup in a database has at least two data files, SQL Server uses a proportional fill algorithm that tries to keep approximately the same percentage of space used from each file. It periodically recalculates the free space in the file to determine how frequently to try an allocation from a specific file. This free space calculation looks at the status of a bit in the GAM page. However, when an extent is deallocated, the bit is cleared in the GAM but the extent is not actually available for reuse until the transaction commits. An extent lock is held to make sure that other processes do not reuse the space. If another process tries to allocate space, it must confirm that the bit is cleared and that the extent can be locked.
If one transaction has deallocated many extents and leaves the transaction open, the proportional fill recalculation incorrectly calculates that one file has more space that it actually does. Because of this, it tries to do more allocations from that file. When the file is actually full, these searches may try to take out thousands of extent locks only to find no space. It may try to search this file many times, depending on the proportional fill ratio at the time, before it returns to the other files that do have space.
The process of indexing (DBREINDEX or CREATE INDEX WITH DROP_EXISTING) a table with clustered and nonclustered indexes can cause this problem independent of any other activity on the system. This problem occurs because the operation is one large internal transaction that may deallocate the extents from the clustered index after it is rebuilt, and yet there may be a lot of additional space that is required to rebuild the nonclustered indexes.