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

相关推荐