Select语句也会引发死锁

　　项目上线，准备验收前出现了一个严重的问题：不少select语句做为死锁的牺牲，大部分报表没法打开。这个问题影响范围很大全部的报表都没法访问，而咱们的报表是放在电视上面轮播的，电视放在工厂里面，因此出现问题后，整个工厂都知道了。

　　解决这个问题比较曲折，首先是写SAP接口的同事发现了问题：SAP一直在传错误数据致使产量表被锁住。修改SAP传输的错误数据后，这个死锁的问题没有出现了。可是我查看生产环境服务器日志的时候，发现这个问题依然存在，因为客户没有提这个问题，我也就是没有理由要求花时间修改了，由于我还有其余项目在忙。

　　问题始终存在，它的暴露只是时间问题。过了一周，在咱们要谈项目验收的时候，这个问题又暴露出来了。由于影响很是大，给客户形成很差的印象。因此修改这个问题获得了老板的支持，说实话，我也头一次遇到这样的问题，也想不通select语句怎么就死锁了。我知道这个问题很头疼，好在获得老板的支持，会给足够的时候我来解决问题，我也就有信心了。

　　在网上找了不少文章，个人解决思路是：经过查询语句查找死锁相关的sql语句，只发现了被牺牲的那条sql语句，另一条sql语句没有找到，这条路走不通。接着就是重现问题，而后解决问题。这条路刚开始也走不通，也行不通，重现了一个下午有没有发现问题。在快下班的时候，我迷茫了。次日又网上找了半天资料，这个时候想到用sql server profiler去监听数据库，悲剧的是客户那边放假了，连不到出问题的生产环境数据库。接着跟同事聊这个问题，他给的建议依然是重现，而后记得有个方法能够重现，这个时候我才猛然想起来了有这档子事。

　　重现方法是有sql语句循环往产量表插入数据，因为报表大多读取产量表，而后报表就常常死锁。这个时候我看到但愿了，只是不理解select语句怎么会引发死锁，后来在网上认真读了一篇文章：SqlServer中select语句引发的死锁（http://www.csharpwin.com/csharpspace/11505r288.shtml），读懂这篇文章后我以为跟我遇到的状况很是类似。

　　经过他的理论我分析了下死锁过程：

• select语句使用非聚族索引查询产量信息，会对非聚族索引添加共享锁，因为非聚族索引上没有select的所有数据列，（因此会有书签查找出现，）须要查询产量表。查询产量表时，须要对产量表数据添加共享锁，须要等待Update语句更新完产量表后释放排他锁。即Select等待Update释放锁。
• 此时产量表上的Update/Insert语句更新产量信息的时候，会在聚族索引上作定位，添加排他锁和修改非聚族索引的信息，问题就出在修改非聚族索引信息的时候，须要对非聚族作索引添加排他锁。此时select语句已经在聚族索引上面添加了共享锁，须要释放后才能被添加排他锁。即update语句须要等待select语句是否锁。
• 这样死锁就造成了。

 

因而只要让查询语句加共享锁就解决问题了，sql server行版本级别控制能解决个人问题。

使用基于行版本控制的隔离级别：当在基于行版本控制的隔离下运行的事务读取数据时，读取操做不会获取正被读取的数据上的共享锁（S 锁）

找到最快设置行版本级别的方法：

 

if(charindex('Microsoft SQL Server 2008',@@version) > 0) 
begin 

declare @sql varchar(8000) 
select @sql = ' 
ALTER DATABASE ' + DB_NAME() + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE ; 
ALTER DATABASE ' + DB_NAME() + ' SET READ_COMMITTED_SNAPSHOT ON; 
ALTER DATABASE ' + DB_NAME() + ' SET MULTI_USER;' 

Exec(@sql) 
end 

很神奇，这样设置后，死锁的问题就不存在了。

 

查询是否设置成功：
select is_read_committed_snapshot_on from sys.databases where name = DB_Name()