SQL Server 并发控制 第四篇：Snapshot Isolation (SI) 和 Read Committed Snapshot Isolation (RCSI)

乐观控制模式假定阻塞很少，快照隔离通过使用行版本控制来避免大多数锁定和阻塞。当数据被修改时，受影响行的已提交版本会被复制到 tempdb 并赋予版本号，此操作称为写时复制 (Copy on Write)，并用于所有的插入、更新和删除操作。当另一个会话读取相同的数据时，将返回读取事务开始时的复制到tempdb的已提交数据版本。

通过避免大多数锁定，这种方法可以比事务隔离以更低的成本显著提高并发性。当然，“天下没有免费的午餐！”，快照隔离也有一个隐藏的成本：tempdb 的使用量增加。SQL Server 中可用的两种快照隔离类型：

• READ COMMITTED SNAPSHOT ISOLATION (RCSI)
• SNAPSHOT ISOLATION

一，Read Committed Snapshot Isolation (RCSI)

在数据库上启用RCSI：

ALTER DATABASE <database name> SET READ_COMMITTED_SNAPSHOT ON;

检查数据库的隔离级别：

SELECT DB_NAME(database_id), is_read_committed_snapshot_on,snapshot_isolation_state_desc  
FROM sys.databases
WHERE database_id = DB_ID();

字段注释：

snapshot_isolation_state：State of snapshot-isolation transactions being allowed, as set by the ALLOW_SNAPSHOT_ISOLATION option:

• 0 = Snapshot isolation state is OFF (default). Snapshot isolation is disallowed.
• 1 = Snapshot isolation state ON. Snapshot isolation is allowed.
• 2 = Snapshot isolation state is in transition to OFF state. All transactions have their modifications versioned. Can't start new transactions using snapshot isolation. The database remains in the transition to OFF state until all transactions that were active when ALTER DATABASE was run can be completed.
• 3 = Snapshot isolation state is in transition to ON state. New transactions have their modifications versioned. Transactions can't use snapshot isolation until the snapshot isolation state becomes 1 (ON). The database remains in the transition to ON state until all update transactions that were active when ALTER DATABASE was run can be completed.

snapshot_isolation_state_Desc: Description of state of snapshot-isolation transactions being allowed, as set by the ALLOW_SNAPSHOT_ISOLATION option.

is_read_committed_snapshot_on：

• 1 = READ_COMMITTED_SNAPSHOT option is ON. Read operations under the read-committed isolation level are based on snapshot scans and don't acquire locks.
• 0 = READ_COMMITTED_SNAPSHOT option is OFF (default). Read operations under the read-committed isolation level use share locks.

RCSI的工作原理是：将所有运行在RCSI下的查询都改为使用快照扫描（snapshot scan），并且除了 Sch-S（schema stability)）锁之外，不再获取其他锁。这样，即使是那些没有请求访问权限的查询，也能自动访问版本化的行。请看以下两个查询：

二，Snapshot Isolation

在数据库上把Allow  Snapshot Isolation选项设置为ON，但是这并不意味着启用了Snapshot Isolation，只是允许启用。

ALTER DATABASE MyOrders SET ALLOW_SNAPSHOT_ISOLATION ON;

快照隔离级别只能在会话级别上启用，下面的代码禁用RCSI，允许Snapshot Isolation，并在Session级别上启用了Snapshot Isolation：

ALTER DATABASE <DB_NAME> SET READ_COMMITTED_SNAPSHOT OFF;
ALTER DATABASE <DB_NAME> SET ALLOW_SNAPSHOT ON;SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

 

 

这里用两个Query来模型快照隔离下的更新冲突：

抛出的错误消息是：

Msg 3960, Level 16, State 5, Line 7

Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table ‘Orders. Orders’ directly or indirectly in database ‘MyOrders’ to update, delete, or insert the row that has been modified or deleted by another transaction. Retry the transaction or change the isolation level for the update/delete statement

 

最重要的部分是第一句话：“事务因更新冲突而中止。” 问题在于两个查询都试图更新同一行。当尝试提交第二个更新的行版本时，SQL Server 发现第一个事务也在尝试更新同一行。数据库引擎判断第二个更新操作的优先级更低，因此果断阻止第二个更新操作。这在某些方面类似于在悲观的事务隔离下可能发生的死锁。在事务隔离下，当两个或多个事务因为试图获取一个或多个不兼容的锁而发生锁冲突时，就会检测到死锁。使用行版本控制，可能会出现更新冲突，就像我遇到的情况一样。区别在于，锁冲突发生在事务提交之前，而更新冲突发生在提交期间，因为数据库引擎会将版本存储中的行与已提交的行进行比较，并发现不匹配。

 

引用文档：

Snapshot Isolation in SQL Server