ORACLE鎖機制深入理解

資料庫是一個多使用者使用的共用資源。當多個使用者並發地存取資料時，在資料庫中就會產生多個事務同時存取同一資料的情況。若對並行作業不加控制就可能會讀取和儲存不正確的資料，破壞資料庫的一致性。
加鎖是實現資料庫並發控制的一個非常重要的技術。當事務在對某個資料對象進行操作前，先向系統發出請求，對其加鎖。加鎖後事務就對該資料對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此資料對象進行更新操作。
在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共用鎖定（Share Locks，即S鎖）。當資料對象被加上排它鎖時，其他的事務不能對它讀取和修改。加了共用鎖定的資料對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。

Oracle資料庫的鎖類型
根據保護的對象不同，Oracle資料庫鎖可以分為以下幾大類：DML鎖（data locks，資料鎖），用於保護資料的完整性；DDL鎖（dictionary locks，字典鎖），用於保護資料庫物件的結構，如表、索引等的結構定義；內部鎖和閂（internal locks and latches），保護 資料庫的內部結構。
DML鎖的目的在於保證並發情況下的資料完整性，。在Oracle資料庫中，DML鎖主要包括TM鎖和TX鎖，其中TM鎖稱為表級鎖，TX鎖稱為事務鎖或行級鎖。

當Oracle執行DML語句時，系統自動在所要操作的表上申請TM類型的鎖。當TM鎖獲得後，系統再自動申請TX類型的鎖，並將實際鎖定的資料行的鎖標誌位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標誌，而只需檢查TM鎖模式的相容性即可，大大提高了系統的效率。TM鎖包括了SS、SX、S、X 等多種模式，在資料庫中用0－6來表示。不同的SQL操作產生不同類型的TM鎖。

在資料行上只有X鎖（獨佔鎖定）。在Oracle資料庫中，當一個事務首次發起一個DML語句時就獲得一個TX鎖，該鎖保持到事務被提交或復原。當兩個或多個會話在表的同一條記錄上執行 DML語句時，第一個會話在該條記錄上加鎖，其他的會話處於等待狀態。當第一個會話提交後，TX鎖被釋放，其他會話才可以加鎖。

當Oracle資料庫發生TX鎖等待時，如果不及時處理常常會引起Oracle資料庫掛起，或導致死結的發生，產生ORA-60的錯誤。這些現象都會對實際應用產生極大的危害，如長時間未響應，大量事務失敗等。

悲觀封鎖和樂觀封鎖
一、悲觀封鎖
鎖在使用者修改之前就發揮作用：
Select ..for update（nowait)
Select * from tab1 for update
使用者發出這條命令之後，oracle將會對返回集中的資料建立行級封鎖，以防止其他使用者的修改。
如果此時其他使用者對上面返回結果集的資料進行dml或ddl操作都會返回一個錯誤資訊或發生阻塞。
1：對返回結果集進行update或delete操作會發生阻塞。
2：對該表進行ddl操作將會報：Ora-00054:resource busy and acquire with nowait specified.
原因分析
此時Oracle已經對返回的結果集上加了排它的行級鎖，所有其他對這些資料進行的修改或刪除操作都必須等待這個鎖的釋放，產生的外在現象就是其他的操作將發生阻塞，這個這個操作commit或rollback.
同樣這個查詢的事務將會對該表加表級鎖，不允許對該表的任何ddl操作，否則將會報出ora-00054錯誤：:resource busy and acquire with nowait specified.

二、樂觀封鎖
樂觀的認為資料在select出來到update進取並提交的這段時間資料不會被更改。這裡面有一種潛在的危險就是由於被選出的結果集並沒有被鎖定，是存在一種可能被其他使用者更改的可能。因此Oracle仍然建議是用悲觀封鎖，因為這樣會更安全。

阻塞
定義：
當一個會話保持另一個會話正在請求的資源上的鎖定時，就會發生阻塞。被阻塞的會話將一直掛起，直到持有鎖的會話放棄鎖定資源為止。4個常見的dml語句會產生阻塞
INSERT
UPDATE
DELETE
SELECT…FOR UPDATE

