公司有一个跑了N年的OLTP系统,使用的是sqlserver2008数据库,由于之前运维sqlserver的经验较少,权当oracle的方式在运维,数据库本身也并没做过什么优化,只是给了很大的内存;有一次突然用户反馈系统使用缓慢、卡死,于是先查看应用服务器日志,发现后台频繁刷报错日志:
死锁的典型报错,于是查看数据库的阻塞情况,通过sqlserver2008的活动监视器发现,数据库阻塞严重,等待类型均为等待获取S共享锁,被阻塞的SQL均为select
于是就奇怪了,查询为什么会执行这么久呢? 根据以往经验查询语句不会加锁,难道是查询SQL的性能太差了需要优化?于是抓取数据库中执行时间久的SQL,抓到了几条然后又建了索引,单条SQL跑是挺快的,觉得大功告成了,这时一看数据库性能数据,发现仍然阻塞严重,用户还是一直叫卡~~~,看来思路错了,这时继续在监视器中查看阻塞最久的会话的阻塞者ID,发现阻塞者居然是update,也就是说update阻塞了select。
发现这个问题以后,于是仔细的学习了下sqlserver有关MVCC和隔离级别相关知识,明白了原来在sqlserver中查询是需要加共享锁的,而Update需要获取排它锁,并发系统中在同一行记录会产生锁冲突,要解决这个问题可以开启sqlserver的行版本管理,在默认的提交读隔离级别中设置ALTER DATABASE thoms SET READ_COMMITTED_SNAPSHOT ON,打开快照读的功能
如此设置,select就不会被update阻塞了,加入了行版本控制,select可以根据事务ID和每行的头信息读取可见版本,是不是跟oracle的undo有异曲同工之妙哇!~
目前系统已经打开了 READ_COMMITTED_SNAPSHOT参数,数据库会话阻塞消失,用户反馈系统使用顺畅!
死锁的典型报错,于是查看数据库的阻塞情况,通过sqlserver2008的活动监视器发现,数据库阻塞严重,等待类型均为等待获取S共享锁,被阻塞的SQL均为select
于是就奇怪了,查询为什么会执行这么久呢? 根据以往经验查询语句不会加锁,难道是查询SQL的性能太差了需要优化?于是抓取数据库中执行时间久的SQL,抓到了几条然后又建了索引,单条SQL跑是挺快的,觉得大功告成了,这时一看数据库性能数据,发现仍然阻塞严重,用户还是一直叫卡~~~,看来思路错了,这时继续在监视器中查看阻塞最久的会话的阻塞者ID,发现阻塞者居然是update,也就是说update阻塞了select。
发现这个问题以后,于是仔细的学习了下sqlserver有关MVCC和隔离级别相关知识,明白了原来在sqlserver中查询是需要加共享锁的,而Update需要获取排它锁,并发系统中在同一行记录会产生锁冲突,要解决这个问题可以开启sqlserver的行版本管理,在默认的提交读隔离级别中设置ALTER DATABASE thoms SET READ_COMMITTED_SNAPSHOT ON,打开快照读的功能
如此设置,select就不会被update阻塞了,加入了行版本控制,select可以根据事务ID和每行的头信息读取可见版本,是不是跟oracle的undo有异曲同工之妙哇!~
目前系统已经打开了 READ_COMMITTED_SNAPSHOT参数,数据库会话阻塞消失,用户反馈系统使用顺畅!
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29018063/viewspace-1975432/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29018063/viewspace-1975432/