KB2448971 - FIX: The locks of a table are not escalated when you insert many rows into a table in SQL Server 2008 or in SQL Server 2008 R2

Symptoms

Consider the following scenario:

• You insert many rows into a table in Microsoft SQL Server 2008 or in SQL Server 2008 R2 by using one of the following queries:

  • INSERT INTO <target_table> SELECT * FROM <target_table> WHERE <predicate>

  • SELECT * INTO <target_table> FROM <source_table> WHERE <predicate>

  Notes
  

  • The <target_table> placeholder represents the actual target table name.

  • The <predicate> placeholder represents the actual predicate.

  • The <source_table> placeholder represents the actual source table.

• The lock escalation threshold of the table is exceeded.

In this scenario, the database engine does not escalate the locks of the table.

Cause

This issue occurs because SQL Server does not internally count all the new locks that are generated by INSERT operations. Therefore, the lock escalation threshold might not be triggered when it is required.

Resolution

Status

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 SQL Server 2008 Service Pack 2 for SQL Server 2008.
This problem was first corrected in SQL Server 2008 R2 Service Pack 1 for SQL Server 2008 R2.

More Information

For more information about lock escalation, visit the following Microsoft TechNet website:

General information about lock escalationTo determine whether the locks of a table are escalated, run the following Transact-SQL statements:

USE tempdb
GO

CREATE TABLE x 
(
i INT NOT NULL PRIMARY KEY
)
GO

BEGIN TRAN
INSERT x
SELECT TOP (40000)
ROW_NUMBER() OVER 
(
ORDER BY (SELECT NULL)
) AS r
FROM 
master..spt_values a, 
master..spt_values b
ORDER BY
r

SELECT
COUNT(*)
FROM sys.dm_tran_locks
WHERE 
request_session_id = @@SPID 
ROLLBACK
GO

DROP TABLE x 

If the locks of the table are escalated, the last SELECT statement returns a value of either 1 or 2. If the locks of the table are not escalated, the last SELECT statement returns a value of either 40,066 or 40,067.