INSERT
Insert發生阻塞的唯一情況就是使用者擁有一個建有主鍵約束的表。當2個的會話同時試圖向表中插入相同的資料時，其中的一個會話將被阻塞，直到另外一個會話提交或會滾。一個會話提交時，另一個會話將收到主鍵重複的錯誤。復原時，被阻塞的會話將繼續執行。
UPDATE 和DELETE當執行Update和delete操作的資料行已經被另外的會話鎖定時，將會發生阻塞，直到另一個會話提交或會滾。
Select …for update
當一個使用者發出select..for update的錯作準備對返回的結果集進行修改時，如果結果集已經被另一個會話鎖定，就是發生阻塞。需要等另一個會話結束之後才可繼續執行。可以通過發出 select… for update nowait的語句來避免發生阻塞，如果資源已經被另一個會話鎖定，則會返回以下錯誤：Ora-00054:resource busy and acquire with nowait specified.
死結-deadlock
定義:當兩個使用者希望持有對方的資源時就會發生死結.
即兩個使用者互相等待對方釋放資源時,oracle認定為產生了死結,在這種情況下,將以犧牲一個使用者作為代價,另一個使用者繼續執行,犧牲的使用者的事務將復原.
例子：
1：使用者1對A表進行Update，沒有提交。
2：使用者2對B表進行Update，沒有提交。
此時雙反不存在資源共用的問題。
3：如果使用者2此時對A表作update,則會發生阻塞，需要等到使用者一的事物結束。
4：如果此時使用者1又對B表作update，則產生死結。此時Oracle會選擇其中一個使用者進行會滾，使另一個使用者繼續執行操作。
起因:
Oracle的死結問題實際上很少見，如果發生，基本上都是不正確的程式設計造成的，經過調整後，基本上都會避免死結的發生。

DML鎖分類表
表1Oracle的TM鎖類型
鎖模式 鎖描述 解釋 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行級共用鎖定，其他對象
只能查詢這些資料行 Select for update、Lock for
update、Lock row share
3 SX(Row-X) 行級排它鎖，
在提交前不允許做DML操作 Insert、Update、
Delete、Lock row share
4 S(Share) 共用鎖定 Create index、Lock share
5 SSX(S/Row-X) 共用行級排它鎖 Lock share row exclusive
6 X(Exclusive) 排它鎖 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
oracle 鎖問題的解決

可以用Spotlight軟體對資料庫的運行狀態進行監控。
當出現session鎖時，我們要及時進行處理.
1. 查看哪些session鎖:
SQL語句：select 'alter system kill session '''||sid||','||serial#||''';' from v$session where sid in (select sid from v$lock where block = 1);
SQL> select 'alter system kill session '''||sid||','||serial#||''';' from v$session where sid in (select sid from v$lock where block = 1);
'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||''';'
--------------------------------------------------------------------------------
alter system kill session '132,731';
alter system kill session '275,15205';
alter system kill session '308,206';
alter system kill session '407,3510';
2. 查看session鎖.
sql語句：select s.sid, q.sql_text from v$sqltext q, v$session s
where q.address = s.sql_address
and s.sid = &sid
order by piece;
SQL> select s.sid,q.sql_text from v$sqltext q, v$session s where q.address = s.sql_address and s.sid in (select sid from v$lock where block = 1) order by piece;
SID SQL_TEXT
---------- ----------------------------------------------------------------
77 UPDATE PROFILE_USER SET ID=1,COMPANY_ID=2,CUSTOMER_ID=3,NAMED
77 _INSURED_ID=4,LOGIN=5,ROLE_ID=6,PASSWORD=7,EMAIL=8,TIME_ZON
77 E=9 WHERE PROFILE_USER.ID=:34
3 rows selected.

3. kill鎖的進程.
SQL語句：alter system kill session '77,22198';
SQL> alter system kill session '391,48398';
System altered.
4. 查看誰鎖了誰。
select s1.username || [email='@']'@'[/email] || s1.machine
|| ' ( SID=' || s1.sid || ' ) is blocking '
|| s2.username || [email='@']'@'[/email] || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
from v$lock l1, v$session s1, v$lock l2, v$session s2
where s1.sid=l1.sid and s2.sid=l2.sid
and l1.BLOCK=1 and l2.request > 0
and l1.id1 = l2.id1
and l2.id2 = l2.id2 ;
註：
> ： 重新導向輸出，將檔案的標準輸出重新定向輸出到檔案，或將資料檔案作為另一程式的標準輸入內容。
| ：UNIX管道：將一檔案的輸出作為另一檔案的輸入.
在執行SQL語句試：alter system kill session '391,48398'(sid為391); 應當注意對於sid在100以下的應當謹慎，可能該進程對應某個application，如對應某個事務,可以kill.