在Oracle数据库中如果出现死锁现象，数据库就会报出ORA-00060的错误代号，这种死锁现象通常都是应用逻辑设计出错导致的异常，和o
在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.
