首页  >  文章  >  数据库  >  ORA-60死锁的实验

ORA-60死锁的实验

WBOY
WBOY原创
2016-06-07 17:33:591106浏览

ORA-60死锁的实验创建表: SQLgt;创建表 tbl_ora_60 (id 号(5),名称 varchar2(5));SQLgt;插入到 tbl_ora

ORA-60死锁的实验

 

创建表:

SQL>创建表 tbl_ora_60 (
id 号(5),
名称 varchar2(5)
);

SQL>;插入 tbl_ora_60 值(1, 'a');
已创建 1 行。

SQL>;插入 tbl_ora_60 值(2, 'b');
创建 1 行。

SQL>犯罪;
提交完成。

SQL> select * from tbl_ora_60;
ID NAME
------------ -----
1 a
2 b

实验开始
Session1 :
SQL> update tbl_ora_60 set where id=1;
已更新 1 行。

Session2:
SQL>; update tbl_ora_60 set where id=2;
1 行已更新。

Session1:
SQL>; update tbl_ora_60 set where id=2;
hang住

Session2:
SQL>; update tbl_ora_60 set where id=1;
hang住

此时,Session1:
SQL>; update tbl_ora_60 set where id=2;
update tbl_ora_60 set where id=2
*
第 1 行出现错误:
ORA-00060: 等待资源时检测到死锁

说明:
Session1 Session2
获取id=1的资源锁
获取id=2的资源锁
等待id=2的资源锁
等待id=1的资源锁
id =2的SQL报ORA-60,自动回滚

1、因为id=2的资源锁是Session2先获取的因此,Oracle会自动回滚产生死锁时后需要资源锁的SQL ,Session1的更新id=2操作被回滚。
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自动执行的回滚操作是基于单条SQL,不是整个事务的,所以这里只有id=2的记录被回滚,id=1的执行仍然正常

Session2:
SQL> update tbl_ora_60 set where id=1;
挂住

继续,Session1:
SQL>; commit;
提交完成。

Session2:
SQL> update tbl_ora_60 set where id=1;
已更新 1 行。

Session1:
SQL>; select * from tbl_ora_60;
ID NAME
------------ -----
1 c
2 b
只有id=1更新成功。

会话2:
SQL> select * from tbl_ora_60;
ID NAME
------------ -----
1 f
2 d
id=1和id=2都更新成功,但未COMMIT。

SQL> commit;
提交完成。

Session1:
SQL> select * from tbl_ora_60;
ID NAME
------------ -----
1 f
2 d
因Session2执行COMMIT,提交更新,此处显示与会话执行相同。

相关阅读:

ORA-01172、ORA-01151 错误处理

ORA-00600 [2662]错误解决

ORA-01078 和 LRM-00109 报错解决方法

ORA-00471处理方法笔记

ORA-00314,redolog 损坏,或丢失处理方法

ORA-00257 归档日志过大导致无法存储的解决方法

ORA-60死锁的实验

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn