-- 死锁的产生与消除1
-- session A
SQL> create table a (ca int);
SQL> create table b (cb int);
SQL> insert into a values (1);
SQL> insert into b values (1);
SQL> commit;
SQL> update a set ca=2 where ca=1;

-- session B
SQL> update b set cb=2 where cb=1;
SQL> update a set ca=3 where ca=1;
-- 此时发生阻塞，因为在session A锁定了a表；
-- session A还有机会提交或回滚，之后，B就不再等待，否则阻塞一直继续

-- session A
SQL> update b set cb=3 where cb=1;
-- 如果在阻塞时，又在A中试图更新表B，就会发生死锁，
-- 在会话B中会得到ERROR 位于第 1 行:ORA-00060: 等待资源时检测到死锁

-- session B
update a set ca=3 where ca=1
*
ERROR 位于第 1 行:
ORA-00060: 等待资源时检测到死锁

-- 死锁发生后，想要更新b表的会话A仍在阻塞着，它在等待会话B对b表的提交或回滚；因为oracle发生死锁后，
-- 并不回滚所以事务，只回滚与死锁有关的语句。
-- 因此，在会话B中提交
-- session B
SQL> commit;

提交完成。

--session A 中自动出现
-- update b set cb=3 where cb=1;
已更新0行。

-- 针对上述原因造成的死锁，网上很多人说在应用中要按顺序进行更新。但这并不是死锁的唯一原因
-- alert_orcl.log中的内容
Wed Dec 27 08:50:41 2006
ORA-000060: Deadlock detected. More info in file d:oracleadminorcludumporcl_ora_1856.trc.

-- orcl_ora_1856.trc中的部分内容
*** 2006-12-27 08:50:40.000
*** SESSION ID:(8.20) 2006-12-27 08:50:40.000
DEADLOCK DETECTED
Current SQL statement for this session:
update a set ca=3 where ca=1
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-0002002c-0000009a 11 8 X 10 7 X
TX-0001001e-000000a4 10 7 X 11 8 X