簡單說明Oracle數(shù)據(jù)庫中對死鎖的查詢及解決方法
死鎖的原理
當(dāng)對于數(shù)據(jù)庫某個表的某一列做更新或刪除等操作,執(zhí)行完畢后該條語句不提
交,另一條對于這一列數(shù)據(jù)做更新操作的語句在執(zhí)行的時候就會處于等待狀態(tài),
此時的現(xiàn)象是這條語句一直在執(zhí)行,但一直沒有執(zhí)行成功,也沒有報錯。
死鎖的定位方法
通過檢查數(shù)據(jù)庫表,能夠檢查出是哪一條語句被死鎖,產(chǎn)生死鎖的機器是哪一臺。
1)用dba用戶執(zhí)行以下語句
select username,lockwait,status,machine,program from v$session where sid in (select session_id from v$locked_object)
如果有輸出的結(jié)果,則說明有死鎖,且能看到死鎖的機器是哪一臺。字段說明:
- Username:死鎖語句所用的數(shù)據(jù)庫用戶;
- Lockwait:死鎖的狀態(tài),如果有內(nèi)容表示被死鎖。
- Status: 狀態(tài),active表示被死鎖
- Machine: 死鎖語句所在的機器。
- Program: 產(chǎn)生死鎖的語句主要來自哪個應(yīng)用程序。
2)用dba用戶執(zhí)行以下語句,可以查看到被死鎖的語句。
select sql_text from v$sql where hash_value in (select sql_hash_value from v$session where sid in (select session_id from v$locked_object))
死鎖的解決例子
死鎖在Oracle中處理時,會自動事務(wù)相關(guān)的DML語句撤銷。換句話說,就是Oracle對于死鎖 問題的處理時一個主動的過程,會主動切斷其中一個session的事務(wù)鎖。
先來看一個簡單的死鎖案例。
我們創(chuàng)建兩個表lock_test1,lock_test2,然后使用兩個session來說明。
session1:
首先在session1中先創(chuàng)建兩個表,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操作,這個時候出現(xiàn)阻塞的情況,一直沒有響應(yīng)。
session1:
n1@TEST11G> delete from lock_test2;
我們在session2中,繼續(xù)對表Lock_test1做delete操作,這個時候會有短暫的停頓,就會發(fā)現(xiàn)session1中的事務(wù)被強行撤銷了。
session2:
n1@TEST11G> delete from lock_test1;
session1中的日志如下,可以看到這個時候session1中的事務(wù)被強行撤銷了。
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
到此為止我們可以看到,死鎖產(chǎn)生的影響是很大的,當(dāng)然,問題還不止于此,在多個表之間很可能存在死鎖現(xiàn)象,對于一個表,也有可能出現(xiàn)死鎖現(xiàn)象。
我們來簡單說明示例一下。
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';
這個時候還是會出現(xiàn)一樣的死鎖問題,這個時候在對應(yīng)的行上會有相應(yīng)的鎖。在session2中會有短暫的停頓,然后把session1中的
給撤銷了,產(chǎn)生的日志如下:
DELETE FROM TEST WHERE TABLE_NAME='LOCK_TEST2' * ERROR at line 1: ORA-00060: deadlock detected while waiting for resource
可見死鎖的問題還是很容易產(chǎn)生的,在編程中處理多并發(fā)的處理時還是需要多多注意。
相關(guān)文章
oracle中fdisk導(dǎo)致的ASM磁盤數(shù)據(jù)丟失的解決方法
oracle中fdisk 導(dǎo)致的ASM磁盤數(shù)據(jù)丟失 有需要的朋友可參考一下2012-10-10使用geotools導(dǎo)入shp文件到Oracle數(shù)據(jù)庫時表名帶下劃線問題的解決方法
這篇文章主要介紹了使用geotools導(dǎo)入shp文件到Oracle數(shù)據(jù)庫時表名帶下劃線的問題解決 的相關(guān)資料,需要的朋友可以參考下2016-08-08oracle to_char函數(shù)將number轉(zhuǎn)成string
很多數(shù)據(jù)轉(zhuǎn)換處理操作時,會遇到將0.007007040000轉(zhuǎn)換成0.70%的需求,我們使用Oracle 的SQL 函數(shù) to_char可以實現(xiàn)這種轉(zhuǎn)換,需要了解的朋友可以參考下2012-11-11