gro*_*wse 9 sql-server transaction locking isolation-level
我有一个长时间运行的事务(称为 T1),它对 SQL Server 2008 R2 中的表执行一些删除、更新和插入操作。同时,另一个进程会定期从该表中运行 select 语句。
在默认隔离设置下(我认为是 READ COMMITTED?),T1 会阻止任何 select 语句运行,直到事务提交或回滚。
我希望看到的是,即使在事务正在进行时,select 语句也能对一致的数据起作用。我相信 SNAPSHOT 隔离可以提供帮助,但不确定我是否朝着正确的方向前进。这是该应用程序的最佳隔离级别吗?
其次,我无法控制调用 select 语句的进程,但我可以控制调用 T1 的 .NET 应用程序。select 语句和 T1 都需要更改任何隔离级别,还是仅将 T1 标记为具有不同的隔离级别就足够了?
正确,使用快照隔离从事务开始之前获取一致的提交数据。
READ UNCOMMITTED 隔离(又名 NOLOCK 提示)将读取脏的、不一致的数据
当您启用 SNAPSHOT 隔离时,它将对以后的所有 SELECT 生效。ALTER DATABASE在这种情况下,您使用 READ_COMMITTED_SNAPSHOT运行
编辑:添加链接 + ALTER DATABASE 的引用(我的粗体)
在数据库级别启用 Read-Committed Snapshot 选项。启用后,即使没有事务使用快照隔离,DML 语句也会开始生成行版本。启用此选项后,指定读已提交隔离级别的事务将使用行版本控制而不是锁定。当事务在已提交读隔离级别运行时,所有语句都会看到存在于语句开头的数据快照。
来自使用快照隔离(我的粗体)
READ_COMMITTED_SNAPSHOT 数据库选项确定在数据库中启用快照隔离时默认READ COMMITTED 隔离级别的行为。如果未明确指定 READ_COMMITTED_SNAPSHOT ON,则 READ COMMITTED 将应用于所有隐式事务。这会产生与设置 READ_COMMITTED_SNAPSHOT OFF(默认值)相同的行为。当 READ_COMMITTED_SNAPSHOT OFF 生效时,数据库引擎使用共享锁来强制执行默认隔离级别。如果将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON,则数据库引擎默认使用行版本控制和快照隔离,而不是使用锁来保护数据。
所以,是的。
启用 RCSI 将允许读取获得一致的数据并且不会被写入者阻止,而将继续使用 Read Committed
| 归档时间: |
|
| 查看次数: |
6720 次 |
| 最近记录: |