資料庫版本是oracle 11.2.0.4.0，架構是單實體dg主從，物理standby，執行陳述句和查看日志的都是在主庫
用的查詢死鎖的陳述句：
SELECT bs.username "Blocking User", bs.username "DB User",
ws.username "Waiting User", bs.SID "SID", ws.SID "WSID",
bs.serial# "Serial#", bs.sql_address "address",
bs.sql_hash_value "Sql hash", bs.program "Blocking App",
ws.program "Waiting App", bs.machine "Blocking Machine",
ws.machine "Waiting Machine", bs.osuser "Blocking OS User",
ws.osuser "Waiting OS User", bs.serial# "Serial#",
ws.serial# "WSerial#",
DECODE (wk.TYPE,
'MR', 'Media Recovery',
'RT', 'Redo Thread',
'UN', 'USER Name',
'TX', 'Transaction',
'TM', 'DML',
'UL', 'PL/SQL USER LOCK',
'DX', 'Distributed Xaction',
'CF', 'Control FILE',
'IS', 'Instance State',
'FS', 'FILE SET',
'IR', 'Instance Recovery',
'ST', 'Disk SPACE Transaction',
'TS', 'Temp Segment',
'IV', 'Library Cache Invalidation',
'LS', 'LOG START OR Switch',
'RW', 'ROW Wait',
'SQ', 'Sequence Number',
'TE', 'Extend TABLE',
'TT', 'Temp TABLE',
wk.TYPE
) lock_type,
DECODE (hk.lmode,
0, 'None',
1, 'NULL',
2, 'ROW-S (SS)',
3, 'ROW-X (SX)',
4, 'SHARE',
5, 'S/ROW-X (SSX)',
6, 'EXCLUSIVE',
TO_CHAR (hk.lmode)
) mode_held,
DECODE (wk.request,
0, 'None',
1, 'NULL',
2, 'ROW-S (SS)',
3, 'ROW-X (SX)',
4, 'SHARE',
5, 'S/ROW-X (SSX)',
6, 'EXCLUSIVE',
TO_CHAR (wk.request)
) mode_requested,
TO_CHAR (hk.id1) lock_id1, TO_CHAR (hk.id2) lock_id2,
DECODE
(hk.BLOCK,
0, 'NOT Blocking', /**//* Not blocking any other processes */
1, 'Blocking', /**//* This lock blocks other processes */
2, 'Global', /**//* This lock is global, so we can't tell */
TO_CHAR (hk.BLOCK)
) blocking_others
FROM v$lock hk, v$session bs, v$lock wk, v$session ws
WHERE hk.BLOCK = 1
AND hk.lmode != 0
AND hk.lmode != 1
AND wk.request != 0
AND wk.TYPE(+) = hk.TYPE
AND wk.id1(+) = hk.id1
AND wk.id2(+) = hk.id2
AND hk.SID = bs.SID(+)
AND wk.SID = ws.SID(+)
AND (bs.username IS NOT NULL)
AND (bs.username <> 'SYSTEM')
AND (bs.username <> 'SYS')
ORDER BY 1;
得到的結果：
PU_APPS PU_APPS 1654 1712 13879 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
PU_APPS PU_APPS 2167 1199 54359 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
PU_APPS PU_APPS 1771 116 45785 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
PU_APPS PU_APPS 2167 858 54359 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
PU_APPS PU_APPS 1712 1314 2975 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
PU_APPS PU_APPS 2167 1884 54359 0000000627E2BEA0 3274778297 JDBC Thin Client JDBC Thin Client
表明有死鎖，但是在資料庫的alert日志中并沒有發現 ORA-00060的日志，請大神進來指點分析一下
uj5u.com熱心網友回復：
死鎖3秒內就會報錯，斷開其中一個會話，你基本上不會查到的。你的腳本查的根本不是死鎖，搞清楚鎖等待和死鎖的區別——因為基本99%以上的開發都管鎖等待叫做死鎖
uj5u.com熱心網友回復：
多謝樓上指點，那請問怎樣去查看死鎖呢？uj5u.com熱心網友回復：
基本99%以上的開發都管鎖等待叫做死鎖
uj5u.com熱心網友回復：
死鎖的話上面說了，3秒內就會有會話報錯，而且實體的alert日志里會寫入死鎖ORA-60錯誤。
uj5u.com熱心網友回復：
也就是sql查出來的都是阻塞而不是死鎖，死鎖只能從日志里看，sql是查不出來的，可以這樣理解嗎？uj5u.com熱心網友回復：
鎖等待，也就是你說的阻塞是其中一個請求鎖資源的會話等待另外一個持鎖的會話，而死鎖是兩個會話之間相互等待，因為死鎖的檢測機制，在這種情況下，3秒之內，必定會有其中一個會話爆出ORA-60，并寫入alert日志，時間太快，你想查也來不及。
uj5u.com熱心網友回復：
多謝指點，明白了轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/24632.html
標籤：基礎和管理
上一篇：Windows10安裝oracle10g出現未找到先決條件解決辦法
下一篇：公司資助我去培訓Oracle