SQL Server 并发性系列（二）使用行版本控制提高 SQL Server ...

安哥网络

有个客户刚刚上线了供应商一套业务系统，供应商开发人员开发的应用代码质量和业务逻辑都存在非常大的问题，导致大量的阻塞发生。为此，客户的DBA每到高峰期必须不断的刷新活动监视器，KILL掉引起大量阻塞的进程。否则，首先体现的用户几乎所有操作无法执行，过一会儿SQL Server 群集服务自动重新启动了。
修改代码和业务逻辑的实现方式，当然是最佳的选择。但是查找问题、修改代码、测试上线，至少需要两周时间，因此客户希望有办法能缓解阻塞的发生。
在上一篇文章《SQL Server 并发性系列（一）并发性问题自测及分析》中我们我们曾经分析过一种最为常见的阻塞发生的原因，例如：
--首先我们创建一张测试表
Create Table T1 (Id INT NOT NULL, Value INT)
INSERT T1 VALUES (1,100)
INSERT T1 VALUES (2,200)
--然后我们在SSMS中打开两个会话窗口，先后执行下面两条语句

上表中的两个会话，如果会话1先启动进行修改，在没有Commit或者RollBack之前，会话2是无法执行完成的，会一直处于等待状态。我们称之为这种现象叫阻塞。导致这种原因的是会话2请求的记录被会话1排他锁定，会话2只能等待会话1完成。
虽然，使用nolock锁提示可以让会话2然会结果，但是nolock返回的是并未提交的修改后的结果，即value列返回的是110，而不是修改前的100，可能影响业务的准确性。而且，即便是加上nolcok，也需要通过修改应用程序实现。
微软在SQL Server 2005 及其以后版本中加入了一种行版本控制技术。可以提高这种并发性，返回修改之前的数据。我们称之为行版本控制，该技术有如下特点：

• 在记录被修改时，会将修改之前的行版本（记录信息）复制到TempDB；
• 如果有用户在事务完成之前查询该记录，则返回该记录修改前的状态；
• TempDB数据需要保证足够空间，并存在在高性能的存储上；
• 可以在数据库级启动，不需要修改任何代码，对开发人员透明；
• SQL Server 2005 及其以后版本支持，包括标准版；
  

通过在数据库级启动行版本控制功能，我们可以大大减少这种读写之间的阻塞，提高数据库和应用的并发性，改善性能。在客户处也体现出，阻塞大大减少，性能明显提升。
具体实现方法也非常简单：
1. 断开所有用户对某个数据库的访问；
2. 在该数据库级别启动行版本控制；
ALTER DATABASE 数据库名 SET READ_COMMITTED_SNAPSHOT ON;
本文摘自：http://www.canway.net/Lists/Canw ... 747A43215699709205A