兩個Oracle死結解決執行個體
關於資料庫中的死結。如果在應用中碰到都會毫不猶豫轉交給DBA,但是從目前我接到的deadlock的問題來看,和Oracle官方的描述基本都是一致的。
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:
死結在Oracle中處理時,會自動事務相關的DML語句撤銷。換句話說,就是Oracle對於死結 問題的處理時一個主動的過程,會主動切斷其中一個session的事務鎖。
先來看一個簡單的死結案例。
我們建立兩個表lock_test1,lock_test2,然後使用兩個session來說明。
session1:
首先在session1中先建立兩個表,lock_test1,lock_test2
n1@TEST11G> create table lock_test1 as select *from cat;
Table created.
n1@TEST11G> create table lock_test2 as select *from cat;
Table created.
然後嘗試對lock_test1做delete操作。
n1@TEST11G> delete from lock_test1;
20 rows deleted.
session2:
然後切換到session2,對lock_test2做delete操作。
n1@TEST11G> delete from lock_test2;
21 rows deleted.
緊接著,在session1中對lock_test2做delete操作,這個時候出現阻塞的情況,一直沒有響應。
session1:
n1@TEST11G> delete from lock_test2;
我們在session2中,繼續對錶Lock_test1做delete操作,這個時候會有短暫的停頓,就會發現session1中的事務被強行撤銷了。
session2:
n1@TEST11G> delete from lock_test1;
session1中的日誌如下,可以看到這個時候session1中的事務被強行撤銷了。
n1@TEST11G> delete from lock_test2;
delete from lock_test2
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
這個問題可以簡單用下面的步驟來說明。
?Session a table1
?Session b table2
?Session a table 2
?Session b table1
到此為止我們可以看到,死結產生的影響是很大的,當然,問題還不止於此,在多個表之間很可能存在死結現象,對於一個表,也有可能出現死結現象。
我們來簡單說明樣本一下。
session1:
create table test as select *from user_tables;
n1@TEST11G> delete from test where table_name='LOCK_TEST1';
1 row deleted.
session2:
n1@TEST11G> DELETE FROM TEST WHERE TABLE_NAME='LOCK_TEST2';
1 row deleted.
session1:
n1@TEST11G> DELETE FROM TEST WHERE TABLE_NAME='LOCK_TEST2';
session2:
n1@TEST11G> DELETE FROM TEST WHERE TABLE_NAME='LOCK_TEST1';
這個時候還是會出現一樣的死結問題,這個時候在對應的行上會有相應的鎖。在session2中會有短暫的停頓,然後把session1中的
給撤銷了,產生的日誌如下:
DELETE FROM TEST WHERE TABLE_NAME='LOCK_TEST2'
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
可見死結的問題還是很容易產生的,在編程中處理多並發的處理時還是需要多多注意。