SQL Server和Oracle中的锁和死锁（二）

最新推荐文章于 2024-01-08 13:09:55 发布

stupen

最新推荐文章于 2024-01-08 13:09:55 发布

阅读量152

点赞数

本文链接：https://blog.csdn.net/stupen/article/details/83372559

版权

数据库专栏收录该内容

5 篇文章 0 订阅

订阅专栏

导读：本文就SQL SERVE和ORACLE常出现的锁和死锁的检测和解决方法进行了全面比较,比较内容包括锁的作用、锁的模式……

　　3、死锁

　　死锁就是两个进程都在等待对方持有的资源锁，要等对方释放持有的资源锁之后才能继续工作，它们互不相让，坚持到底，实际上，双方都要等到对方完成之后才能继续工作，而双方都完成不了。

　　Oracle死锁样本：

　　步骤一：

　　登陆ORACLE SQL *plus 之一窗口，执行：

　　update HR.JOBS

　　SET JOB_title = ’S.Finance Manager’

　　where job_id = ’FI_MGR’

　　步骤二：

　　登陆ORACLE SQL *plus 之二窗口，执行：

　　update HR.JOBS

　　SET JOB_title = ’S.President’

　　where job_id = ’AD_PRES’;

　　步骤三：

　　重新ORACLE SQL *plus 之一窗口，执行

　　update HR.JOBS

　　SET JOB_title = ’S.President’

　　where job_id = ’AD_PRES’;

　　发现已经无法完成，因为在等待资源释放。

　　步骤四：

　　登陆ORACLE SQL *plus 之二窗口，执行：

　　update HR.JOBS

　　SET JOB_title = ’S.Finance Manager’

　　where job_id = ’FI_MGR’

　　此时出现ORA-00060错误,如下图所示：

　　 ORA—00060错误

　　发现报出错误，系统检测到死锁，此时打开C:\oracle\admin\ORADB\udump\的oradb_ora_5528文件会发现已经记录了死锁deadlock日志，文字如下：

*** 2008-07-05 16:46:43.000
*** SESSION ID:(17.16) 2008-07-05 16:46:43.000
DEADLOCK DETECTED
Current SQL statement for this session:
update  HR.JOBS
SET JOB_title  = ’S.President’
where job_id = ’AD_PRES’
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
infromation may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-000a0002-00001904        16      17     X             17      18           X
TX-00010010-00001917        17      18     X             16      17           X
session 17: DID 0001-0010-00000003 session 18: DID 0001-0011-00000003
session 18: DID 0001-0011-00000003 session 17: DID 0001-0010-00000003
Rows waited on:
Session 18: obj - rowid = 00007339 - AAAHM5AAFAAAABGAAD
(dictionary objn - 29497,file- 5, block - 70, slot - 3)
Session 17: obj - rowid = 00007339 - AAAHM5AAFAAAABGAAA
(dictionary objn - 29497, file - 5, block - 70, slot - 0)
Information on the OTHER waiting sessions:
Session 18:
pid=17 serial=20 audsid=0 user: 0/SYS
O/S info: user: WANGTM\wangtm, term: WANGTM, ospid: 5200:4876, machine: WORKGROUP\WANGTM
prigram: sqlplusw.exe
Current SQL Statement:
update  HR.JOBS
SET JOB_title  = ’S.Finance Manager’
where job_id = ’FI_MGR’ 
End of information on OTHER waiting sessions.

　　SQL Server死锁样本：

　　死锁使事务中止时，SQL Server向客户机返回错误号1205，由于死锁不是逻辑错误，而只是资源争夺问题，因此客户机可以更新提交整个事务，要在应用程序中处理死锁，要在错误处理器中捕获消息1205。遇到消息1205时，应用程序可以自动重新提交事务，最好不要然用户看到SQL Server返回的死锁错误消息。

　　我们知道可以通过SP_lock和SP_who监视进程之间的锁争用，但是，一旦出现死锁，一个事务回退，一个事务继续。此时使用sp_lock已经看不到真正死锁的资源信息(或许能够看许多X类型的锁信息)，因为所涉及资源的锁已经释放。

　　SQL SERVER 提供了几个跟踪标志，可以监视出现的死锁。可以用DBCC TRACEON命令打开跟踪标志，用DBCC TRACEOFF关闭跟踪标志，要然SQL SERVER把死锁跟踪标志的输出写入到错误日志中。首先要设置DBCC TRACEON(3605)，比如：

　　DBCC TRACEON(3605)

　　DBCC TRACEON(1204)

　　这样，一旦出现死锁，将能在错误日志中监视到相关明细信息。