造成死鎖的原因就是多個線程或進程對同一個資源的爭搶或相互依賴。這里列舉一個對同一個資源的爭搶造成死鎖的實例。
十余年的東昌網(wǎng)站建設(shè)經(jīng)驗,針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù),響應(yīng)快,48小時及時工作處理。全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動調(diào)整東昌建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計,從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“東昌網(wǎng)站設(shè)計”,“東昌網(wǎng)站推廣”以來,每個客戶項目都認真落實執(zhí)行。
CREATE TABLE testLock( ID NUMBER,
test VARCHAR (100) )
COMMIT
INSERT INTO testLock VALUES (1, 'test1' );
INSERT INTO testLock VALUES (2, 'test2' );
COMMIT ;
SELECT * FROM testLock
ID TEST
---------- ----------------------------------
1 test1
2 test2
死鎖現(xiàn)象的重現(xiàn):
1. 在sql 窗口 執(zhí)行:SELECT * FROM testLock FOR UPDATE; -- 加行級鎖 并對內(nèi)容進行修改,不要提交
查看引起死鎖的語句:
SQL> 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));
查出以下語句死鎖:
delete from testLock where ID = 1
死鎖的處理:
alter system kill session 'session_id,serial#';
alter system kill session '301,16405';
再查看一下死鎖,會發(fā)現(xiàn)已經(jīng)沒有stauts為active的記錄了,
發(fā)生死鎖的語句已經(jīng)被終止。
客戶的10.2.0.4 RAC for AIX環(huán)境頻繁出現(xiàn)ORA-60死鎖問題,導(dǎo)致應(yīng)用程序無法順利執(zhí)行。
經(jīng)過一系列的診斷,發(fā)現(xiàn)最終問題是由于外鍵上沒有建立索引所致,由于程序在主子表上刪除數(shù)據(jù),缺少索引導(dǎo)致行級鎖升級為表級鎖,最終導(dǎo)致大量的鎖等待和死鎖。
下面通過一個例子簡單模擬一下問題:
SQL> create table t_p (id number primary key, name varchar2(30));
Table created.
SQL> create table t_f (fid number, f_name varchar2(30), foreign key (fid) references t_p);
Table created.
SQL> insert into t_p values (1, 'a');
1 row created.
SQL> insert into t_f values (1, 'a');
1 row created.
SQL> insert into t_p values (2, 'b');
1 row created.
SQL> insert into t_f values (2, 'c');
1 row created.
SQL> commit;
Commit complete.
SQL> delete t_f where fid = 2;
1 row deleted.
這時在會話2同樣對子表進行刪除:
SQL2> delete t_f where fid = 1;
1 row deleted.
回到會話1執(zhí)行主表的刪除:
SQL> delete t_p where id = 2;
會話被鎖,回到會話2執(zhí)行主表的刪除:
SQL2> delete t_p where id = 1;
會話同樣被鎖,這時會話1的語句被回滾,出現(xiàn)ORA-60死鎖錯誤:
delete t_p where id = 2
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
SQL> rollback;
Rollback complete.
將會話1操作回滾,會話2同樣回滾并建立外鍵列上的索引:
1 row deleted.
SQL2> rollback;
Rollback complete.
SQL2> create index ind_t_f_fid on t_f(fid);
Index created.
重復(fù)上面的步驟會話1刪除子表記錄:
SQL> delete t_f where fid = 2;
1 row deleted.
會話2刪除子表記錄:
SQL2> delete t_f where fid = 1;
1 row deleted.
會話1刪除主表記錄:
SQL> delete t_p where id = 2;
1 row deleted.
會話2刪除主表記錄:
SQL> delete t_p where id = 1;
1 row deleted.
所有的刪除操作都可以成功執(zhí)行,關(guān)于兩種情況下鎖信息的不同這里就不深入分析了,重點就是在外鍵列上建立索引。
雖然有一些文章提到過,如果滿足某些情況,可以不在外鍵列上建立的索引,但是我的觀點一向是,既然創(chuàng)建了外鍵,就不要在乎再多一個索引,因為一個索引所增加的代價,與缺失這個索引所帶來的問題相比,是微不足道的。
網(wǎng)站標題:Oracle常見死鎖發(fā)生的原因以及解決方法
網(wǎng)頁URL:http://aaarwkj.com/article26/gipijg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供關(guān)鍵詞優(yōu)化、網(wǎng)站內(nèi)鏈、、網(wǎng)站策劃、小程序開發(fā)、響應(yīng)式網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)