发布日期:2015-11-05 17:18 来源: 标签: 数据库 oracle教程 oracle函数 死锁deadlocks
Oracle是目前商业数据库市场上表现最优秀的并发数据库系统,同样存在死锁的威胁。存在并发、存在资源独占,就有锁lock或者类似锁概念的机制。Oracle提供了多种类型锁和多种锁的机制,包括共享锁和独占锁。并且,在进行各类型操作的时候,自动的对对象进行加锁解锁,以及锁升级操作,最大可能的保证数据完整性。
Oracle中的死锁
Oracle是目前商业数据库市场上表现最优秀的并发数据库系统,同样存在死锁的威胁。存在并发、存在资源独占,就有锁lock或者类似锁概念的机制。Oracle提供了多种类型锁和多种锁的机制,包括共享锁和独占锁。并且,在进行各类型操作的时候,自动的对对象进行加锁解锁,以及锁升级操作,最大可能的保证数据完整性。
那么,如果出现死锁,Oracle会如何处理呢?
Oracle的锁机制是建立在行锁一级,在插入、更新行一级信息的时候,会加入独占锁内容。那么,我们尝试模拟下出现死锁的状态。两个session分别更新两条记录,在一个事务里再尝试更新对方记录,那么可以引发死锁。

实验环境准备:
SQL> desc t;
Name Type         Nullable Default Comments
---- ------------ -------- ------- --------
ID   NUMBER                                 
COMM VARCHAR2(10) Y                        

SQL> select * from t where rownum<3;
        ID COMM
---------- ----------
         1 Tst1
         2 Tst2
两个session,分别针对id=1,2两条记录做文章。
//Session1

SQL> select sid from v$mystat where rownum<2;
       SID
----------
       152

SQL> update t set comm='Tst1' where id=1;
1 row updated
//Session2

SQL> select sid from v$mystat where rownum<2;
       SID
----------
       150

SQL> update t set comm='Tst2' where id=2;
1 row updated
此时,锁的状态为:

SQL> select * from v$lock where sid in (150,152);
ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST
-------- -------- ---------- ---- ---------- ---------- ---------- ----------
333415A4 333415BC        152 TM        54599          0          3          0
33341668 33341680        150 TM        54599          0          3          0 
3338A42C 3338A548        150 TX       393251        795          6          0 
333B8954 333B8A70        152 TX       327686        779          6          0
此时,我们看到了在两个session中,分别使用了行锁,独占(LMODE=6)锁住了两行。下面继续相互请求。
//session1中,尝试更新id=2的记录

SQL> update t set comm='Tst2' where id=2;
Session1(SID=152)被hange住。

//锁状态
SQL> select * from v$lock where sid in (150,152);
ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST
-------- -------- ---------- ---- ---------- ---------- ---------- ----------
33834398 338343AC        152 TX       393251        795          0          6 
333415A4 333415BC        152 TM        54599          0          3          0 
33341668 33341680        150 TM        54599          0          3          0 
3338A42C 3338A548        150 TX       393251        795          6          0
333B8954 333B8A70        152 TX       327686        779          6          0 
说明:在Oracle中,hange表示session正在等待资源被释放,表现就是停住操作,不断的轮询资源。

Session2请求更新:
//session2(SID=150)
SQL> update t set comm='Tst1' where id=1;
注意:此时,应当出现死锁状态,而在系统中,也出现了一瞬间的两个session互相hange的状态;
此时,session2继续被hange住,原先的session1退出,如下状态:
//session1(SID=152)
SQL> update t set comm='Tst2' where id=2;
update t set comm='Tst2' where id=2
ORA-00060: 等待资源时检测到死锁
结果是:Oracle在两个出现死锁的session中,随机寻找了一个session,驳回了其被hange住的请求,维持另一方session的hange状态。
注意:Oracle此处的处理:只是驳回了一方的请求,并没有回滚该请求,也没有将另一方的hange状态解除。
思考:显然,这个过程中是Oracle内部的防护机制起了作用,防止了系统中死锁的发生。在Oracle中,存在某种轮询的机制,随时检查系统中出现的多会话被hange住的情况,一旦发生,就将一个session被hange住的请求退回,抛出00060错误。
在两个session互锁的情况下,Oracle死锁检测程序可以起作用。那么,如果死锁结构复杂的时候,是不是Oracle的检测机制会失效。笔者使用4-5个session进行检查,虽然检测起效的时间有长有短,但最后都是将死锁的状态加以解除。
有一点需要注意,Oracle解决死锁的方式只是将请求拒绝,并不是将事务回滚。所以,在解决死锁之后,其他被hange住的session依然还是被hange住。所以,从应用程序和PL/SQL的角度,如果接受到了60错误,应该做的工作就是回滚当前事务,解决整体的资源争用现象。

Oracle死锁发生
那么,Oracle中死锁发生的几率是不是那么高呢?答案是否定的。这个是由Oracle锁的特性所决定的。
1、  Oracle对查询不加锁。Oracle本身支持多版本一致读,如果当前的数据块正在被修改(独占)而并未提交,Oracle会根据SCN查找日志和Undo空间,找到合适SCN的版本返回结果。所以,在查询的时候,是不需要加锁的。
2、  Oracle数据操作使用行级锁(本质上是事务锁),实现最小粒度的独占范围。Oracle在DML的时候,只会对操作的行进行独占锁定,而不是过大的数据单元(如页page)。这样,就保证了不会引起过多的独占资源。
同时,Oracle本身也提供了死锁监视程序功能,能及时发现死锁状态,并自动的进行解锁。在这些机制下,Oracle认为死锁发生的概率很低(起码自身不会引起死锁)。只有一种情况会引发死锁,就是开发人员手工提高加锁的级别。
Oracle对于SQL的拓展中,有一部分是显示对象加锁。从lock table XXX到select XXX for update。这些操作都会引起对对象锁级别的提升,这些都可能引发死锁的发生。

相关评论

专题信息
    ORACLE数据库系统是美国ORACLE公司(甲骨文)提供的以分布式数据库为核心的一组软件产品,是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。比如SilverStream就是基于数据库的一种中间件。ORACLE数据库是目前世界上使用最为广泛的数据库管理系统,作为一个通用的数据库系统,它具有完整的数据管理功能;本教程主要是针对oracle应用过程中我们常用的函数进行深入讲解,让大家能够通过代码实例更快、更有效的掌握oracle函数,希望对大家有所帮助。