SQLSERVER2005行版本控制的使用总结
例子:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRANSACTION;
SELECT *
FROM User2
行版本控制隔离:优势
使用行版本控制的隔离级别具有以下优点:
· 读取操作检索一致的数据库快照。
· SELECT 语句在读取操作过程中不锁定数据(读取器不阻塞编写器,编写器也不阻塞读取器)。
· SELECT 语句可以在其他事务更新行时访问最后提交的行值,而不阻塞应用程序。
· 死锁的数量减少。
· 事务所需的锁的数量减少,这减少了管理锁所需的系统开销。
· 锁升级的次数减少。
行版本控制隔离:原理
SQL Server 2005的行版本控制原理上很简单,就是在库表中每一行的记录上都悄悄的增加了一个类时间戳列(行版本列)。
当使用行版本控制的隔离时,SQL Server 2005 Database Engine 向使用行版本控制操作数据的每个事务分配一个事务序列号 (XSN)。
事务在执行 BEGIN TRANSACTION 语句时启动。
但是,事务序列号在执行 BEGIN TRANSACTION 语句后的第一次读/写操作时开始增加。
事务序列号在每次分配时都增加 1。
事务在执行 BEGIN TRANSACTION 语句时启动。
但是,事务序列号在执行 BEGIN TRANSACTION 语句后的第一次读/写操作时开始增加。
事务序列号在每次分配时都增加 1。
当事务执行时,SQL Server根据行版本列,来提供的行的相应版本。
而SQLServer将维护所有在数据库中执行的数据修改的逻辑副本(版本)。
特定的事务每次修改行时,数据库引擎 实例都存储以前提交的 tempdb 中行的图像版本。
每个版本都标记有进行此更改的事务的事务序列号。
已修改行的版本使用链接列表链接在一起。
最新的行值始终存储在当前的数据库中并链接至版 本存储区 tempdb 中存储的版本。
(修改大型对象 (LOB) 时,只有已更改的片段才会复制到 tempdb 中的版本存储区, 对于短期运行的事务,已修改行的版本将可能保存在缓冲池中,而不会写入 tempdb 数据库的磁盘文件中。
如果只是临时需要副本行,它将只是简单地从缓冲池中删除而不会引发 I/O 开销。)
行版本控制隔离:种类
READ_COMMITTED_SNAPSHOT的强项在于查询的时候不会下锁,影响别的事务操作,
而且可以保障查询的数据满足绝大多数的精确要求。
SNAPSHOT隔离就像真实的快照,它会无视涉及行的变化。在SNAPSHOT隔离下运行的事务将读取数据,然后由另一事务修改此数据。SNAPSHOT事务不阻塞由其他事务执行的更新操作,它忽略数据的修改继续从版本化的行读取数据。但是,当快照事务尝试修改已由其他事务修改的数据时,SNAPSHOT事务将生成错误并终止.
相比READ_COMMITTED_SNAPSHOT,SNAPSHOT真正做到了快照隔离,完全无视数据的更新。相对READ_COMMITTED_SNAPSHOT,它更进一步减轻了对锁的依赖,在性能方面获得了更大的优势。不可避免的是,SNAPSHOT的事务性也变得更差,但是,至少,它比NoLock要好。^_^
SNAPSHOT比READ_COMMITTED_SNAPSHOT更快,但是坏消息是它的限制也多。
1.快照隔离不支持分布式事务,包括分布式分区数据库中的查询。
2.SQL Server 不会保留多个版本的系统元数据。表中的数据定义语言 (DDL) 语句和其他数据库对象(索引、视图、数据类型、存储过程和公共语言运行时函数)会更改元数据。如果 DDL 语句修改一个对象,那么在快照隔离下对该对象的任何并发引用都将导致快照事务失败。READ_COMMITTED_SNAPSHOT 数据库选项为 ON 时,已提交读事务没有此限制。
3.BULK INSERT 操作可能会导致对目标表元数据的更改(例如,禁用约束检查时)。如果出现这种情况,访问大容量插入表的并发快照隔离事务将失败。
特定的事务每次修改行时,数据库引擎 实例都存储以前提交的 tempdb 中行的图像版本。
每个版本都标记有进行此更改的事务的事务序列号。
已修改行的版本使用链接列表链接在一起。
最新的行值始终存储在当前的数据库中并链接至版 本存储区 tempdb 中存储的版本。
(修改大型对象 (LOB) 时,只有已更改的片段才会复制到 tempdb 中的版本存储区, 对于短期运行的事务,已修改行的版本将可能保存在缓冲池中,而不会写入 tempdb 数据库的磁盘文件中。
如果只是临时需要副本行,它将只是简单地从缓冲池中删除而不会引发 I/O 开销。)
行版本控制隔离:种类
行版本控制分为两种已提交读快照隔离级别(READ_COMMITTED_SNAPSHOT)和快照隔离级别(ALLOW_SNAPSHOT_ISOLATION),他们属于行版本控制的隔离的范畴,但是实际上他们却有方方面面的不同。
下面是MSDN对他们的比较。
属性 |
已提交读快照隔离级别 |
快照隔离级别 |
必须设置为 ON 以便启用所需支持的数据库选项。 |
READ_COMMITTED_SNAPSHOT |
ALLOW_SNAPSHOT_ISOLATION |
会话如何请求特定类型的行版本控制。 |
使用默认的已提交读隔离级别,或运行 SET TRANSACTION ISOLATION LEVEL 语句来指定 READ COMMITTED 隔离级别。这可以在事务启动后完成。 |
需要执行 SET TRANSACTION ISOLATION LEVEL 来在事务启动前指定 SNAPSHOT 隔离级别。 |
由语句读取的数据的版本。 |
在每条语句启动前提交的所有数据。 |
在每个事务启动前提交的所有数据。 |
如何处理更新。 |
从行版本恢复到实际的数据,以选择要更新的行并使用选择的数据行上的更新锁。获取要修改的实际数据行上的排他锁。没有更新冲突检测。 |
使用行版本选择要更新的行。尝试获取要修改的实际数据行上的排他锁,如果数据已被其他事务修改,则出现更新冲突,同时快照事务也将终止。 |
有更新冲突检测。 |
无。 |
集成支持。无法禁用。 |
READ_COMMITTED_SNAPSHOT的强项在于查询的时候不会下锁,影响别的事务操作,
而且可以保障查询的数据满足绝大多数的精确要求。
SNAPSHOT隔离就像真实的快照,它会无视涉及行的变化。在SNAPSHOT隔离下运行的事务将读取数据,然后由另一事务修改此数据。SNAPSHOT事务不阻塞由其他事务执行的更新操作,它忽略数据的修改继续从版本化的行读取数据。但是,当快照事务尝试修改已由其他事务修改的数据时,SNAPSHOT事务将生成错误并终止.
相比READ_COMMITTED_SNAPSHOT,SNAPSHOT真正做到了快照隔离,完全无视数据的更新。相对READ_COMMITTED_SNAPSHOT,它更进一步减轻了对锁的依赖,在性能方面获得了更大的优势。不可避免的是,SNAPSHOT的事务性也变得更差,但是,至少,它比NoLock要好。^_^
SNAPSHOT比READ_COMMITTED_SNAPSHOT更快,但是坏消息是它的限制也多。
1.快照隔离不支持分布式事务,包括分布式分区数据库中的查询。
2.SQL Server 不会保留多个版本的系统元数据。表中的数据定义语言 (DDL) 语句和其他数据库对象(索引、视图、数据类型、存储过程和公共语言运行时函数)会更改元数据。如果 DDL 语句修改一个对象,那么在快照隔离下对该对象的任何并发引用都将导致快照事务失败。READ_COMMITTED_SNAPSHOT 数据库选项为 ON 时,已提交读事务没有此限制。
3.BULK INSERT 操作可能会导致对目标表元数据的更改(例如,禁用约束检查时)。如果出现这种情况,访问大容量插入表的并发快照隔离事务将失败。