阻塞与死锁(三)——死锁的定位及解决方法
2012-05-21 13:13
274 查看
死锁所在的资源和检测:
在SQL Server的两个或多个任务中,如果某个任务锁定了其他任务试图锁定的资源。会造成这些任务的永久阻塞,从而出现死锁。下图为例:
l 事务T1获得了行R1的共享锁。
l 事务T2获得了行R2的共享锁。
l 然后事务T1请求行R2的排它锁,但是T2完成并释放其对R2的共享锁之前被阻塞。
l T2请求行R1的排它锁,但是事务T1完成并释放其对R1持有的共享锁之前被阻塞。
现在T2与T1相互等待,导致了死锁。一般情况下监视器会自动检测并解决这个问题。
可以发生死锁的资源:
死锁不仅仅发生在锁资源上面,还会发生在一下资源上:l 锁。例如页、行、元数据和应用程序上的锁。
l 工作线程。如果排队等待线程的任务拥有阻塞所有其他工作线程的资源,也会导致死锁。
l 内存。当并发请求等待获得内存,而当前的可用内存无法满足其需要时,可能发生死锁。
l 并行查询执行的相关资源。当一个语句用到多个线程运行时,线程之间有可能发生死锁。
死锁检测:
默认5秒钟搜索SQL Server中的所有任务,检测是否有死锁。如果有,将选择一个作为牺牲品,并返回1205错误。一般是开销最小的事务作为牺牲品。死锁与阻塞的差别:
阻塞:当一个事务请求一个被其他事务锁定的资源上的锁时,发出请求的事务会一直等待下去,知道该锁被别人释放,自己能申请到位置。默认情况下除非设置了LOCK_TIMEOUT,否则事务会一直等待下去。
死锁:两个或多个进程之间的相互等待。但是由于SQL Server有数据库引擎死锁检测方案,至少5秒钟会消除一个现有的死锁。对性能的影响往往没有阻塞严重。
问题定位:
1、 跟踪标志1204和跟踪标志1222:打开跟踪的语句:
DBCC
TRACEON(1222,-1)
DBCC
TRACEON(1204,-1)
对于1222产生的结果解释:
1、 死锁牺牲的进程:第一句deadlockvictim=processXXXX,中的xxxx就是死锁牺牲品。
2、 死锁发生的进程信息:第二部分的process-list
3、 发生死锁的资源信息:在结果的resource-list中
2、 死锁图形事件:
从sqlserver profiler中得到,一般结合1222跟踪标志和sql trace。
首先从errorlog中寻找1222的输出结果,根据输出的时间在跟踪里找到相应的连接。然后分析原因。
解决办法:
尽管死锁不能完全避免,但是可以把机会降到最低:l 按同一顺序访问对象。
l 避免事务中的用户交互。
l 保持事务简短并处于一个批处理中。
l 使用脚底的隔离级别。
l 调整语句的执行计划,减少锁的申请数目。
按同一顺序访问对象:
如果所有并发事务按同一顺序访问对象,则发生死锁的可能性会降低。
避免事务中的用户交互:
避免编写包含用户交互的事务,因为没有用户干预的批处理的运行速度远快于必须等待用户响应时的查询速度。
保持事务简短并处于一个批处理中:
运行时间越长,等待时间就越长,造成死锁的机会就越高。
使用脚底的隔离级别:
确定事务能否在低隔离级别上运行。尽可能使用较低的隔离级别。
调整语句的执行计划,减少锁的申请数目:
可以从执行计划中找出哪些资源耗得比较多。此时锁的数目也会相应增多。
相关文章推荐
- 阻塞与死锁(三)——死锁的定位及解决方法
- 阻塞与死锁(三)——死锁的定位及解决方法
- 阻塞与死锁(三)——死锁的定位及解决方法
- 阻塞与死锁(三)——死锁的定位及解决方法
- 牛人笔记----(死锁问题定位与解决方法)
- sql server 2000阻塞和死锁问题的查看与解决方法
- Sys.SysProcesses 系统表是一个很重要的系统视图,主要用来定位与解决Sql Server的阻塞和死锁
- 安装win7的解决方法(“安装程序无法定位现有系统分区,也无法创建新的系统分区”)
- supermap学习系列之silverlight--添加可拖拽的定位图钉(方法二之超图自带类(Pushpin、InfoWindow)) 续 解决上一篇的问题
- I2C死锁原因及解决方法
- Oracle常见死锁发生的原因以及解决方法
- Mysql并发时经典常见的死锁原因及解决方法
- 什么是死锁及死锁的必要条件和解决方法【转】
- win7安装系统出现“安装程序无法创建新的系统分区,也无法定位现有的系统分区”解决方法
- oracle数据库死锁解决方法
- iOS中CoreLocation定位的代理方法不执行的解决办法。
- android发送模拟按键消息,出现死锁,timeout的解决方法
- 绝对定位元素被遮挡的解决方法
- Oracle中发生表加锁、死锁的原因,查看,与解决方法