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错误,如下图所示：
发现报出错误，系统检测到死锁，此时打开C:oracleadminORADBudump的oradb_ora_5528文件会发现已经记录了死锁deadlock日志，文字如下：
*** 2008-07-05 16:46:43.000*** SESSION ID:(17.16) 2008-07-05 16:46:43.000DEADLOCK DETECTEDCurrent SQL statement for this session:update HR.JOBSSET JOB_title = ’S.President’where job_id = ’AD_PRES’The following deadlock is not an ORACLE error. It is adeadlock due to user error in the design of an applicationor from issuing incorrect ad-hoc SQL. The followinginfromation may aid in determining the deadlock:Deadlock graph:---------Blocker(s)-------- ---------Waiter(s)---------Resource Name process session holds waits process session holds waitsTX-000a0002-00001904 16 17 X 17 18 XTX-00010010-00001917 17 18 X 16 17 Xsession 17: DID 0001-0010-00000003 session 18: DID 0001-0011-00000003session 18: DID 0001-0011-00000003 session 17: DID 0001-0010-00000003Rows 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/SYSO/S info: user: WANGTMwangtm, term: WANGTM, ospid: 5200:4876, machine: WORKGROUPWANGTMprigram: sqlplusw.exeCurrent SQL Statement:update HR.JOBSSET 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)
这样，一旦出现死锁，将能在错误日志中监视到相关明细信息。
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
云端SQL Server高可用性最佳做法
与内部部署相比，在云端运行SQL Server可为数据库软件用户提供更多的灵活性和可扩展性，也可能更省钱。但云 […]
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列，而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库（O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢？TechTarget数据库网站将与您分享12月份的榜单排名情况，让我们拭目以待。
-
2017年11月数据库流行度排行榜 半数以上数据库积分减少
数据库知识网站DB-engines更新了2016年11月份的数据库流行度排行榜。TechTarget数据库网站将与您一同关注11月份的榜单排名情况。