SQLSERVER排查阻塞

系统教程400 更新时间：2025-09-07 04:15:43

2024年4月6日发(作者：)

SQL Server允许并发操作，BLOCKING是指在某一操作没有完成之前，其他操作

必须等待，以便于保证数据的完整性。BLOCKING的解决方法要查看BLOCKING的

头是什么，为什么BLOCKING头上的语句执行的很慢。通常来讲只要我们能找到

BLOCKING头上的语句，我们总能够想出各种各种的办法，来提升性能，缓解或

解决BLOCKING的问题。

但是问题的关键是，我们不知道BLOCKING什么时候会发生。用户跟我们抱怨数

据库性能很差，等我们连上数据库去查看的时候，那时候有可能BLOCKING可能

就已经过去了。性能又变好了。或者由于问题的紧急性，我们直接重新启动服务

器以恢复运营。但是问题并没有最终解决，我们不知道下次问题会在什么时候发

生。

BLOCKING问题的后果比较严重。因为终端用户能直接体验到。他们提交一个订

单的时候，无论如何提交不上去，通常几秒之内能完成的一个订单提交，甚至要

等待十几分钟，才能提交完成。更有甚者，极严重的BLOCKING能导致SQL Server

停止工作。如下面的SQL ERRORLOG所表示, 在短短的几分钟之内，SPID数据从

158增长到694, 并马上导致SQL Server打了一个dump, 停止工作。我们很容

易推断出问题的原因是由于BLOCKING导致的，但是我们无法得知BLOCKING

HEADER是什么，我们必须要等下次问题重现时，辅之以工具，才能得知BLOCKING

HEADER在做什么事情。如果信息抓取时机不对，我们可能要等问题发生好几次，

才能抓到。这时候，客户和经理就会有抱怨了。因为我们的系统是生产系统，问

题每发生一次，都会对客户带来损失。

2011-06-01 16:22:30.98 spid1931 Alert There are 158 Active database sessions which is too high.

2011-06-01 16:23:31.16 spid3248 Alert There are 342 Active database sessions which is too high.

2011-06-01 16:24:31.06 spid3884 Alert There are 517 Active database sessions which is too high.

2011-06-01 16:25:31.08 spid3688 Alert There are 694 Active database sessions which is too high.

2011-06-01 16:26:50.93 Server Using '' version '4.0.5'

2011-06-01 16:26:50.97 Server **Dump thread - spid = 0, EC = 0x0000

2011-06-01 16:26:50.97 Server ***Stack Dump being sent to

D: