SQL2005中的事务与锁定（七）
作者 佚名技术
来源 数据库编程
浏览
发布时间 2012-03-22
| 干预进来，我们所能感知比如接收到1205号错误，健壮的应用系统会人工干预1205错误，恰当的重新提交批处理，当1205错误发生没有终止的进程获得相应的资源并处理自己的事务直至释放资源，其实这种人为的干预潜在的又为死锁提供一个外在环境。当然我们前面写的一个过程也可以查询到相应的锁定信息。 接着，死锁是无法完全避免的。在一个并发的多用户系统，锁定、线程、内存、并行查询、MARS中死锁的发生是正常的、可以预见的，也是必然的。在我们能力范围内只能尽可能的在应用端或服务器上恰当的处理死锁，使得这种无法完全避免的事件给系统带来的影响降到最低。也就是我们应该明白：死锁是无法完全避免，但是我可以降低发生的次数。 第三，死锁是一种末日，没有人为干预时永远退不出这种状态。一个并发的多用户系统这种竞争资源的可能性是很大的，一有竞争就会有“矛盾”发生，双方等待对方释放自己所需要的资源，必然成了无限期等待，这种等待就是我们所说的死锁。我们通过上面的介绍知道这时SQLSERVER锁管理器会干预这个过程，试想如果没有SQLSERVER锁管理器的干预那么两个进程一根筯的结果就是无限期等待，对于应用系统来说就是一个末日。SQLSERVER2005更是提供了丰富的锁有关元数据，可以很方便的侦察出锁定信息，SQLSERVER锁管理器干预的结果就是根据牺牲品的优先等级及回滚代价，把优先级低和代价最小的进程当作牺牲品，杀掉这个进程并抛出1205错误。 第四，死锁大体分为三类：cycle死锁、conversion死锁、应用级死锁及不明死锁。 Cycle死锁：是进程双方持有的排它性资源是另外一方想要的资源。比如说进程A拥有TA的表级排它锁这时它又想申请TB的排它锁，同时进程B先拥有TB的排它锁定也想申请TA的表级排它锁定，这是进程A想要TB的排它锁但是已经让进程B锁定，进程B想要的TA锁定也已经让进程B锁定，这时死锁发生，下面我们来模拟一下： create table ta(id int,col varchar(10)) create table tb(id int,col varchar(10)) go 查询一： BEGIN TRAN UPDATE TB SET COL = ''A'' WAITFOR DELAY ''00:00:05'' UPDATE TA SET COL = ''B'' --COMMIT TRAN 查询二： BEGIN TRAN UPDATE TA SET COL = ''A'' WAITFOR DELAY ''00:00:05'' EXEC SP_US_LOCKINFO –-在死锁前获取锁的信息 UPDATE TB SET COL = ''B'' --COMMIT TRAN 执行顺序先运行行查询一立即切换查询二执行，得死锁前的锁定信息，我们列出部分锁定信息： 由上图我们可以看得出，一开始查询一和查询二分别获得了TB TA上的锁定，行号为20和25的记录我们可以看到分别获得了排它锁定（我仅说明RID,在表和页上也会相应的锁定），因为查询一行执行，那么5S后，它想更新TA，这时阻塞发生，我们从记录26可以看到SPID＝53的进程想要获取表TA上行的更新锁定被SPID＝52的进程阻塞，而进入等待状，注意这时不是死锁哦，是等待哦，紧接查询二5S过了开始执行更新TB上的记录行，显然这个时候TB给进程53排它锁定，这是死锁发生，因为进程52等待53释放TB上的锁定，进程53在等待52释放资源，进入了抱死状态，这就是cycle锁定。这时我们会SQLSERVER参与了干预，查询二抛出错误并回滚事务： 消息1205，级别13，状态45，第8 行 事务(进程ID 52)与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品。请重新运行该事务。 为什么说它回滚呢，这是死锁发生时SQLSERVER自动处理的，不信你最后提交查询二的commit语句，你会发现报如下错（3902）： 消息3902，级别16，状态1，第1 行 COMMIT TRANSACTION 请求没有对应的BEGIN TRANSACTION。 conversion死锁： |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
你可能对下面的文章感兴趣
关于SQL2005中的事务与锁定（七）的所有评论
