正在进行事务回滚.估计回滚已完成:0%.估计剩余时间:0秒.

版权声明:本文为博主原创文章,未经博主允许不得转载。 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的过程。现在我感触颇深。遇到问题不要慌,不要急,要抓住细节,从源头分析,这样才能命中问题,

没有更多推荐了,返回首页