1. 日常排查语句
- 1--当前正在执行的语句2 SELECT 3 der. [session_id],
- der. [blocking_session_id],
- 4 sp.lastwaittype,
- sp.hostname,
- sp.program_name,
- sp.loginame,
- 5 der. [start_time] AS'开始时间',
- 6 der. [status] AS'状态',
- 7 dest. [text] AS'sql语句',
- 8 DB_NAME(der. [database_id]) AS'数据库名',
- 9 der. [wait_type] AS'等待资源类型',
- 10 der. [wait_time] AS'等待时间',
- 11 der. [wait_resource] AS'等待的资源',
- 12 der. [logical_reads] AS'逻辑读次数'13 FROM sys. [dm_exec_requests] AS der 14 INNER JOIN master.dbo.sysprocesses AS sp ON der.session_id = sp.spid 15 CROSS APPLY sys. [dm_exec_sql_text](der. [sql_handle]) AS dest 16 WHERE[session_id] > 50 AND session_id < >@@SPID 17 ORDER BY der. [session_id] 18 GO 19 20--是否堵塞21 SELECT spid,
- blocked,
- waittime,
- waittype,
- waitresource,
- p.dbid,
- cpu,
- physical_io,
- memusage,
- open_tran 22,
- status,
- login_time,
- last_batch,
- hostname,
- program_name,
- hostprocess,
- loginame,
- cmd,
- text 23 FROM master.dbo.sysprocesses p CROSS APPLY sys.dm_exec_sql_text(p.sql_handle) s 24 WHERE blocked > 0 OR spid IN(SELECT blocked FROM master.dbo.sysprocesses WHERE blocked > 0) 25 go 26 27--是否有未提交事物28 select spid,
- blocked,
- waittime,
- waittype,
- waitresource,
- p.dbid,
- cpu,
- physical_io,
- memusage,
- open_tran 29,
- status,
- login_time,
- last_batch,
- hostname,
- program_name,
- hostprocess,
- loginame,
- cmd,
- text 30 from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) s 31 where open_tran < >0 32 go 33 34--死锁drop table#deadlock 35 CREATE TABLE#deadlock(LogDate DATETIME, ProcessInfo VARCHAR(20), Text VARCHAR(2000)) 36 go 37 INSERT INTO#deadlock EXEC xp_readerrorlog 0,
- 1,
- 'deadlock victim',
- NULL,
- '2016 - 07 - 20 14 : 00 : 00',
- '2016 - 07 - 30',
- 'DESC'38 go select * from#deadlock
发现较多进程正在等待某个表资源,从中查看是什么表。
- 1 waitresource/等待的资源 TAB: 7:1028198713:7
- 2 select OBJECT_NAME(1028198713)
同时看看有没有发生死锁,果然有死锁!(提前开启死锁跟踪: traceon(1222,-1))
死锁资源列表如下:
- 1 resource-list
- 2 objectlock lockPartition=27 objid=629577281 subresource=FULL dbid=7 objectname=MYDB.dbo.mytable id=lock1bdc37b280 mode=Sch-S associatedObjectId=629577281
- 3 owner-list
- 4 owner id=processe51d948 mode=Sch-S
- 5 owner id=processe4bf288 mode=Sch-S
- 6 waiter-list
- 7 waiter id=process2b95dcc508 mode=Sch-M requestType=wait
- 8 objectlock lockPartition=23 objid=629577281 subresource=FULL dbid=7 objectname=MYDB.dbo.mytable id=lock1bfb3d7680 mode=Sch-M associatedObjectId=629577281
- 9 owner-list
- 10 owner id=process2b95dcc508 mode=Sch-M
- 11 waiter-list
- 12 waiter id=process5c53dc8 mode=IS requestType=wait
- 13 objectlock lockPartition=19 objid=629577281 subresource=FULL dbid=7 objectname=MYDB.dbo.mytable id=lock1d20baba80 mode=Sch-M associatedObjectId=629577281
- 14 owner-list
- 15 waiter-list
- 16 waiter id=processe4bf288 mode=Sch-S requestType=wait
- 17 objectlock lockPartition=23 objid=629577281 subresource=FULL dbid=7 objectname=MYDB.dbo.mytable id=lock1bfb3d7680 mode=Sch-M associatedObjectId=629577281
- 18 owner-list
- 19 waiter-list
- 20 waiter id=processe51d948 mode=Sch-S requestType=wait
- 21 objectlock lockPartition=19 objid=629577281 subresource=FULL dbid=7 objectname=MYDB.dbo.mytable id=lock1d20baba80 mode=Sch-M associatedObjectId=629577281
- 22 owner-list
- 23 owner id=process2b95dcc508 mode=Sch-M
- 24 waiter-list
- 25 waiter id=processe480988 mode=IS requestType=wait
可以看到,出现了架构稳定锁(Sch-S)和架构修改锁(Sch-M),但是数据库没有人修改架构啊!查看审核信息也无人修改过表对象。什么原因??!
继续使用上面的排查语句进行多次查询,发现了一条特殊的语句!
- 1 insert bulk [dbo].[TABLES_Writes](此处省略字段)
果然是该语句了!大容量插入是要表级别的锁,并且也会出现架构锁。其他等待资源的进程,也是需要查询该表的,所以才出现了表级别的资源等待!而恰巧,要使用该表的是一个存储过程,也是比较复杂的,执行 10 秒以上,该存储过程使用的其实是一个视图,视图中包含了该表!暂时解决的话。在视图上加 nolock。询问开发人员,说大容量导入操作随时发生的,因为有些数据是需要业务员操作导入的。这种方法以后还是得改,要么大容量先插入到一个中间表,再插入到当前表中。
来源: http://www.bubuko.com/infodetail-1960455.html