主页 / dba / 问题 / 66683
Accepted
Mark Freeman
Asked: 2014-06-06 11:03:40 +0800 CST

交易隔离级别快照与截断？

  • 772

我希望有人能对这种我没有预料到的关于 SNAPSHOT 隔离与 TRUNCATE 的行为有所了解。

数据库：允许快照隔离 = True；是否已提交读取快照打开 = False。

过程 1（用大量连接替换长时间运行的复杂 SELECT 表 foo 的内容）：

BEGIN TRAN; 
TRUNCATE TABLE foo; 
INSERT INTO foo SELECT...; 
COMMIT;

程序 2（从表 foo 中读取）：

SET TRANSACTION ISOLATION LEVEL SNAPSHOT; 
SELECT * FROM foo;

如果在执行 Procedure2 时 Procedure1 正在运行，则 Procedure2 将等待 LCK_M_SCH_S 等待（根据 sp_WhoIsActive），直到 Procedure1 完成。当 Procedure2 完成时，它会引发此异常：

数据库“DatabaseName”中的快照隔离事务失败，因为自该事务开始以来，该语句访问的对象已被另一个并发事务中的 DDL 语句修改。这是不允许的，因为元数据没有版本化。如果与快照隔离混合，对元数据的并发更新可能会导致不一致。

但是，Microsoft 并未将 TRUNCATE 列为 SNAPSHOT 隔离下不允许的 DDL 语句：http: //msdn.microsoft.com/en-us/library/bb933783.aspx

显然我没有正确理解某些东西，因为我本以为 Procedure2 的最佳情况会在 TRUNCATE 之前立即从表中返回最近提交的数据，或者最坏的情况是被 Procedure1 阻止，然后返回新的内容桌子。你能帮我吗？

sql-server sql-server-2008-r2

1 个回答

  1. Best Answer

    列出的'DDL'操作列表并不全面（并且TRUNCATE TABLE不是该列表中唯一的遗漏）。SQL Server中是否TRUNCATE TABLE是一个令人担忧的问题，辩论双方都有有说服力的示例，并且在联机丛书中有两种方式的条目。DMLDDL

    从快照隔离事务的角度来看，truncate 具有取Sch-M锁的本质特性，这解释了阻塞（因为RCSI并且SI仍然获取Sch-S锁）；它还会影响内部元数据版本（出于内部原因*），导致错误 3961。

    因此，您看到的行为是预期的，只是没有很好地记录。

    * TRUNCATE TABLE 的当前实现不生成行版本。碰撞元数据版本是确保正确行为的最简单方法。

    • 19

相关问题