--死锁检测 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，或是磁盘文件。