ORA-00060 Deadlock detected

今天一套10.2.0.4的数据库报ORA-00060 Deadlock detected。

 

trace部分内容:

 

Dump file /oracle/oracle/product/10.2.0/admin/APSDB/udump/apsdb_ora_1008062.trc

Oracle Database10gEnterprise Edition Release10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORACLE_HOME = /oracle/oracle/product/10.2.0

System name:   AIX

Node name: jzdb-b

Release:   3

Version:   5

Machine:   00C1A5C54C00

Instance name: APSDB

Redo thread mounted by this instance: 1

Oracle process number: 63

Unix process pid: 1008062, image: oracle@jzdb-b

 

*** 2011-09-26 10:54:37.137

*** SERVICE NAME:(SYS$USERS) 2011-09-26 10:54:37.129

*** SESSION ID:(205.28158) 2011-09-26 10:54:37.129

DEADLOCK DETECTED ( ORA-00060 )

[Transaction Deadlock]

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:

                      ---------Blocker(s)-------- ---------Waiter(s)---------

Resource Name         process session holds waits process session holds waits

TX-00010023-00004fdb       63    205    X          62    179          X

TX-000a0025-00009f87       62    179    X          63    205          X

session 205: DID 0001-003F-000095E7session 179: DID 0001-003E-00009E3A

session 179: DID 0001-003E-00009E3Asession 205: DID 0001-003F-000095E7

Rows waited on:

Session 179: obj - rowid = 00002AD8 - AAACrYAAEAAAIkRABP

 (dictionary objn - 10968, file - 4, block - 35089, slot - 79)

Session 205: obj - rowid =00002A16 - AAACoWAAEAAAJisAAF

 (dictionary objn - 10774, file - 4, block - 39084, slot - 5)

Information on the OTHER waiting sessions:

Session 179:

 pid=62 serial=42457 audsid=12628802 user: 28/CNAPS

 O/S info: user: , term: , ospid: 1234, machine: rcca-web

           program:

 Current SQL Statement:

 

update JJ_SHENGQINGJIAN5 set YINHANG_NO=:1, SAVING=:2, STOCKS=:3, HOUSEREGION=:4, HOUSEAREA=:5, HOUSEPRICE=:6, OTHER_CREDITLIMIT=:7, BRANCHSUGGESTLIMIT=:8, VEHICLETYPE=:9, VEHICLEPRICE=:10, VEHICLEWEIGHT=:11, VEHICLEREGISTDATE=:12, REGISTFUND=:13, REGISTDATE=:14, REFTEL1BYCREDIT=:15, REFTEL2BYCREDIT=:16, REFERENCETEL=:17, CONFIRMCONTENT=:18, COMMENTINFOBYBRANCH=:19, YEARINCOMEBYJJ=:20, INCOMEBYCREDIT=:21, BUSINESSLICENSE=:22, NOTERESULT=:23, NOTEOVERFLG=:24, OVER_RECHECK_FLAG=:25, RISK_CHECK_FLAG=:26, REFUSE=:27, PRIMARYLIMIT=:28, SECONDARYLIMITPERCENT=:29, SECONDARYLIMIT=:30, REASONCD1=:31, REASONCD2=:32, REASONCD3=:33, REASONCD4=:34, REASONCD5=:35, EXPLAIN=:36, RFE_TIME=:37, PINION=:38, VERFLG=:39, THERS=:40, PINE=:41, REFTELOPINE=:42, CREATER=:43, INSERTTIME=:44, UPDATOR=:45, UPDATETIME=:46, ID=:47, STOCKSBYCREDIT=:48, SAVINGBYCREDIT=:49, HOLD_CARD_FLG=:50, CHECKCREDIT_FLG=:51, HUNTER_FLG=:52, REGISTFUNDBYCREDIT=:53, VEHICLEPRICEBYCREDIT=:54, HOUSEPRICEBYCREDIT=:55, CANCEL_REASON=:56, MASTER_AUDIT_REASON=:57, FINAL_REASON=:58, FINAL_TIME=:59, LCOPINE=:60, income_flag=:61, inspection_flag=:62, TVCODE=:63, SCCODE=:64, CTCODE=:65, ACCODE=:66, ICCODE=:67, CCODE=:68, PCCODE=:69, RCCODE=:70, FTECODE=:71, FINALFLAG=:72, docstart=:73, docend=:74 where SHENQINGJIAN_ID=:75

