一個常見的ORA-00060死結現象

在Oracle資料庫中如果出現死結現象，資料庫就會報出ORA-00060的錯誤代號，這種死結現象通常都是應用邏輯設計出錯導致的異常，和oracle資料庫本身的設計無關，現在通過實驗類比一個死結現象
 
開啟兩個會話執行下列更新順序
 
會話1：執行對employee_id為198的欄位更新
HR@prod>update employees set first_name = 'cj' where employee_id = 198;
 
1 row updated.
 
會話2：執行對employee_id為200的欄位更新
HR@prod>update employees set first_name = 'hh' where employee_id = 200;
 
1 row updated.
 
會話1：再執行對employee_id為200的欄位更新，此時語句已經hang住，需要等待會話2發出commit或rollback動作。
HR@prod>update employees set first_name = 'cj' where employee_id = 200;
 
會話2：一旦執行更新，會話1就會馬上報錯。
HR@prod>update employees set first_name = 'sdf' where employee_id = 198;
 
update employees set first_name = 'cj' where employee_id = 200
         *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
 
會話2仍然hang住，查詢alert日誌發現報錯：
ORA-00060: Deadlock detected. More info in file /u01/app/oracle/admin/prod/udump/prod_ora_4273.trc.
 
 通過dba_blockers表中的HOLDING_SESSION欄位可以查詢到hang住會話的ID
SYS@prod>select * from dba_blockers;
 
HOLDING_SESSION
---------------
            159
 
使用v$session視圖擷取hang住會話的sid和serial#
SYS@prod>select sid,serial#,username from v$session where sid in
  2  (select blocking_session from v$session);
 
       SID    SERIAL# USERNAME
---------- ---------- ------------------------------
       159          5 HR
 
找到hang住的會話後，執行alter system命令kill掉相應的session就可以了：
SYS@prod>alter system kill session '159,5' immediate;
 
System altered.
 
執行後會話1中的會話會自動被kill掉
會話1：
HR@prod>select employee_id,first_name from employees where rownum
select employee_id,first_name from employees where rownum
         *
ERROR at line 1:
ORA-03135: connection lost contact
 
會話2中執行查詢發現會話2的更改生效。
HR@prod>select employee_id,first_name from employees where rownum
 
EMPLOYEE_ID FIRST_NAME
----------- --------------------
        198 sdf
        199 Douglas
        200 hh
        201 Michael
        202 Pat
        203 Susan
        204 Hermann
        205 Shelley
        206 William
        100 Steven
 
10 rows selected.
實際上，當出現死結的情況，Oracle也會在一段時間後解鎖。這種情況會在alert日誌中記載下列資訊：
ORA-00060: Deadlock detected. More info in file /u01/app/oracle/admin/ORCL/udump/orcl_ora_3173.trc.