一个常见的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.