共计 2891 个字符，预计需要花费 8 分钟才能阅读完成。
Oracle 死锁分析
关于死锁一般 3 种处理方式
1、事前预测
2、资源分级
3、事后检测释放
我知道的 ORACLE MYSQL 都是采用第三种在行锁级别上的话。
这里分析一个 ORACLE 死锁，首先一个死锁肯定会生成一个 TRACE 文件，这里会记录很多信息如：
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-0058000f-0000b473 649 1204 X 651 1252 X
TX-0019001c-0004e0b0 651 1252 X 649 1204 X
这里给出了进程和会话 id
Rows waited on:
Session 1204: obj – rowid = 0003D942 – AAA9lCAAEAADgaNAAI
(dictionary objn – 252226, file – 4, block – 919181, slot – 8)
Session 1252: obj – rowid = 0003D942 – AAA9lCAAEAADgaNAAa
(dictionary objn – 252226, file – 4, block – 919181, slot – 26)
这里给出导致死锁的行
同时给出了最后触发死锁会话 1252 的语句
—– Information for the OTHER waiting sessions —–
Session 1252:
sid: 1252 ser: 35883 audsid: 7170593 user: 235/FEECORESV
flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
pid: 651 O/S info: user: oracle, term: UNKNOWN, ospid: 13035
image: oracle@oratest11
client details:
O/S info: user: sky, term: unknown, ospid: 1234
machine: autobots program: JDBC Thin Client
application name: JDBC Thin Client, hash value=2546894660
current SQL:
UPDATE *******
—– End of information for the OTHER waiting sessions —–
Information for THIS session:
—– Current SQL Statement for this session (sql_id=3vh5sc7pgtrjy) —–
UPDATE *******
那么到这里我们大概能够分析出
A:1204 拿到 AAA9lCAAEAADgaNAAa 行锁 B:1252 拿到 AAA9lCAAEAADgaNAAI 行锁
C:1204 需要 AAA9lCAAEAADgaNAAI 则等待 D:1252 需要 AAA9lCAAEAADgaNAAa 则触发死锁 1204 回滚
那么随后 trace 给出 1204 C 这一步等待时间和事物信息
SO: 0xee1fcd10, type: 4, owner: 0xf031e750, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xf031e750, name=session, file=ksu.h LINE:12624, pg=0
(session) sid: 1204 ser: 2443 trans: 0xe9221180, creator: 0xf031e750
flags: (0x100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
flags2: (0x40009) -/-/INC
DID: , short-term DID:
txn branch: (nil)
oct: 6, prv: 0, sql: 0xf25d2278, psql: 0xc4346788, user: 235/FEECORESV
ksuxds FALSE at location: 0
service name: SYS$USERS
Current Wait Stack:
0: waiting for ‘enq: TX – row lock contention’
name|mode=0x54580006, usn<<16 | slot=0x19001c, sequence=0x4e0b0
wait_id=33 seq_num=34 snap_id=1
wait times: snap=3.001739 sec, exc=3.001739 sec, total=3.001739 sec
wait times: max=infinite, heur=3.001739 sec
wait counts: calls=1 os=1
in_wait=1 iflags=0x15a0
随后给出了导致他等待会话的等待信息，这里不给出。当然随后还有很多类容，但是关键就是如上
但是这里并没有一个显示的事物执行的过程，如果要看到完整的语句我们需要日志挖掘，我挖掘出来的如下：
1204：
set transaction read write;
select * from TEST.TEST where ROWID = ‘AAA9lCAAEAADgaNAAa’ for update;
commit;
1252：
set transaction read write;
select * from TEST.TEST where ROWID = ‘AAA9lCAAEAADgaNAAI’ for update;
update TEST.TEST set “STATUS” = ‘SUCCESS’, “DETAIL” = ‘ 执行成功 ’, “RAW_UPDATE_TIME” = TO_TIMESTAMP(’19-SEP-16 01.27.25.714715 PM’) where “IDENTITY” = ‘39319’ and “STATUS” = ‘PROCESSING’ and “DETAIL” IS NULL and “RAW_UPDATE_TIME” = TO_TIMESTAMP(’19-SEP-16 01.27.24.611036 PM’) and ROWID = ‘AAA9lCAAEAADgaNAAa’;
commit;
这样能够清楚的看到 1204 的 update 并没有执行，而由于触发了 deadlock 回滚掉了。
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-09/135420.htm
