SQL:查找被锁的表,以及锁表的SQL语句(重点推荐)

Posted 大西瓜3721

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SQL:查找被锁的表,以及锁表的SQL语句(重点推荐)相关的知识,希望对你有一定的参考价值。

复制代码
--死锁检测 
use master 
Select * from sysprocesses where blocked<>0 
--找到SPID   
exec sp_lock 
--根据SPID找到OBJID 
select object_name(85575343) 
--根据OBJID找到表名
复制代码

1.DatabaseName 同于你要监测的数据库名(不过这个好像不起作用,我的电脑上设置无效)
2.DatabaseID 同于你要检测的数据库的dbid,可以用 selectdb_id(N\'你要监测的库名\')得到dbid
3.ObjectName 同于你要监测的对象名,例如表名,视图名等
4.ObjectID 同于你要监测的对象的id,可以用 select object_id(N\'你要监测的对象名\')得到id
5.Error 同于错误,如果经常出现某个编号的错误,则针对此错误号
6.Seccess 同于0,失败,1,成功,如果是排错,就过滤掉成功的处理

select db_id(N\'ChinaHNDB_2013\') --得到dbid
select object_name(1813581499) 

 

 //*****************以下为SQL进行跟踪,并得到跟踪日志,再结合SQL Server Profiler 分析 *******************************

declare @rc int  
declare @TraceID int  
declare @FileName sysname
declare @maxfilesize bigint  
set @maxfilesize = 5   
SELECT @FileName = \'E:\\lock2\'

-- 初始化跟踪  
exec @rc = sp_trace_create @TraceID output, 0, @FileName, @maxfilesize, NULL   
--此处的e:/dblog/deadlockdetect是文件名(可自行修改),SQL会自动在后面加上.trc的扩展名  
if (@rc != 0) goto error 

-- 设置跟踪事件  
declare @on bit  
set @on = 1  
--下述语句中的148指的是locks:deadlock graph事件(参见sys.trace_events),12指的是spid列(参见sys.trace_columns)  
exec sp_trace_setevent @TraceID, 148, 12, @on    
exec sp_trace_setevent @TraceID, 148, 11, @on  
exec sp_trace_setevent @TraceID, 148, 4, @on  
exec sp_trace_setevent @TraceID, 148, 14, @on  
exec sp_trace_setevent @TraceID, 148, 26, @on  
exec sp_trace_setevent @TraceID, 148, 64, @on  
exec sp_trace_setevent @TraceID, 148, 1, @on 

-- 启动跟踪  
exec sp_trace_setstatus @TraceID, 1 

-- 记录下跟踪ID,以备后面使用  
select TraceID = @TraceID  
goto finish 

error:   
select ErrorCode=@rc 

finish:   
go 


exec sp_trace_setstatus 2, 0
exec sp_trace_setstatus 2, 2

select * from fn_trace_gettable(\'E:\\lock2.trc\',1)

/*
如果要暂停上面的服务器端跟踪,可运行下面的语句:
exec sp_trace_setstatus 3, 0 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为0,即暂停

如果要停止上面的服务器端跟踪,可运行下面的语句:
exec sp_trace_setstatus 3, 2 --第一个参数表示TraceID,即步骤1中的输出参数。第二个参数表示将状态改为2,即停止


对于上面生成的跟踪文件(e:/DbLog/deadlockdetect.trc),可通过两种方法查看:
1.
select * from fn_trace_gettable(\'e:/DbLog/deadlockdetect.trc\',1)
结果中的TextData列即以XML的形式返回死锁的详细信息。

2.
在SQL Server Profiler中打开。
依次 进入Profiler -> 打开跟踪文件 ->选择e:/DbLog/deadlockdetect.trc,就可以看到以图形形式展现的死锁信息了。

//*****************************************************************************************************

 

方法二: 用SQL Server Profiler分析死锁(重点推荐,2014-4-3编辑)

 

1. 打开 SQL Server Management Studio >>工具 >> SQL Server Profiler

2.创建一个新的跟踪

3.在事件选择页中,先勾选显示所有事件,再选择“死锁图形”事件、 “锁定:死锁”和“锁定:死锁链” (Deadlock graph,Lock:Deadlock;Lock:Deadlock Chain )如下图所示:

 

,最后 取消其它默认事件选项((Deadlock graph,Lock:Deadlock;Lock:Deadlock Chain 以外事件) ,并运行。

 

 4. 跟踪一段时间,事务执行中止结束,选择Deadlock graph,我们可以直观查看到事务之间发生死锁的原因:

上图的椭圆形有一个叉,表示事务被SQL Server选择为死锁牺牲品,如果我们把鼠标指针移动到该叉椭圆中会出现一个提示。被锁定Object 为Proc存储过程(可以根据ID ,select object_id(N\'ID)

 

二个矩形框称为资源节点,它们代表的数据库对象,如表,行或索引。

由于事务A和B在拥有各自资源时试图获得对方资源的一个独占锁,使得进程相互等待对方释放资源从而导致死锁。

 

解决死锁

这里有几个方法可以帮助我们解决死锁问题。

      优化查询

 

      我们在写查询语句时,要考虑一下查询是否Join了没有必要的表?是否返回数据太多(太多的列或行)?查询是否执行表扫描?是否能通过调整查询次序来避免死锁?是否应该使用Join的地方使用了Left Join?Not In语句是否考虑周到?

 

      我们在写查询语句可以根据以上准则来考虑查询是否应该做出优化。

 

      慎用With(NoLock)

 

      默认情况下SELECT语句会对查询到的资源加S锁(共享锁),由于S锁与X锁(排他锁)不兼容,在加上With(NoLock)后,SELECT不对查询到的资源加锁(或者加Sch-S锁,Sch-S锁可以与任何锁兼容);从而使得查询语句可以更好和其他语句并发执行,适用于表数据更新不频繁的情况。

 

     也许有些人会提出质疑With(NoLock),可能会导致脏读,首先我们要考虑查询的表是否频繁进行更新操作,而且是否要读回来的数据会被修改,所以衡量是否使用With(NoLock)还是要根据具体实际出发。

 

     优化索引

 

     是否有任何缺失或多余的索引?是否有任何重复的索引?

 

     处理死锁

 

     我们不能时刻都观察死锁的发生,但我们可以通过日志来记录系统发生的死锁,我们可以把系统的死锁错误写入到表中,从而方便分析死锁原因。

 

     缓存

 

     也许我们正在执行许多相同的查询非常频繁,如果我们把这些频繁的操作都放到Cache中,执行查询的次数将减少发生死锁的机会。我们可以在数据库的临时表或表,或内存,或磁盘上应用Cache,或是磁盘文件。

以上是关于SQL:查找被锁的表,以及锁表的SQL语句(重点推荐)的主要内容,如果未能解决你的问题,请参考以下文章

查看Sql Server被锁的表以及解锁

MySQL锁表和解锁操作

数据库查询锁表以及解锁表的sql

查看oracle锁的表名

查看SQL Server被锁的表以及如何解锁

Oracle查询被锁的表及解锁方法