FIX: Many Extent Lock Time-outs May Occur During Extent Allocation

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

Hotfix information

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.
   Date         Time   Version            Size    File name   -------------------------------------------------------------------   24-Jan-2003  18:53  2000.80.732.0      29,244  Dbmslpcn.dll        18-Jan-2003  02:23                    786,432  Distmdl.ldf   18-Jan-2003  02:23                  2,359,296  Distmdl.mdf   11-Dec-2002  17:50                        180  Drop_repl_hotfix.sql   02-Jul-2002  15:35  2000.80.650.0     107,088  Impprov.dll         17-Jan-2003  20:33                    774,409  Instdist.sql   11-Dec-2002  17:50                      1,402  Inst_repl_hotfix.sql   20-Aug-2002  16:24  2000.80.679.0     111,172  Logread.exe         15-Dec-2002  23:21  2000.80.717.0      90,692  Msgprox.dll         05-Mar-2003  18:17  2000.80.736.0      62,024  Odsole70.dll        03-Jan-2002  01:59                     18,185  Qfe356326.sql   20-Aug-2002  16:47  2000.80.679.0     135,748  Qrdrsvc.exe         26-Aug-2002  22:49  2000.80.679.0     406,088  Rdistcom.dll        04-Oct-2001  01:36                    437,302  Replcom.sql   20-Aug-2002  16:33  2000.80.679.0     152,136  Replmerg.exe        25-Nov-2002  21:43                  1,004,990  Replmerg.sql   15-Dec-2002  23:21  2000.80.717.0     221,768  Replprov.dll        15-Dec-2002  23:21  2000.80.717.0     303,688  Replrec.dll         22-Jan-2003  19:27                  1,002,101  Replsys.sql   04-Oct-2001  01:36                    881,228  Repltran.sql   26-Aug-2002  22:49  2000.80.679.0     283,208  Rinitcom.dll        16-Sep-2002  22:31                    390,045  Securityhotfix.sql   26-Aug-2002  22:49  2000.80.679.0      28,672  Sqlagent.dll        26-Aug-2002  18:39  2000.80.679.0     311,872  Sqlagent.exe        28-Aug-2002  16:32  2000.80.679.0      49,152  Sqlagent.rll   26-Aug-2002  22:49  2000.80.679.0      53,824  Sqlcmdss.dll        28-Aug-2002  16:40  2000.80.679.0      12,288  Sqlcmdss.rll   14-Jan-2003  21:39  2000.80.725.0     172,600  Sqlmap70.dll        03-Apr-2003  02:42  2000.80.741.0   7,483,473  Sqlservr.exe        01-Nov-2002  18:56  2000.80.698.0      45,644  Sqlvdi.dll          24-Jan-2003  18:53  2000.80.732.0      29,244  Ssmslpcn.dll        24-Jan-2003  18:53  2000.80.732.0      82,492  Ssnetlib.dll        02-Jan-2003  20:12  2000.80.722.0      25,148  Ssnmpn70.dll        07-Apr-2002  02:08  2000.80.606.0      70,208  Xplog70.dll         07-Apr-2002  02:08  2000.80.606.0      53,828  Xpqueue.dll         07-Apr-2002  02:08  2000.80.606.0     156,228  Xprepl.dll          12-Jul-2002  01:00  2000.80.658.0     279,104  Xpstar.dll          16-Sep-2002  23:12  2000.80.686.0      98,872  Xpweb70.dll
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.

Article ID: 818096 - Last Review: 02/27/2014 21:18:27 - Revision: 10.2

Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2000 Personal Edition, Microsoft SQL Server 2000, Workgroup Edition, Microsoft SQL Server 2000 Desktop Engine (Windows), Microsoft SQL Server 2000 Enterprise Edition 64-bit

  • kbnosurvey kbarchive kbqfe kbsqlserv2000presp4fix kbfix kbbug KB818096