SQL2005中的事务与锁定（二）,该怎么处理
SQL2005中的事务与锁定（二）
请支持我的blog: http://blog.csdn.net/happyflystone
前一篇：SQL2005中的事务与锁定（一）
SQL2005中的事务与锁定（二）
全文地址
------------------------------------
-- Author : HappyFlyStone
-- Date : 2009-09-27 21:36:30
-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)
-- Apr 14 2006 01:12:25
-- Copyright (c) 1988-2005 Microsoft Corporation
-- Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
-- 转载请注明出处，更多请关注：http://blog.csdn.net/happyflystone
-- 关键字：隔离等级 锁定
------------------------------------
四、 隔离等级
首先来说说隔离，隔离是一个事务必须与其他事务所进行的资源或数据更改相隔开，显然隔离等级就是相隔的程度了吧。在说隔离级别不得不提及锁的概念，但是在本单不提及锁，在以后听章节里再作说明，大家只要有个印象就行。在这儿我们必须明白两件事：
1，隔离级别不会影响进程获得数据修改的排它锁，并且这个锁会保存到事务结束。相对于读进程来说，隔离级别就是对读操作的一个保护级别，保护读操作受其它事务影响的程序。
2，较低的隔离级别可以增强许多用户同时访问数据的能力，但也增加了用户可能遇到的并发副作用（例如脏读或丢失更新）的数量。相反，较高的隔离级别减少了用户可能遇到的并发副作用，却需要太多的系统资源及一个事务阻塞其他事务的可能性。
应平衡应用程序的完整性要求与相应隔离级别的系统开销，在此基础上选择相应的隔离级别。最高隔离级别（可序列化）保证事务在每次重复读取操作时都能准确检索到相同的数据，但需要通过执行某种级别的锁定来完成此操作，而锁定可能会影响其他用户进程。最低隔离级别（未提交读）可以检索其他事务已经修改但未提交的数据。在未提交读中，所有并发副作用都可能发生，但因为没有读锁定或修改阻塞读取，所以开销最少。
不同的隔离级别决定我们有哪些数据副作用可以发生，而并发模型决定不同隔离等级下如何来限制这些数据行为或如何协调这数据行为。好，那我们来关注一下不同隔离等级下如何限制这些行为的发生。
未提交读（uncommitted Read）：字面理解一下，修改了的未提交数据可以读取。准确点：一个用户进程可以读取另一个用户进程修改却未提交的数据。SQL SERVER对这个等级下的读操作不需要获得任何锁就可以读取数据，因为不需要锁所以不会和其它任何进程互相阻塞，自然而然能读取其它进程修改了的却未提交数据。显然这不是我们理想的一种模式，但是它却有了高并发性，因为读操作没有锁不会影响其它进程的读或写操作。在这种级别下，除了丢失更新（上一讲中的数据可能发生的行为）外，其它行为都有可能发生，冒着数据不一致的风险来避免修改的进程阻塞读取的进程，事务的一致性肯定是得不到保障，显然这是消极并发模式下的回避阻塞频繁的一种解决方案。未提交读那肯定是不适合于股票、金融系统的，但是在一些趋势分析的系统里，要求的只是一种走向，准确性可以不是那么严格时，这个级别因并发性能超强成为首选。
已提交读(Read Committed)：它和未提交读相反，已提交读级别保证一个进程不可能读到另一个进程修改但未提交的数据。这个级别是引擎默认的级别，也是2005乐观并发模式下支持的级别，也就是说已提交读可是乐观的也可以是悲观的，那究竟当前库是属于哪个并发模型下的已提交读呢，这取决于一个READ_COMMITED_SNAPSHOT数据库配置项，并且缺省是悲观并发控制的。这个配置项决定已提交读级别下事务使用锁定还是行版本控制，并很显然行版本控制是乐观并发模式，锁定是悲观并发模式。我们来点角本看看：
--设置已提交读隔离使用行版本控制
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）：这也是一个悲观并发的级别。可重复读比已提交读要求更严格，在已提交读的基础上增加了一个限制：获取的共享锁保留到事务结束。在这个限制下，进程在一个事务里两交次读取的数据一致，也就是不会读取到其它进程修改了数据。在这儿我们提到共享锁会保留到事务结束，那得申明一下无论哪种级别及并发模型，排它锁是一定要保留到事务结束的。在可重复读级别共享锁同样也会保留到事务结束。那么这种对数据安全的保证是通过增加共享保留的开销为代价的，也就是只要开始一个事务，其它用户进程是不可能修改数据的，显而易见的系统的并发性和性能必然下降。这似乎是我们想像中的一种级别，虽然这个级别暂时无法回避幻影读，而且我们也默许并发及性能下降，那只有对程序员对事务的控制有严格的要求：事务要短并尽量不要人为因素的干扰，减少潜在的锁竞争。
请支持我的blog: http://blog.csdn.net/happyflystone
前一篇：SQL2005中的事务与锁定（一）
SQL2005中的事务与锁定（二）
全文地址
------------------------------------
-- Author : HappyFlyStone
-- Date : 2009-09-27 21:36:30
-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)
-- Apr 14 2006 01:12:25
-- Copyright (c) 1988-2005 Microsoft Corporation
-- Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)
-- 转载请注明出处，更多请关注：http://blog.csdn.net/happyflystone
-- 关键字：隔离等级 锁定
------------------------------------
四、 隔离等级
首先来说说隔离，隔离是一个事务必须与其他事务所进行的资源或数据更改相隔开，显然隔离等级就是相隔的程度了吧。在说隔离级别不得不提及锁的概念，但是在本单不提及锁，在以后听章节里再作说明，大家只要有个印象就行。在这儿我们必须明白两件事：
1，隔离级别不会影响进程获得数据修改的排它锁，并且这个锁会保存到事务结束。相对于读进程来说，隔离级别就是对读操作的一个保护级别，保护读操作受其它事务影响的程序。
2，较低的隔离级别可以增强许多用户同时访问数据的能力，但也增加了用户可能遇到的并发副作用（例如脏读或丢失更新）的数量。相反，较高的隔离级别减少了用户可能遇到的并发副作用，却需要太多的系统资源及一个事务阻塞其他事务的可能性。
应平衡应用程序的完整性要求与相应隔离级别的系统开销，在此基础上选择相应的隔离级别。最高隔离级别（可序列化）保证事务在每次重复读取操作时都能准确检索到相同的数据，但需要通过执行某种级别的锁定来完成此操作，而锁定可能会影响其他用户进程。最低隔离级别（未提交读）可以检索其他事务已经修改但未提交的数据。在未提交读中，所有并发副作用都可能发生，但因为没有读锁定或修改阻塞读取，所以开销最少。
不同的隔离级别决定我们有哪些数据副作用可以发生，而并发模型决定不同隔离等级下如何来限制这些数据行为或如何协调这数据行为。好，那我们来关注一下不同隔离等级下如何限制这些行为的发生。
未提交读（uncommitted Read）：字面理解一下，修改了的未提交数据可以读取。准确点：一个用户进程可以读取另一个用户进程修改却未提交的数据。SQL SERVER对这个等级下的读操作不需要获得任何锁就可以读取数据，因为不需要锁所以不会和其它任何进程互相阻塞，自然而然能读取其它进程修改了的却未提交数据。显然这不是我们理想的一种模式，但是它却有了高并发性，因为读操作没有锁不会影响其它进程的读或写操作。在这种级别下，除了丢失更新（上一讲中的数据可能发生的行为）外，其它行为都有可能发生，冒着数据不一致的风险来避免修改的进程阻塞读取的进程，事务的一致性肯定是得不到保障，显然这是消极并发模式下的回避阻塞频繁的一种解决方案。未提交读那肯定是不适合于股票、金融系统的，但是在一些趋势分析的系统里，要求的只是一种走向，准确性可以不是那么严格时，这个级别因并发性能超强成为首选。
已提交读(Read Committed)：它和未提交读相反，已提交读级别保证一个进程不可能读到另一个进程修改但未提交的数据。这个级别是引擎默认的级别，也是2005乐观并发模式下支持的级别，也就是说已提交读可是乐观的也可以是悲观的，那究竟当前库是属于哪个并发模型下的已提交读呢，这取决于一个READ_COMMITED_SNAPSHOT数据库配置项，并且缺省是悲观并发控制的。这个配置项决定已提交读级别下事务使用锁定还是行版本控制，并很显然行版本控制是乐观并发模式，锁定是悲观并发模式。我们来点角本看看：
--设置已提交读隔离使用行版本控制
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）：这也是一个悲观并发的级别。可重复读比已提交读要求更严格，在已提交读的基础上增加了一个限制：获取的共享锁保留到事务结束。在这个限制下，进程在一个事务里两交次读取的数据一致，也就是不会读取到其它进程修改了数据。在这儿我们提到共享锁会保留到事务结束，那得申明一下无论哪种级别及并发模型，排它锁是一定要保留到事务结束的。在可重复读级别共享锁同样也会保留到事务结束。那么这种对数据安全的保证是通过增加共享保留的开销为代价的，也就是只要开始一个事务，其它用户进程是不可能修改数据的，显而易见的系统的并发性和性能必然下降。这似乎是我们想像中的一种级别，虽然这个级别暂时无法回避幻影读，而且我们也默许并发及性能下降，那只有对程序员对事务的控制有严格的要求：事务要短并尽量不要人为因素的干扰，减少潜在的锁竞争。