ORA-60死锁的实验
创建表：
SQL> create table tbl_ora_60 (
id number(5),
name varchar2(5)
); SQL> insert into tbl_ora_60 values(1, 'a');
1 row created.
SQL> insert into tbl_ora_60 values(2, 'b');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from tbl_ora_60;
ID NAME
---------- -----
1 a
2 b
实验开始
Session1：
SQL> update tbl_ora_60 set name='c' where id=1;
1 row updated.
Session2：
SQL> update tbl_ora_60 set name='d' where id=2;
1 row updated.
Session1：
SQL> update tbl_ora_60 set name='e' where id=2;
hang住
Session2：
SQL> update tbl_ora_60 set name='f' where id=1;
hang住
此时，Session1：
SQL> update tbl_ora_60 set name='e' where id=2;
update tbl_ora_60 set name='e' where id=2
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
说明：
Session1 Session2
获取id=1的资源锁
获取id=2的资源锁
等待id=2的资源锁
等待id=1的资源锁
id=2的SQL报ORA-60，自动rollback
1、因为id=2的资源锁是Session2先获取的，因此Oracle会自动rollback产生死锁时后需要资源锁的SQL，Session1的更新id=2操作被rollback。
2、从中可以发现，真正报ORA-60错误的SQL获取的资源(此例中id=2)，并不是触发死锁产生的那个资源(此例中id=1)，此例用的是同一个表的不同行，对不同表的相同行也如此，也可以解释之前夜维出现ORA-60时显示的SQL之间表是不同的原因，因为夜维执行的某个表更新与当前应用执行的某个表更新之间存在互锁的情况，因此可能导致夜维SQL报ORA-60或应用报ORA-60的错误。
此时，Session1：
SQL> select * from tbl_ora_60;
ID NAME
---------- -----
1 c
2 b
说明：此处可以证明产生报错后，Oracle自动执行的rollback操作是基于单条SQL，不是整个事务的，所以这里只有id=2的记录被rollback，id=1的执行仍正常。
Session2：
SQL> update tbl_ora_60 set name='f' where id=1;
hang住
继续，Session1：
SQL> commit;
Commit complete.
Session2：
SQL> update tbl_ora_60 set name='f' where id=1;
1 row updated.
Session1：
SQL> select * from tbl_ora_60;
ID NAME
---------- -----
1 c
2 b
只有id=1更新成功。
Session2：
SQL> select * from tbl_ora_60;
ID NAME
---------- -----
1 f
2 d
id=1和id=2都更新成功，但未COMMIT。
SQL> commit;
Commit complete.
Session1：
SQL> select * from tbl_ora_60;
ID NAME
---------- -----
1 f
2 d
因Session2执行COMMIT，提交更新，此处显示与Session执行相同。
