版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/weixin_38357227/article/details/79208502
今天在给数据表字段做长度变更时,遇到一点问题.由于是生产环境,在为该表做变更操作时刻意挑的操作低峰时段.正常10m左右可以完成的操作执行了20分钟左右还是正在执行中.查询会话状态,发现该会话状态是suspended,等待类型是PAGEIOLATCH_EX.
查看网上对该等待类型的解释，原来是数据页没有缓存在内存里。SQL Server在缓冲池里找到一个页面的空间，在上面申请一个EX的latch，防止数据从磁盘里读出来之前，有别人也来读取或修改这个页面。对整个page加锁相当于是在内存中预定了一片空间用于存放需要从磁盘中physical read来的page。
（详细链接：http://www.cnblogs.com/xwdreamer/archive/2012/08/30/2663232.html）
为防止造成大量堵塞，影响业务，KILL掉该进程，发现此时该会话状态变成下图状态
使用语句kill 483with statusonly 查看回滚进度，返回信息如下：
10分钟后查看回滚进度，仍旧显示此状态。网上搜索发现几乎所有网友的解决办法都是重启服务。但是重启服务会导致部分操作无效，可能会造成数据丢失，不到万不得已，最好不要重启服务。
此时查看数据库堵塞信息，发现已造成大量堵塞，堵塞语句主要是读取系统表获取表结构的SQL语句。
想到对于该等待类型的解释，我kill掉了正在进行的SELECT操作会话，降低IO压力，等了几分钟，该会话回滚完成。
作为一个小白，我想起曾经有人和我说：不经历过惊魂时刻都不是好DBA，每一次惊魂，对于DBA都是 get stronger的过程。现在我感触颇深。遇到问题不要慌，不要急，要抓住细节，从源头分析，这样才能命中问题，