在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 < 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.
