SQL2005中的事务与锁定（二）-转载

设置已提交读隔离使用行版本控制 ALTER DATABASE testcsdn SET READ_COMMITTED_SNAPSHOT ON GO --查看当前已提交读隔离并发模型 select name,database_id,is_read_committed_snapshot_on from sys.databases /* name database_id is_read_committed_snapshot_on -------------------- ----------- ----------------------------- master 1 0 tempdb 2 0 model 3 0 msdb 4 0 ReportServer$SQL2005 5 0 ReportServer$SQL2005TempDB 6 0 TestCsdn 7 1 --current (7 行受影响) */ --设置已提交读隔离使用锁定 ALTER DATABASE testcsdn SET READ_COMMITTED_SNAPSHOT OFF GO --查看已提交读隔离并发模型 select name,database_id,is_read_committed_snapshot_on from sys.databases /* name database_id is_read_committed_snapshot_on -------------------- ----------- ----------------------------- master 1 0 tempdb 2 0 model 3 0 msdb 4 0 ReportServer$SQL2005 5 0 ReportServer$SQL2005TempDB 6 0 TestCsdn 7 0 --curret (7 行受影响) */

已提交读在逻辑上保证了不会读到不实际存在的数据。悲观并发下的已提交读，当进程要修改数据时会在数据行上申请排它锁，其它进程（无论是读还是写）必须等到排它锁释放才可以使用这些数据。如果进程仅是读取数据时会使用共享锁，其它进程虽然可以读取数据但是无法更新数据，必须等到共离锁释放（共享锁在数据处理完即释放，比如行共享锁在当前数据行数据处理完就自动释放，不会在整个事务内保留发。）。乐观并发的已提交读，也确保不会读到未提交的数据，不是通过锁定的方式来实现，而是通过行版本控制器生成行的提前交的数据版本，被修改的数据虽然仍然锁定，但是其它进程可以可以读取更新前版本数据。
　　可重复读（Repeatable Read）：这也是一个悲观并发的级别。可重复读比已提交读要求更严格，在已提交读的基础上增加了一个限制：获取的共享锁保留到事务结束。在这个限制下，进程在一个事务里两交次读取的数据一致，也就是不会读取到其它进程修改了数据。在这儿我们提到共享锁会保留到事务结束，那得申明一下无论哪种级别及并发模型，排它锁是一定要保留到事务结束的。在可重复读级别共享锁同样也会保留到事务结束。那么这种对数据安全的保证是通过增加共享保留的开销为代价的，也就是只要开始一个事务，其它用户进程是不可能修改数据的，显而易见的系统的并发性和性能必然下降。这似乎是我们想像中的一种级别，虽然这个级别暂时无法回避幻影读，而且我们也默许并发及性能下降，那只有对程序员对事务的控制有严格的要求：事务要短并尽量不要人为因素的干扰，减少潜在的锁竞争。
　　快照(SnapShot)：乐观并发级别。这是2005新增加的一个隔离级别。快照级别与使用乐观并发的已提交读差不多，差别在于行版控制器里的数据版本有多早，这个在以后讲锁时再说。这个级别保证了一个事务读取的数据是事务开始时就在数据库逻辑上确认并符合一致性的数据。读操作不会要求共享锁定，如果要求的数据已经排它，就会通过行版本控制器读取最近的符合一致性的数据。
　　可串行化：是目前最严谨、最健壮的一个级别，属于悲观并发。它防止幻影的发生，回避了以前所有意外行为的发生。可串行化意味着系统按进程进入队列的顺序依次、序列化的执行的结果与事务同时运行得到一致的结果。这个最健壮的级别显然共享锁也是随事务开始随事务结束，并通过锁定部分不存在的数据（即索引键范围锁定）来回避幻影的发生。



今天的任务完成，前两篇我只是把理论上的东西整理了一下，下一篇我把意外行为结合隔离等级用点实例来说明，然后再开始整理锁定。

请大家继续关注我的blog: http://blog.csdn.net/happyflystone

SQL2005中的事务与锁定（二）-转载

标签：