sql-server - 为什么我的 SQL Server UPSERT 代码有时不会阻塞？

Question

我有一张 table ImportSourceMetadata我用它来控制导入批处理过程。它包含一个 PK 列 SourceId和数据列 LastCheckpoint 。导入批处理读取 LastCheckpoint对于给定的SourceId ，执行一些逻辑(在其他表上)，然后更新 LastCheckpoint为此SourceId 或者如果尚不存在则将其插入。

进程的多个实例同时运行，通常带有析取 SourceIds ，并且我需要这些情况的高度并行性。但是，可能会发生两个进程针对同一个 SourceId 启动的情况。 ;在这种情况下，我需要实例相互阻止。

因此，我的代码如下所示:

BEGIN TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT LastCheckpoint FROM ImportSourceMetadata WITH (UPDLOCK) WHERE SourceId = 'Source'

-- Perform some processing

-- UPSERT: if the SELECT above yielded no value, then
INSERT INTO ImportSourceMetadata(SourceId, LastCheckpoint) VALUES ('Source', '2013-12-21')
-- otherwise, we'd do this: UPDATE ImportSourceMetadata SET LastCheckpoint = '2013-12-21' WHERE SourceId = 'Source'

COMMIT TRAN

我正在使用事务来实现原子性，但我只能使用 READ COMMITTED 隔离级别(因为“执行某些处理” block 中的并行性要求)。因此(为了避免死锁)，我在 SELECT 语句中包含了 UPDLOCK 提示，以实现在 SourceId 上参数化的“关键部分”。值。

现在，这在大多数情况下都工作得很好，但是当我为同一个 SourceId 启动大量并行进程时，我已经成功地使用 INSERT 语句触发了主键冲突错误。与一个空的数据库。然而，我无法可靠地重现这一点，而且我不明白为什么它不起作用。

我在互联网上找到了提示(例如 here 和 here, in a comment )，我需要指定 WITH (UPDLOCK,HOLDLOCK) (分别为 WITH (UPDLOCK,SERIALIZABLE) )而不是仅仅在 SELECT 上使用 UPDLOCK，但我真的不明白为什么会这样。 MSDN 文档 say ,

UPDLOCK
Specifies that update locks are to be taken and held until the transaction completes.

在事务完成之前获取并保持的更新锁应该足以阻止后续的插入，事实上，当我在 SQL Server Management Studio 中尝试它时，它确实阻止了我的插入。然而，在某些罕见的情况下，它似乎突然不再起作用了。

那么，到底为什么 UPDLOCK 不够，为什么在我的 99% 的测试运行中(以及在 SQL Server Management Studio 中模拟它时)它足够了？

更新:我现在发现，通过在 SQL Server Management Studio 的两个不同窗口中同时执行上述代码(直到 INSERT 之前)，我可以可靠地重现非阻塞行为，但是 < em>仅在创建数据库后第一次。之后(即使我删除了ImportSourceMetadata表的内容)，SELECT WITH (UPDLOCK)确实会阻塞并且代码不再失败。事实上，在 sys.dm_tran_locks ，我可以看到即使该行在后续测试运行中不存在，但在创建表后的第一次运行中不存在，也可以看到 U 锁被采用。

这是一个完整的示例，显示“新创建的表”和“旧表”之间的锁差异:

DROP TABLE ImportSourceMetadata
CREATE TABLE ImportSourceMetadata(SourceId nvarchar(50) PRIMARY KEY, LastCheckpoint datetime)

BEGIN TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT LastCheckpoint FROM ImportSourceMetadata WITH (UPDLOCK) WHERE SourceId='Source'

SELECT * 
FROM sys.dm_tran_locks l 
JOIN sys.partitions p 
ON l.resource_associated_entity_id = p.hobt_id JOIN sys.objects o 
ON p.object_id = o.object_id

INSERT INTO ImportSourceMetadata VALUES('Source', '2013-12-21')
ROLLBACK TRAN

BEGIN TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT LastCheckpoint FROM ImportSourceMetadata WITH (UPDLOCK) WHERE SourceId='Source'

SELECT * 
FROM sys.dm_tran_locks l 
JOIN sys.partitions p 
ON l.resource_associated_entity_id = p.hobt_id JOIN sys.objects o 
ON p.object_id = o.object_id

ROLLBACK TRAN

在我的系统(使用 SQL Server 2012)上，第一个查询显示 ImportSourceMetadata 上没有锁定。 ，但第二个查询显示 KEY锁定ImportSourceMetadata .

换句话说，HOLDLOCK确实需要，但前提是该表是新创建的。这是为什么？

Answer 1

您还需要HOLDLOCK。

如果该行确实存在，那么您的 SELECT 语句将至少获取该行上的 U 锁，并将其保留到事务结束。

如果该行不存在，则没有行可以获取并持有 U 锁，因此您不会锁定任何内容。 HOLDLOCK 将至少锁定该行适合的范围。

如果没有 HOLDLOCK，两个并发事务都可以对不存在的行执行 SELECT。不保留任何冲突的锁，并且都移至 INSERT。

关于您问题中的重现，“行不存在”问题似乎比我最初想象的要复杂一些。

如果该行之前确实存在，但已被逻辑删除，但实际上仍然作为“幽灵”记录存在于页面上，则仍然可以在幽灵上取出 U 锁，从而解释阻塞你正在看到的。

您可以使用DBCC PAGE来查看幽灵记录，如对代码的轻微修改所示。

SET NOCOUNT ON;

DROP TABLE ImportSourceMetadata

CREATE TABLE ImportSourceMetadata
  (
     SourceId       NVARCHAR(50),
     LastCheckpoint DATETIME,
     PRIMARY KEY(SourceId)
  )

BEGIN TRAN

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

SELECT LastCheckpoint
FROM   ImportSourceMetadata WITH (UPDLOCK)
WHERE  SourceId = 'Source'

INSERT INTO ImportSourceMetadata
VALUES      ('Source',  '2013-12-21')

DECLARE @DBCCPAGE NVARCHAR(100)

SELECT TOP 1 @DBCCPAGE = 'DBCC PAGE(0,' + CAST(file_id AS VARCHAR) + ',' + CAST(page_id AS VARCHAR) + ',3) WITH NO_INFOMSGS'
FROM   ImportSourceMetadata
       CROSS APPLY  sys.fn_physloccracker(%%physloc%%)

ROLLBACK TRAN

DBCC TRACEON(3604)

EXEC (@DBCCPAGE)

DBCC TRACEOFF(3604)

SSMS 消息选项卡显示

Slot 0 Offset 0x60 Length 31

Record Type = GHOST_DATA_RECORD      Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 31                     
Memory Dump @0x000000001215A060

0000000000000000:   3c000c00 00000000 9ba20000 02000001 †<.......¢...... 
0000000000000010:   001f0053 006f0075 00720063 006500††††...S.o.u.r.c.e.  

Slot 0 Column 1 Offset 0x13 Length 12 Length (physical) 12