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 操作可能会导致对目标表元数据的更改（例如，禁用约束检查时）。如果出现这种情况，访问大容量插入表的并发快照隔离事务将失败。
