IT星球论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

新浪微博账号登陆

只需一步,快速开始

搜索
查看: 3504|回复: 0

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

[复制链接]

1997

主题

1

好友

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

优秀会员 助人为乐 辛勤工作 技术精英 多才多艺 优秀班竹 灌水天才 星球管理 宣传大使 灌水之王 财富勋章 版主勋章 动漫勋章 勤奋会员 论坛精英 PS高手 心 8 闪游皮肤 双鱼座 8★8➹ 志愿者 乖

发表于 2013-4-27 14:07:49 |显示全部楼层
有个客户刚刚上线了供应商一套业务系统,供应商开发人员开发的应用代码质量和业务逻辑都存在非常大的问题,导致大量的阻塞发生。为此,客户的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


该会员没有填写今日想说内容.
您需要登录后才可以回帖 登录 | 立即注册 新浪微博账号登陆

回顶部