死锁问题及其解决方法.docVIP

死锁问题及其解决方法 一、死锁的介绍 死锁（Deadlocks）通常发生在两个或多个进程（sessions）对被彼此锁住的资源发出请求的情况下。其最常见的锁的类型为：行级锁（row-level locks）和块级锁（block-level locks）。 ORACLE会自动侦察到死锁情况，并通过回滚其中一个造成死锁的语句，从而释放其中一个锁来解决它，如上图中的C时间所示。需要说明的，如果一个事务中的某个语句造成死锁现象，回滚的只是这个语句而不是整个事务。 二、行级死锁及其解决方法 行级锁的发生如下图所示，在A时间，Transacrion1和Transction2分别锁住了它们要update的一行数据，没有任何问题。但每个Transaction都没有终止。接下来在B时间，它们又试图update当前正被对方Transaction锁住的行，因此双方都无法获得资源，此时就出现了死锁。之所以称之为死锁，是因为无论每个Transaction等待多久，这种锁都不会被释放。 行级锁的死锁一般是由于应用逻辑设计的问题造成的，其解决方法是通过分析trace文件定位出造成死锁的SQL语句、被互相锁住资源的对象及其记录等信息，提供给应用开发人员进行分析，并修改特定或一系列表的更新（update）顺序。 以下举例说明出现行级死锁时如何定位问题所在。 环境搭建 create table b b number ; insert into b values 1 ; insert into b values 2 ; commit; session1: update b set b 21 where b 2; session2: update b set b 11 where b 1; session1: update b set b 12 where b 1; session2: update b set b 22 where b 2; 此时出现死锁现象。 解决办法 方法一：利用trace文件信息定位； 1 ORACLE 8.1.7 SQL sho parameter user_dump_dest NAME TYPE VALUE user_dump_dest string /u01/app/oracle/admin/ora817/udump 到udump的路径下找到最新生成的trace文件，其中主要信息如下： *** 2004-08-03 15:17:09.171 *** SESSION ID: 13.2244 2004-08-03 15:17:09.170 DEADLOCK DETECTED Current SQL statement for this session: update b set b 22 where b 2 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 information may aid in determining the deadlock: Deadlock graph: Resource Name process session holds waits process session holds waits TX0000000e 14 13 X 15 14 X TX00000011 15 14 X 14 13 X session 13: DID 0001-000Esession 14: DID 0001-000Fsession 14: DID 0001-000Fsession 13: DID 0001-000ERows waited on: Session 14: obj - rowid 00000C87 - AAAAyHAABAAAGG8AAA Session 13: obj - rowid 00000C87 - AAAAyHAABAAAGG8AAB 通过红字部分的信息来定位被互相锁住资源的对象及其记录，00000C87即十六进制的object_id，转化成十进制为3207，通过查询可定位对象： SQL select object_name,object_type from user_objects where object_id 3207; OBJECT_NAME OBJECT