共計 2704 個字符,預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要介紹了 LOCK 中如何實現模擬鎖等待現象,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓丸趣 TV 小編帶著大家一起了解一下。
1. 模擬“鎖等待”現象
1)開啟一個終端創建測試表 test_lock,插入一條數據,模擬更新該條數據,但不提交
sys@orcl conn sec/sec
Connected.
sec@orcl create table test_lock (a int);
Table created.
sec@orcl insert into test_lock values (1);
1 row created.
sec@orcl commit;
Commit complete.
sec@orcl select * from test_lock;
A
———-
1
sec@orcl update test_lock set a = 2;
1 row updated.
2)再另外開啟一個終端,對同樣的行進行另外的更新,隨即出現鎖等待的現象
sys@orcl conn sec/sec
Connected.
sec@orcl
sec@orcl
sec@orcl update test_lock set a = 3;
因為更新都是 test_lock 表中 1 這行的記錄,第一個用戶提交了修改但是沒有提交,在這里會出現無法繼續執行的現象,這種現象就是“鎖等待”,千萬不要再說這個現象是“死鎖”啦,“死鎖”Oracle 是會自己處理的,有興趣的朋友可以查詢死鎖產生的四個條件,我們這個實驗只是討論最容易出現的“鎖等待”現象的處理方法。
2. 檢測“鎖等待”方法
sys@orcl @lock
lock lock
holder holder lock lock request blocked
username session id SERIAL# type id1 id2 mode mode BLOCK session id
—————— ———– ———- —— ———– ———– ——— ——— ———- ———-
SEC 148 23007 TM 303038 0 3 0 0
SEC 153 18219 TM 303038 0 3 0 0
SEC 153 18219 TX 262159 306200 6 0 1 148
165 1 TS 3 1 3 0 0
166 1 CF 0 0 2 0 0
166 1 RS 25 1 2 0 0
166 1 XR 4 0 1 0 0
167 1 RT 1 0 6 0 0
8 rows selected.
通過上面腳本的執行可以清楚的看出,首先,存在鎖等待現象,因為最后一列存在不為空的會話 id 信息,其次,可以通過上面所列出來的鎖的信息判斷出因為 153 會話中執行的 SQL 語句導致 148 會話的 SQL 語句無法執行。
3.“鎖等待”處理方法
1)溫柔方法
通過個人魅力找到 153 會話操作的弟兄,溫柔的提醒他請將未提交的 SQL 語句做提交或回滾處理,以便釋放相應的行級鎖。
2)暴力方法
直接殺死 153 會話,方法如下:
sys@orcl alter system kill session 153,18219
System altered.
到此,向你抱怨長時間未運行完成的 SQL 語句神奇般的恢復了本應有的速度。
4.OK,是該隆重推出我用來檢測“鎖等待”的腳本的時候了,大家請看
—————————————————
— Script. Function: Query the lock info —
— Script. Name: lock.sql —
— Author: secooler —
— Date: 2008.3.6 —
—————————————————
set pages 1000 lin 126
col kaddr heading lock|address
col username heading lock|holder|username for a18
col sid heading lock|holder|session id format 9999999999
col type heading lock|type format a6
col id1 heading id1 format 9999999999
col id2 heading id2 format 9999999999
col lmode heading lock|mode format 99999999
col request heading request|mode format 99999999
col blocking_sid format 999999 heading blocked|session id
select /*+rule*/
— a.kaddr, —
(select username from v$session where sid = a.sid) username,
a.sid,
(select serial# from v$session where sid = a.sid) serial#,
— (select ctime from v$lock where KADDR = a.kaddr) ctime, —
a.type,
a.id1,
a.id2,
a.lmode,
a.request,
a.block,
b.sid blocking_sid
from v$lock a,
(select * from v$lock
where request 0
and type MR
) b
where a.id1 = b.id1(+)
and a.id2 = b.id2(+)
and a.lmode 0
and a.type MR
order by username,a.sid,serial#,a.type
/
column sid clear
column type clear
column request clear
column username clear
5. 總結
“鎖等待”現象是一種常見的數據庫問題,往往出現在多人(往往是技術支持人員)同時操作數據庫的時候。在出現此類問題的時候,要沉著、認真、快速、準確的定位問題,排除故障。當然如果能采用非常嚴格的數據庫操作制度以便防止此類問題的發生的話,那是最好不過的了,所以說七分管理三分處理。
好運!
感謝你能夠認真閱讀完這篇文章,希望丸趣 TV 小編分享的“LOCK 中如何實現模擬鎖等待現象”這篇文章對大家有幫助,同時也希望大家多多支持丸趣 TV,關注丸趣 TV 行業資訊頻道,更多相關知識等著你來學習!