欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

sqlserver阻塞定位(转载)

程序员文章站 2022-04-09 13:02:01
...

很多人都遇到过这样的情况,当网站达到一定的访问量,数据库就会成为瓶颈,进而引起阻塞。 有人认为这可能就是硬件的极限了,于是想办法增加硬件设备。而我本人认为问题的元凶可能是性能不高的sql脚本,引起了阻塞。 如果你和我有相同的看法,那我们就一起想

很多人都遇到过这样的情况,当网站达到一定的访问量,数据库就会成为瓶颈,进而引起阻塞。

有人认为这可能就是硬件的极限了,于是想办法增加硬件设备。而我本人认为问题的元凶可能是性能不高的sql脚本,引起了阻塞。

如果你和我有相同的看法,那我们就一起想办法找出问题的源头。

案例1.

某一天我被告知,我们的书城网站不能访问了,我马上查看,发现书城的有两台iis服务器均显示service unavailable,我初步断定是sqlserver数据库发生了阻塞,因为同一套程序使两台iis服务器同时当机的可能性不大。

要知道是否发生了阻塞,当然要看master库的sysprocess表,看看是否有什么进程堵住了别的进程,语句如下:

Select * from master..sysprocesses where blocked > 0

很快我发现,有一个blocked = 51 堵住了很多进程(查看blocked列可见),果然和我的判断吻合;为了进一步找出发生阻塞的语句,我用到的如下的语句

dbcc inputbuffer(51);

结果如下:

EventType Parameters EventInfo

------------------------------------------------

RPC Event 0 p_Book_content;1

从上面就可以看出是p_Book_content (是个存储过程)引起的阻塞,但是这个过程里面同时对多个表进行了操作,到底是那个语句出了问题呢?

下面我们再来进一步定位阻塞的位置:

Sp_lock

结果如下(大部分数据略)

Spid dbid objid indid type resource mode status

-------------------------------------------------------------------------------------------------

51 14 206623779 0 TAB X WAIT

52 14 0 0 DB S GRANT

53 14 0 0 DB S GRANT

。。。

。。。

。。。

现在我们来看看spid = 51 这行, mode = X 表示排它锁, status = WAIT表示正在等待(即被阻塞了),dbid = 14 是数据库的id,objid = 206623779 是被锁的对象id,我们可以通过下列函数得到数据库和表:

Select db_name(@dbid) -----》book_db

select object_name(@objid) -------》 t_book

即book_db库的t_book表被锁住了,这时候再回投仔细检查 p_Book_content 存储过程,发现只有一个语句对t_book进行了操作:

update t_book set hitcount = hitcount + 1 where bookid = @bookid

这个语句的作用是更新书本的点击次数,为什么上面这个语句会引起阻塞呢?我认为最可能的情况应该是同时访问的人过多,同时对表进行过多的update操作引起的,所以最终改用别的方式,不再实时对t_book表进行update操作,而是每次访问都先insert一条记录到一个中间表中,然后再用一个作业,每隔10分钟定时更新书本的点击次数,如此改进之后,此问题终于圆满解决了。

相关资料在book online可以找到, 关键字: sp_lock , sysprocesses , dbcc inputbuffer , db_name(), object_name()

注:原来发在csdn的,现在荒芜了,挪到这边来栽培一下。