End of information on OTHER waiting sessions.

Current SQL statement for this session:

update JBPM_TASKINSTANCE set NAME_=:1, DESCRIPTION_=:2, ACTORID_=:3, CREATE_=:4, START_=:5, END_=:6, DUEDATE_=:7, PRIORITY_=:8, ISCANCELLED_=:9, ISSUSPENDED_=:10, ISOPEN_=:11, ISSIGNALLING_=:12, ISBLOCKING_=:13, TASK_=:14, TOKEN_=:15, SWIMLANINSTANCE_=:16, TASKMGMTINSTANCE_=:17 where ID_=:18

 

简单说明一下,从Deadlock graph中,确认以下信息:

 

                      ---------Blocker(s)-------- ---------Waiter(s)---------

Resource Name         process session holds waits process session holds waits

TX-00010023-00004fdb       63    205    X          62    179          X

TX-000a0025-00009f87       62    179    X          63    205          X

 

从这里可以看到,session 179以排他方式(X)拥有资源TX-00010023-00004fdb,阻塞了session 205对该资源的申请。Session 205以排他方式(X)拥有资源TX-000a0025-00009f87,阻塞了session 179对该资源的申请,从而导致了死锁。

 

这里的TX-00010023-00004fdb,TX代表锁的类型,常见的有:

TM - DML enqueue

TX - Transaction enqueue

UL - User supplied

 

00010023和00004fdb分别对应的是v$lock中ID1和ID2字段。

 

对于TX类型锁,通过ID1可以换算出事务的回滚段号、slot号,ID2代表事务的序列号。

先看00010023,0001代表回滚段号,换算成十进制为1,0023为事务的slot号,换算成十进制为35。而00004fdb换算成十进制为20443。

所以TX-00010023-00004fdb对应v$transaction中XIDUSN=1,XIDSLOT=35,XIDSQN=20443的事务。

 

当然也可以这么换算,00010023对应十进制的65571。

 

SQL> select trunc(65571/65536),mod(65571,65536) from dual;     

 

TRUNC(65571/65536) MOD(65571,65536)

------------------ ----------------

                1              35

 

得到XIDUSN=1,XIDSLOT=35。

 

对于TM类型锁,ID1代表object id,ID2总是为0。

 

Lock type

TX

ID1

ID1 indicates the rollback segment and the slot number. On 32-bit machines, you must convert ID1 into hexadecimal and left pad with zeros up to 8 characters. The high order 2 bytes give the rollback segment number, and the low order 2 bytes give the rollback slot number. The values can be seen in the XIDUSN and XIDSLOT columns of the V$TRANSACTION view.

ID2

Rollback segment wrap or sequence number. This value can be seen in the XIDSQN column of V$TRANSACTION view.

Lock type

TM

ID1

ID1 indicates the object ID of the table, which can be found in DBA_OBJECTS.OBJECT_ID.

ID2

Always 0.

 

接下来trace信息记录了DID信息:

 

session 205: DID 0001-003F-000095E7session 179: DID 0001-003E-00009E3A

session 179: DID 0001-003E-00009E3Asession 205: DID 0001-003F-000095E7

 

DID即deadlock id,这里以0001-003F-000095E7为例:

0001:换算成十进制为1,代表的是实例号

003F:换算为十进制为63,代表ORACLE PID,即ORACLE进程号

