人为地构造一个死锁(deadlock)(第6章.锁)

Expert Oracle Database Architecture学习笔记

人为地构造一个死锁(deadlock)(第6章.锁)

如果你有两个会话，每个会话都拥有另一个会话想要的资源，此时就会出现死锁(deadlock).

人为地构造一个死锁：
如果我们的数据库中有两个表a和b，每个表中都只有一行，就可以很容易地展示什么是死锁。

--------打开一个sqlplus会话：(会话a)------------
SQL> create table a(x int);
表已创建。

SQL> insert into a values(1);
已创建 1 行。

SQL> create table b(x int);
表已创建。

SQL> insert into b values(1);
已创建 1 行。

SQL> commit;
提交完成。

SQL> update a set x=x+1;
已更新 1 行。

--------打开第二个sqlplus会话：(会话b)-------
SQL> update b set x=x+1;
已更新 1 行。

--------回到第一个sqlplus会话：(会话a)-------
SQL> update b set x=x+1;
(此时发生阻塞，会话陷入等待状态)
--------回到第二个sqlplus会话：(会话b)-------
SQL> update a set x=x+1;
(此时发生死锁，两个会话在相互等待被对方锁定的资源)
----------------------------------------------
一段时间后，Oracle检测出死锁，并选择会话a作为牺牲品，让他的语句回滚：
----会话a显示：-----
update b set x=x+1
       *
ERROR 位于第 1 行:
ORA-00060: 等待资源时检测到死锁
--------------------

尽管会话a已经回滚，但是会话b仍然处于阻塞状态，因为Oracle只回滚了导致思索的一条语句，我决定对会话a进行提交：
----会话a--------
SQL> commit;
提交完成。
-----------------------------
随着会话a的提交，会话b也从阻塞状态走出，继续进行：
----会话b------
已更新 1 行。
--------------------
同时，在udump目录里，Oracle生成了一个长达79k的文件shanghai_ora_4068.trc对这次死锁进行描述。

正如Tom所言，Oracle认为这些应用死锁是应用自己导致的错误。而且Tom说，在大多情况下，Oracle的这种看法是正确的。不同于其他许多的RDBMS，Oracle极少出现死锁，甚至可以认为几乎不存在。通常情况下，必须认为地提供条件才会产生死锁。