Oracle常见死锁发生的原因以及解决方法
如何处理数据库中的死锁问题(五)
在开发和运维数据库系统的过程中，经常会遇到死锁问题。
死锁是指两个或多个进程在执行过程中，互相请求对方所持有的资源，同时又拒绝释放自己持有的资源，导致彼此都无法继续执行的情况。
如何处理数据库中的死锁问题成为数据库管理员和开发人员必须重视的一个方面。
1. 死锁问题的原因分析死锁问题主要是由于并发访问数据库中的共享资源时，对资源先后次序的控制不当引起的。
当多个进程需要同时访问同一个资源时，通过资源锁机制来保证数据的一致性和完整性。
然而，如果没有良好的资源访问控制策略，就容易导致死锁问题的发生。
2. 死锁问题的识别为了解决死锁问题，首先需要能够识别出死锁的存在。
数据库系统通常会提供一些工具和机制来帮助识别死锁，如死锁检测器。
死锁检测器可以追踪资源的分配和请求情况，以及进程的等待关系，并根据这些信息判断是否存在死锁。
3. 死锁问题的解决方法一旦识别出死锁问题的存在，就需要采取相应的解决方法来消除死锁。
以下是一些常用的死锁解决方法：a. 死锁超时机制死锁超时机制是一种简单但有效的解决方法。
当进程在一定时间内无法获得所需资源时，可以通过设置超时时间来主动放弃并重新尝试获取资源，以避免长时间的无谓等待。
b. 死锁检测与恢复死锁检测与恢复是一种较为复杂但比较全面的解决方法。
通过定期或实时地检测死锁的存在，然后采取相应的恢复策略。
常见的恢复策略有终止进程、回滚事务等。
c. 死锁预防死锁预防是一种在设计数据库系统时就考虑和解决死锁问题的方法。
通过合理的资源分配策略、避免不必要的资源竞争等手段来预防死锁的发生。
d. 死锁避免死锁避免是基于资源请求的动态分配的原则，根据当前系统状态和资源请求情况，通过预测资源请求的未来走向来避免潜在的死锁。
这需要对系统状态和资源请求进行动态调整和优化。
4. 其他注意事项处理数据库中的死锁问题还需要注意以下几个方面：a. 优化数据库设计合理的数据库设计在很大程度上可以减少死锁问题的发生。
通过合理的表和索引设计，可以降低并发事务对同一资源的竞争。
oracle死锁一例
死锁一例：应用程序报错图片：客户应用基于odbc与sybase数据库连接，数据库错误信息通过odbc传回。
错误信息：操作发生死锁，请重试。
死锁的产生原因：SQL server中的死锁：注：4个update语句的执行顺序按图中位置自上而下图中左边的会话得以执行，右边会话作为死锁的牺牲者回滚。
Oracle中的死锁：注：4个update语句的执行顺序按图中位置自上而下图中左边会话中断(此时不回滚也不提交，等待用户决定)，右边会话阻塞，等待左边会话释放a表上的锁。
如图：死锁解决方法：修改应用！参考以下方法。
1、将死锁减至最少虽然不能完全避免死锁，但可以使死锁的数量减至最少。
将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务：∙回滚，而回滚会取消事务执行的所有工作。
∙由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：∙按同一顺序访问对象。
∙避免事务中的用户交互。
∙保持事务简短并在一个批处理中。
∙使用低隔离级别。
∙使用绑定连接。
2、按同一顺序访问对象如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。
例如，如果两个并发事务获得Supplier表上的锁，然后获得Part表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在Supplier表上。
第一个事务提交或回滚后，第二个事务继续进行。
不发生死锁。
将存储过程用于所有的数据修改可以标准化访问对象的顺序。
3、避免事务中的用户交互避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。
例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。
这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。
即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
4、保持事务简短并在一个批处理中在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。
ORACLE 数据库故障解决方案
ORACLE 数据库故障解决方案一、引言在使用ORACLE数据库的过程中，难免会遇到各种故障，这些故障可能导致数据库无法正常运行，影响业务的连续性和数据的完整性。
因此，本文将介绍一些常见的ORACLE数据库故障，并提供相应的解决方案，以帮助管理员和开发人员快速恢复数据库运行。
二、故障类型及解决方案1. 数据库无法启动故障现象：尝试启动数据库时，遇到错误提示，无法成功启动。
解决方案：1) 检查数据库实例是否正常关闭，如果没有正常关闭，使用SHUTDOWN命令关闭数据库实例。
2) 检查数据库参数文件是否正确配置，确保参数文件路径正确，参数设置正确。
3) 检查数据库控制文件是否损坏，如果损坏，可以尝试恢复备份的控制文件。
4) 检查数据库日志文件是否损坏，如果损坏，可以尝试恢复备份的日志文件。
5) 检查数据库文件是否损坏，如果损坏，可以尝试恢复备份的数据文件。
2. 数据库性能下降故障现象：数据库查询响应时间延长，业务处理变慢。
解决方案：1) 分析数据库性能指标，如CPU利用率、内存利用率、磁盘IO等，找出性能瓶颈。
2) 优化SQL语句，如添加索引、重写查询语句等，提高查询效率。
3) 调整数据库参数，如增加SGA大小、调整PGA大小等，优化内存使用。
4) 分析数据库锁等待情况，解决锁冲突问题，提高并发处理能力。
5) 定期收集数据库统计信息，重新生成优化器统计信息，提高查询计划的准确性。
3. 数据库备份恢复故障现象：数据库数据丢失或损坏，需要进行数据恢复。
解决方案：1) 检查数据库备份情况，如果有可用的备份，可以尝试进行恢复操作。
2) 使用RMAN工具进行数据库备份和恢复操作，可以选择完全恢复或部分恢复。
3) 如果没有备份，可以尝试使用闪回技术进行数据恢复，还原到历史状态。
4) 如果数据文件损坏，可以尝试使用数据文件的备份进行恢复，或者使用RMAN进行数据文件的恢复。
5) 恢复完成后，进行数据一致性检查，确保数据库的完整性。
Oracle死锁问题及解决办法
Oracle死锁问题及解决办法死锁通常是2个及以上线程共同竞争同⼀资源⽽造成的⼀种互相等待的僵局。
我们看下图所⽰场景。
线程1执⾏的事务先更新资源1，然后更新资源2。
线程2涉及到的事务先更新资源2，然后更新资源1。
这种情况下，很容易出现你等我我等你，导致死锁。
我⽤Oracle数据库来模拟这种场景的死锁。
●service类如下PayAccountServiceMock类， up⽅法和up2⽅法，这2个⽅法使⽤了spring事务，逻辑是根据账户id来更新两条账户的⾦额。
不过，两个⽅法更新两条账户记录的顺序是相反的。
我们⽤后⾯的testcase很容易就能模拟出Oracle死锁。
package com.xxx.accounting;import org.springframework.transaction.annotation.Transactional;@Service@Slf4jpublic class PayAccountServiceMock {@Autowiredprivate TAccTransService tAccTransService;@Transactionalpublic void up() throws InterruptedException {tAccTransService.updateBalance("89900000426016346075");Thread.sleep(RandomUtils.nextInt(100, 300));select("89900000426016346075");tAccTransService.updateBalance("PF00060");}@Transactionalpublic void up2(TAccTrans at4) throws InterruptedException {tAccTransService.updateBalance("PF00060");Thread.sleep(550);tAccTransService.updateBalance("89900000426016346075");}@Transactionalpublic void select(String id) {tAccTransService.selectByPrimaryKey(id);try {Thread.sleep(1100);} catch (InterruptedException e) {e.printStackTrace();}}}View Code●testcase类如下Junit测试类，使⽤倒计数门栓（CountDownLatch，就是JUC包下倒计时门栓，个⼈觉得⽤“倒计数门栓”感觉更合适~）来保证多线程同时执⾏，达到并⾏处理的效果。
数据库死锁的检测与解决技巧
数据库死锁的检测与解决技巧数据库死锁是在多用户并发访问数据库时可能发生的一种情况，它会导致数据库无法继续正常执行操作。
在日常的数据库管理中，必须及时发现和解决死锁问题，以确保数据库的稳定性和可用性。
本文将介绍数据库死锁的检测与解决技巧。
一、死锁的定义与原因1. 死锁的定义：死锁是指两个或多个事务互相等待对方所持有的资源，而导致它们在无外力介入的情况下都无法继续执行的状态。
2. 死锁的原因：死锁通常发生在多个事务同时在数据库中申请资源时。
以下为常见的死锁原因：(1) 彼此互斥的资源：多个事务需要使用彼此互斥的资源。
(2) 事务保持资源并等待：一个事务保持资源并等待其他事务所持有的资源。
(3) 循环等待：多个事务形成一个闭环，每个事务等待下一个事务所持有的资源。
二、死锁的检测技巧1. 手动查询：可以通过查询系统视图或工具来检测是否存在死锁情况。
例如，在MySQL中，可以通过执行"show engine innodb status"命令来获取相关信息。
2. 使用系统工具：大多数数据库管理系统都提供了相关的工具来检测和解决死锁问题。
例如，在Oracle中，可以使用AWR报告来识别死锁情况。
3. 使用第三方工具：如果数据库管理系统的自带工具无法满足需求，可以考虑使用第三方工具来进行死锁检测。
一些常用的第三方工具包括Percona Toolkit和pt-deadlock-logger等。
三、死锁的解决技巧1. 重构数据库设计：死锁问题可能是由于数据库设计不合理导致的。
通过对数据库模式、索引和查询进行优化，可以减少死锁的发生概率，从而提高数据库的性能和可用性。
2. 事务隔离级别的选择：选择合适的事务隔离级别对于降低死锁的风险是至关重要的。
较高的隔离级别会导致更多的锁冲突和死锁发生机会，而较低的隔离级别可能影响数据的一致性和并发性。
需要在性能和数据一致性之间做出权衡选择。
3. 降低事务的持有时间：较长时间的事务可能会增加死锁的风险。
解决Oracle死锁问题，及产生的原因
解决Oracle死锁问题，及产⽣的原因
⽂章来源：
最近⽼是发现应该执⾏操作数据库的代码时发现执⾏不了，查了⼀下发现是数据库表锁死的原因，
，纠其原因，发现有些同事操作数据库时⽼是喜欢⽤select * from XXX for update
去操作数据库，有的操作了⼜没有COMMIT 所以导致数据库锁死，笔都建议⼤家不⽤，如果要⽤for update 之后请你记得提交解决死锁的⽅法
第⼀步：找到数据库中被锁死的表
select object_id,session_id,locked_mode from v$locked_object;
第⼆步：找到表的SID SERIAL#
select ername,t2.sid,t2.serial#,t2.logon_time
from v locked o bjectt1,v session t2
where t1.session_id=t2.sid order by t2.logon_time;
第三步：强杀锁死的表
alter system kill session 'sid,serial#';
另：Oracle９I以后的版本有⾃动处理锁死表的能⼒！
Processing math: 100%。
解决Oracle数据库死锁
解决Oracle数据库死锁解决Oracle数据库死锁2011年01月12日星期三08：35 P.M.解决Oracle数据库死锁介绍本文我们尝试总结在多个用户并发情况下，如何识别和解决删除操作期间发生的死锁问题，在开始之前，我们先简单描述一下什么是死锁以及什么东西会导致死锁。
死锁在任何数据库中发生死锁都是不愉快的，即使是在一个特殊的情况下发生也是如此，它们会减小应用程序的接受程度(ACCEPTANCE)，因此避免并正确解释死锁是非常重要的。
当两个或更多用户相互等待锁定的数据时就会发生死锁，发生死锁时，这些用户被卡住不能继续处理业务，Oracle自动检测死锁并解决它们(通过回滚一个包含在死锁中的语句实现)，释放掉该语句锁住的数据，回滚的会话将会遇到Oracle错误"ORA-00060：等待资源时检测到死锁"。
是什么导致了死锁?明确地锁定表是为了保证读/写一致性，未建立索引的外键约束，在相同顺序下表不会锁住，没有为数据段分配足够的存储参数(主要是指INITTRANS，MAXTRANS和PCTFREE参数)很容易引发突发锁和死锁，原因是多种多样的，需要重新逐步审查。
识别死锁当Oracle数据库检测到死锁时(Oracle错误消息：ORA-00060)，相应的消息就写入到警告日志文件中(alert.log)，另外还会在USER_DUMP_DEST目录下创建一个跟踪文件，分析警告日志文件和跟踪文件是非常耗时的。
下面是一个警告日志文件示例：Mon Aug 07 09：14：42 2007 ORA-000060：Deadlock detected.Moreinfo in file e：\oracle\admin\GEDEON\udump\ORA01784.TRC.下面是从跟踪文件中节选出来的片段，从其中我们可以看出是哪个语句创造了死锁，相关的语句和被锁定的资源已经标记为粗体。
/users/ora00/log/odn_ora_ 1097872.trc Oracle9i Enterprise Edition Release 9.2.0.8.0-64bit Production With the Partitioning,OLAP and Oracle Data Mining options JServer Release 9.2.0.8.0-Production ORACLE_HOME=/soft/ora920 System name：AIX Node name：beaid8 Release：2 Version：5 Machine：00C95B0E4C00 Instance name：ODN Redo thread mounted by this instance：1 Oracle process number：17 Unix process pid：1097872,image：oracle@beaid8(TNS V1-V3)*2007-06-04 14：41：04.080*SESSION ID：(10.6351)2007-06-04 14：41：04.079 DEADLOCK DETECTED(ORA-00060)The following deadlock is not an ORACLE error.It is adeadlock due to user error in the design of an application orfrom issuing incorrect ad-hoc SQL.The following information may aidin determining the deadlock：Deadlock graph：---Blocker(s)-----Waiter(s)---Resource Name process session holds waits process session holds waits TM-00001720-00000000 17 10 SX 16 18 SX SSX TM-0000173a-00000000 16 18 SX 17 10 SX SSX session 10：DID 0001-0011-00000002session 18：DID 0001-0010-00000022 session 18：DID 0001-0010-00000022session 10：DID 0001-0011-00000002 Rows waited on：Session 18：obj-rowid=00001727-AAABcnAAJAAAAAAAAA(dictionary objn-5927,file-9,block-0,slot-0)Session 10：obj-rowid=00001727-AAABcnAAJAAAAAAAAA(dictionary objn-5927,file-9,block-0,slot-0)Information on the OTHER waiting sessions：Session 18：pid=16 serial=2370 audsid=18387 user：21/ODN O/S info：user：mwpodn00,term：unknown,ospid：,machine：beaida program：JDBC Thin Client application name：JDBC Thin Client,hash value=0 Current SQL Statement：DELETE FROM ODNQTEX WHERE EX_ID=：B1 End of information on OTHER waiting sessions.Current SQL statement for this session：DELETE FROM ODNQTFN WHERE FN_ID_EXIGENCE_EX=：B1---PL/SQL Call Stack---object line object handle number name 7000000135 f7fd8 34 procedure ODN.ODNQPDR 700000013 5f89f0 16 procedure ODN.ODNQPZB我们可以使用企业管理器来决定保留所有的锁还是释放掉它们，为了便于说明，我们打开2个sqlplus实例会话(在此期间同时发生了死锁)来一起调式，当每个语句执行完毕后，我们看到锁仍然保留下来了，它可以帮助我们识别出是哪个资源引起的死锁。
数据库死锁的产生与解决方法
数据库死锁的产生与解决方法数据库作为现代信息系统的核心组成部分之一，承担着存储和管理大量数据的重要任务。
然而，在多用户并发访问数据库时，死锁问题可能会导致系统性能下降甚至崩溃。
本文将探讨数据库死锁的产生原因，以及常用的解决方法。
一、死锁的产生原因1. 互斥访问资源：死锁的产生是因为多个并发事务同时竞争访问同一资源，每个事务都要求独占资源，但资源无法同时满足所有请求，导致事务之间发生资源竞争。
2. 内存不足：当系统内存不足时，数据库管理系统可能会将一些数据和操作转移到虚拟内存中。
如果产生死锁并且没有充足的物理内存来满足事务需求，那么死锁就会发生。
3. 事务持有和等待：当一个事务获取一个资源时，它可能会继续请求其他资源，并在等待其他资源的同时持有已获取的资源。
如果其他事务需要这些已获取的资源，则会产生死锁。
4. 循环等待：多个事务形成环形等待资源的关系，每个事务都在等待下一个事务所持有的资源，导致死锁的产生。
二、死锁解决方法1. 死锁检测与恢复：死锁检测算法可以周期性地扫描系统，定期检查是否存在死锁。
一旦检测到死锁，可以使用死锁恢复算法将死锁事务进行回滚，释放资源，解除死锁状态。
2. 死锁预防：死锁预防方法旨在通过改变系统的策略和规则，防止死锁的发生。
常见的预防方法包括：- 破坏互斥条件：通过将资源设置为可共享而不是互斥性的，可以防止死锁的发生。
- 破坏占有和等待条件：要求一个事务在执行之前获取所有需要的资源，而不是持有部分资源后再去请求其他资源。
- 破坏不可抢占条件：允许系统抢占一些资源，以便在发生死锁时能够打破死锁链。
- 破坏循环等待条件：通过强制事务按照某种统一顺序来请求资源，避免循环等待。
3. 死锁避免：死锁避免方法在事务执行之前对事务进行检测，并根据预测的执行路径来避免潜在的死锁情况。
该方法需要提前获得事务的请求资源信息，以便进行检测和判断是否应该阻止某个事务。
避免死锁的常用算法包括银行家算法和资源分配图算法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Oracle常见死锁发生的原因以及解决方法Oracle常见死锁发生的原因以及解决办法一，删除和更新之间引起的死锁造成死锁的原因就是多个线程或进程对同一个资源的争抢或相互依赖。
这里列举一个对同一个资源的争抢造成死锁的实例。
Oracle 10g, PL/SQL version 9.2CREATE TABLE testLock( ID NUMBER,test VARCHAR(100) )COMMITINSERT INTO testLock VALUES(1,'test1');INSERT INTO testLock VALUES(2,'test2');COMMIT;SELECT * FROM testLock1. ID TEST2.---------- ----------------------------------3. 1 test14. 2 test2死锁现象的重现：1)在sql 窗口执行：SELECT * FROM testLock FOR UPDATE; -- 加行级锁并对内容进行修改，不要提交2)另开一个command窗口，执行：delete from testLock WHERE ID=1;此时发生死锁（注意此时要另开一个窗口，不然会提示：POST THE CHANGE RECORD TO THE DATABASE. 点yes 后强制commit）：3)死锁查看：1.SQL> select ername,l.object_id, l.session_id,s.serial#, s.lockwait,s.status,s.machine,s.program from v$session s,v$locked_object l where s.sid = l.session_id;</p><p>USER NAME SESSION_ID SERIAL# LOCKWAIT STATUS MACHINE PROGRAM2.---------- ---------- ---------- -------- -------- ---------------------- ------------3.SYS 146 104 INACTIVE WORKGROUP\J-THINK PLSQLDev.exe4.SYS 144 145 20834474 ACTIVE WORKGROUP\J-THINK PLSQLDev.exe字段说明：Username：死锁语句所用的数据库用户；SID: session identifier，session 标示符，session 是通信双方从开始通信到通信结束期间的一个上下文。
SERIAL#: sid 会重用，但是同一个sid被重用时，serial#会增加，不会重复。
Lockwait：可以通过这个字段查询出当前正在等待的锁的相关信息。
Status：用来判断session状态。
Active：正执行SQL语句。
Inactive：等待操作。
Killed：被标注为删除。
Machine：死锁语句所在的机器。
Program：产生死锁的语句主要来自哪个应用程序。
4)查看引起死锁的语句：SQL> select sql_text from v$sql where hash_value in (select sql_hash_value from v$se ssion where sid in (select session_id from v$locked_object));1.2.SQL_TEXT3.------------------------------------------------------------1.delete from testLock where ID = 15)死锁的处理：SQL> alter system kill session '144,145';1.2.System altered3.4.Executed in 1.061 seconds此时在执行delete语句的窗口出现：SQL> delete from testLock where ID = 1;1.2.delete from testLock where ID = 13.4.ORA-00028: 您的会话己被终止再查看一下死锁，会发现已经没有stauts为active的记录了：SQL> select ername, l.session_id,s.serial#, s.lockwait,s.status,s.machine,s.program from v$session s,v$locked_object l where s.sid = l.session_id;1.ERNAME SESSION_ID SERIAL# LOCKWAIT STATUS MACHINE PROGRAM3.------------- ---------- ---------- -------- -------- --------------------------- ----------------1.SYS 146 104 INACTIVE WORKGROUP\J-THINK PLSQLDev.exe2.3.Executed in 0.032 seconds发生死锁的语句已经被终止。
二，在外键上没有加索引引起的死锁客户的10.2.0.4 RAC for AIX环境频繁出现ORA-60死锁问题，导致应用程序无法顺利执行。
经过一系列的诊断，发现最终问题是由于外键上没有建立索引所致，由于程序在主子表上删除数据，缺少索引导致行级锁升级为表级锁，最终导致大量的锁等待和死锁。
下面通过一个例子简单模拟一下问题：SQL> create table t_p (id number primary key, name varchar2(30));Table created.SQL> create table t_f (fid number, f_name varchar2(30), foreign key (fid) referencest_p);Table created.SQL> insert into t_p values (1, 'a');1 row created.SQL> insert into t_f values (1, 'a');1 row created.SQL> insert into t_p values (2, 'b');1 row created.SQL> insert into t_f values (2, 'c');1 row created.SQL> commit;Commit complete.SQL> delete t_f where fid = 2;1 row deleted.这时在会话2同样对子表进行删除：SQL2> delete t_f where fid = 1;1 row deleted.回到会话1执行主表的删除：SQL> delete t_p where id = 2;会话被锁，回到会话2执行主表的删除：SQL2> delete t_p where id = 1;会话同样被锁，这时会话1的语句被回滚，出现ORA-60死锁错误：delete t_p where id = 2*ERROR at line 1:ORA-00060: deadlock detected while waiting for resourceSQL> rollback;Rollback complete.将会话1操作回滚，会话2同样回滚并建立外键列上的索引：1 row deleted.SQL2> rollback;Rollback complete.SQL2> create index ind_t_f_fid on t_f(fid);Index created.重复上面的步骤会话1删除子表记录：SQL> delete t_f where fid = 2;1 row deleted.会话2删除子表记录：SQL2> delete t_f where fid = 1;1 row deleted.会话1删除主表记录：SQL> delete t_p where id = 2;1 row deleted.会话2删除主表记录：SQL> delete t_p where id = 1;1 row deleted.所有的删除操作都可以成功执行，关于两种情况下锁信息的不同这里就不深入分析了，重点就是在外键列上建立索引。
虽然有一些文章提到过，如果满足某些情况，可以不在外键列上建立的索引，但是我的观点一向是，既然创建了外键，就不要在乎再多一个索引，因为一个索引所增加的代价，与缺失这个索引所带来的问题相比，是微不足道的。
【补充】Oracle 10g和Oracle 9i trc日志内容的差别最主要的差别是在Oracle 10g中提示了等待资源的两条sql语句，在Oracle 9i中，只显示检测到死锁的sql语句Oracle 10g 10.2.0.3.0：DEADLOCK DETECTED ( ORA-00060 )[Transaction Deadlock]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 followinginformation may aid in determining the deadlock:Deadlock graph:---------Blocker(s)-----------------Waiter(s)---------Resource Name process session holds waits process session holds waitsTM-0000dd55-00000000 16 146 SX SSX 17 148 SX SSXSX SSXsession 146: DID 0001-0010-00000008 session 148: DID0001-0011-00000006session 148: DID 0001-0011-00000006 session 146: DID0001-0010-00000008Rows waited on:Session 148: no rowSession 146: no rowInformation on the OTHER waiting sessions:Session 148:pid=17 serial=39 audsid=540046 user: 54/SCOTTO/S info: user: SKYHOME\sky, term: SKYHOME, ospid: 3028:7000, machine: WORKGROUP\SKYHOMEprogram: plsqldev.exeapplication name: PL/SQL Developer, hash value=1190136663action name: Command Window - New, hash value=254318129Current SQL Statement:delete t_p where id = 1End of information on OTHER waiting sessions.Current SQL statement for this session:delete t_p where id = 2Oracle 9i 9.2.0.7.0：DEADLOCK DETECTEDCurrent SQL statement for this session:delete t_p where id = 2The 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 followinginformation may aid in determining the deadlock:Deadlock graph:---------Blocker(s)-----------------Waiter(s)---------Resource Name process session holds waits process session holds waitsSX SSXTM-0000260e-00000000 23 20 SX SSX 21 51 SX SSXsession 51: DID 0001-0015-0000043D session 20: DID0001-0017-00000397session 20: DID 0001-0017-00000397 session 51: DID0001-0015-0000043DRows waited on:Session 20: no rowSession 51: no rowInformation on the OTHER waiting sessions:Session 20:pid=23 serial=53179 audsid=197296 user: 87/scottO/S info: user: sky, term: SKYHOME, ospid: 5540:4984, machine: WORKGROUP\SKYHOMEprogram: plsqldev.execlient info: 127.0.0.1application name: PL/SQL Developer, hash value=1190136663action name: Command Window - New, hash value=254318129Current SQL Statement:delete t_p where id = 1End of information on OTHER waiting sessions.三，两个表之前不同顺序之间的相互更新操作引起的死锁Oracle中的死锁：注：4个update语句的执行顺序按图中位置自上而下图中左边会话中断(此时不回滚也不提交，等待用户决定)，右边会话阻塞，等待左边会话释放a表上的锁。