公司有一个跑了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参数，数据库会话阻塞消失，用户反馈系统使用顺畅！