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

SYMPTOMS

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.

RESOLUTION

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.

MORE INFORMATION

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.