一个常见的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 (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 < 11; select employee_id,first_name from employees where rownum < 11 * ERROR at line 1: ORA-03135: connection lost contact
会话2中执行查询发现会话2的更改生效。
HR@prod>select employee_id,first_name from employees where rownum < 11; 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.
本文版权由作者Beanbee和博客园共同所有,转载请注明出处。
来自【Beanbee的博客】:http://www.cnblogs.com/beanbee/