【第22期】观点:IT 行业加班,到底有没有价值?

ORA-60死锁的实验

原创 2013年12月03日 14:38:20

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执行相同。
版权声明:本文为博主原创文章,未经博主允许不得转载。 举报

相关文章推荐

Oracle锁的模式和10704事件跟踪对比

锁是数据库用来控制共享资源并发访问的机制,是用来保护和用户相关的资源,如:表、用户、会话等。 本文以Oracle中锁的种类和模式讲起,后用10704做实验观察不同sql语句下锁持有情况的不同,主要以...

谈谈Oracle undo表空间

        谈谈Oracle undo表空间   Oracle比其他数据库牛逼的地方好几个,其中一个很重要的就是undo表空间的引入(当然,锁也是很牛逼的一个东西)</
  • hae
  • hae
  • 2014-07-30 22:20
  • 489

欢迎关注CSDN程序人生公众号

关注程序员生活,汇聚开发轶事。

死锁产生的原因和解决办法

如果有两个会话,每个会话都持有另一个会话想要的资源,此时就会发生死锁。 用下面实验来说明死锁的产生原因和解决办法。 SESSION1: SQL> create table t2 as selec...

ORA-60死锁的实验

http://blog.csdn.net/bisal/article/details/17095531 ORA-60死锁的实验 创建表: SQL> create ta...

Oracle之悲观锁和乐观锁

为了得到最大的性能,一般数据库都有并发机制,不过带来的问题就是数据访问的冲突。为了解决这个问题,大多数数据库用的方法就是数据的锁定。 数据的锁定分为两种方法,第一种叫做悲观锁,第二种叫做乐观锁。什么叫悲观锁呢,悲观锁顾名思义,就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住。而乐观锁就是认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行

Oracle中的锁(LOCK)机制

本文结合示例简要的介绍了一下Oracle中锁的机制。

案例学习Oracle错误:ORA-00060

原文: ORA-00060 deadlock detected while waiting for resource.   Cause: Your session and another session are waiting for a resource locked by the other. This condition is known as a deadlock. To resolve the deadlock, one or more statements were rolled back for th

oracle 监控

8个重要的脚本来监控Oracle数据库: 1.显示服务器上的可用实例       ps -ef | grep smon       oracle    5242     1  0 Mar07 ? ...

一次ORA-60死锁故障的处理

在一个数据库的警告日志中发现产生大量的ORA-60死锁报错,并导致了udump下产生了大量的trace文件。导致/app文件系统迅速增长。分析警告日志,和死锁产生的trace文件。 警告日志节选 Tue
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)