000095E7:换算为十进制为38375,类似于v$session.serial#,ORACLE PID的一个串行值。

 

同时,下面的trace信息,描述了死锁发生时对应会话的object id和rowid。

 

Session 179: obj - rowid = 00002AD8 - AAACrYAAEAAAIkRABP

 (dictionary objn - 10968, file - 4, block - 35089, slot - 79)

Session 205: obj - rowid =00002A16 - AAACoWAAEAAAJisAAF

 (dictionary objn - 10774, file - 4, block - 39084, slot - 5)

 

这里的会话179,对象号是00002AD8,rowid是AAACrYAAEAAAIkRABP。

后面的括号内容(dictionary objn - 10968, file - 4, block - 35089, slot - 79)已经很清楚地翻译了这些信息,这里不再详细说明了。

 

最后,我们可以看到死锁时会话执行的sql语句。

 

Session 179:

 

update JJ_SHENGQINGJIAN5 set YINHANG_NO=:1, SAVING=:2, STOCKS=:3, HOUSEREGION=:4, HOUSEAREA=:5, HOUSEPRICE=:6, OTHER_CREDITLIMIT=:7, BRANCHSUGGESTLIMIT=:8, VEHICLETYPE=:9, VEHICLEPRICE=:10, VEHICLEWEIGHT=:11, VEHICLEREGISTDATE=:12, REGISTFUND=:13, REGISTDATE=:14, REFTEL1BYCREDIT=:15, REFTEL2BYCREDIT=:16, REFERENCETEL=:17, CONFIRMCONTENT=:18, COMMENTINFOBYBRANCH=:19, YEARINCOMEBYJJ=:20, INCOMEBYCREDIT=:21, BUSINESSLICENSE=:22, NOTERESULT=:23, NOTEOVERFLG=:24, OVER_RECHECK_FLAG=:25, RISK_CHECK_FLAG=:26, REFUSE=:27, PRIMARYLIMIT=:28, SECONDARYLIMITPERCENT=:29, SECONDARYLIMIT=:30, REASONCD1=:31, REASONCD2=:32, REASONCD3=:33, REASONCD4=:34, REASONCD5=:35, EXPLAIN=:36, RFE_TIME=:37, PINION=:38, VERFLG=:39, THERS=:40, PINE=:41, REFTELOPINE=:42, CREATER=:43, INSERTTIME=:44, UPDATOR=:45, UPDATETIME=:46, ID=:47, STOCKSBYCREDIT=:48, SAVINGBYCREDIT=:49, HOLD_CARD_FLG=:50, CHECKCREDIT_FLG=:51, HUNTER_FLG=:52, REGISTFUNDBYCREDIT=:53, VEHICLEPRICEBYCREDIT=:54, HOUSEPRICEBYCREDIT=:55, CANCEL_REASON=:56, MASTER_AUDIT_REASON=:57, FINAL_REASON=:58, FINAL_TIME=:59, LCOPINE=:60, income_flag=:61, inspection_flag=:62, TVCODE=:63, SCCODE=:64, CTCODE=:65, ACCODE=:66, ICCODE=:67, CCODE=:68, PCCODE=:69, RCCODE=:70, FTECODE=:71, FINALFLAG=:72, docstart=:73, docend=:74 where SHENQINGJIAN_ID=:75

 

Session 205:

 

update JBPM_TASKINSTANCE set NAME_=:1, DESCRIPTION_=:2, ACTORID_=:3, CREATE_=:4, START_=:5, END_=:6, DUEDATE_=:7, PRIORITY_=:8, ISCANCELLED_=:9, ISSUSPENDED_=:10, ISOPEN_=:11, ISSIGNALLING_=:12, ISBLOCKING_=:13, TASK_=:14, TOKEN_=:15, SWIMLANINSTANCE_=:16, TASKMGMTINSTANCE_=:17 where ID_=:18

 

有了以上信息,就很方便我们定位死锁的原因了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值