深入淺出oracle鎖（ZT）

在網上看到蠻不錯的鎖介紹，收藏一下。

深入淺出鎖---原理篇

深入淺出鎖---鎖阻塞的分析

[@more@] 深入淺出鎖---原理篇在現代的多使用者多工系統中，必然會出現多個使用者同時訪問共享的某個物件，這個物件可能是表，行，或者記憶體結構，為了解決多個使用者併發性訪問帶來的資料的安全性，完整性及一致性問題，必須要有一種機制，來使對這些共享資源的併發性訪問序列化，oracle中的鎖就可以提供這樣的功能，當在對某個物件進行操作前，先向系統發出請求，對其加相應的鎖，加鎖後該事務就對該資料物件有了一定的控制許可權，在該事務釋放鎖之前，其他的事務不能對此資料物件進行更新操作（可以做select動作，但select 利用的是undo中的前映象資料了）.
Oracle鎖的分類Oracle鎖基本上可以分為二類
a：共享鎖（share locks） 也稱讀鎖，s鎖
b：排它鎖 (exclusive locks) 也稱寫鎖，x鎖
在中有兩種基本的鎖型別：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當資料物件被加上排它鎖時，其他的事務不能對它讀取和修改。加了共享鎖的資料物件可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖型別來對資料庫的事務進行併發控制。

按鎖保護的內容分類
oracle提供多粒度封鎖機制，按保護物件來分，據此又可以分為
a：dml鎖， data locks 資料鎖，用來保護資料的完整性和一致性
b：ddl鎖， dictionary locks 字典鎖，用來保護資料物件的結構，如，index的定義
c：內部鎖和閂 internal locks and latchs 用來保護資料庫內部結構，如sga記憶體結構

dml鎖
DML鎖主要包括TM鎖和TX鎖，其中TM鎖稱為表級鎖，TM鎖的種類有S,X,SR,SX,SRX五種，TX鎖稱為事務鎖或行級鎖。當Oracle執行delete,update,insert,select for update DML語句時，oracle首先自動在所要操作的表上申請TM型別的鎖。當TM鎖獲得後，再自動申請TX型別的鎖，並將實際鎖定的資料行的鎖標誌位(lb 即 bytes)進行置位。在記錄被某一會話鎖定後，其他需要訪問被鎖定物件的會話會按先進先出的方式等待鎖的釋放，對於select操作而言，並不需要任何鎖，所以即使記錄被鎖定，select語句依然可以執行，實際上，在此情況下，oracle是用到undo的內容進行一致性讀來實現的。

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

在資料表上，oracle預設是共享鎖，在執行dml語句的時候，oracle會先申請物件上的共享鎖，防止其他會話在這個物件上做ddl語句，成功申請表上的共享鎖後，再在受影響的記錄上加排它所，防止其他會話對這些做修改動作。

這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標誌，而只需檢查TM鎖模式的相容性即可，大大提高了系統的效率。TM鎖包括了SS、SX、S、X等多種模式，在資料庫中用0－6來表示。不同的操作產生不同型別的TM鎖。如表1所示。

和鎖相關的效能檢視介紹
v$lock
SID 會話的sid，可以和v$session 關聯
TYPE 區分該鎖保護物件的型別，如tm，tx，rt，mr等
ID1 鎖表示1，詳細見下說明
ID2 鎖表示2，詳細見下說明
LMODE 鎖模式，見下面說明
REQUEST 申請的鎖模式，同lmode
CTIME 已持有或者等待鎖的時間
BLOCK 是否阻塞其他會話鎖申請 1:阻塞 0:不阻塞

LMODE取值0,1,2,3,4,5,6, 數字越大鎖級別越高, 影響的操作越多。
1級鎖：
Select，有時會在v$locked_object出現。
2級鎖即RS鎖
相應的sql有：Select for update ,Lock xxx in Row Share mode，select for update當對
話使用for update子串開啟一個遊標時，所有返回集中的資料行都將處於行級(Row-X)獨
佔式鎖定，其他物件只能查詢這些資料行，不能進行update、delete或select for update
操作。
3級鎖即RX鎖
相應的sql有：Insert, Update, Delete, Lock xxx in Row Exclusive mode，沒有commit
之前插入同樣的一條記錄會沒有反應, 因為後一個3的鎖會一直等待上一個3的鎖, 我們
必須釋放掉上一個才能繼續工作。
4級鎖即S鎖
相應的sql有：Create Index, Lock xxx in Share mode
5級鎖即SRX鎖
相應的sql有：Lock xxx in Share Row Exclusive mode，當有主外來鍵約束時update
/delete ... ; 可能會產生4,5的鎖。
6級鎖即X鎖
相應的sql有：Alter table, Drop table, Drop Index, Truncate table, Lock xxx in Exclusive
mode

ID1,ID2的取值含義根據type的取值而有所不同
對於TM 鎖
ID1表示被鎖定表的object_id 可以和dba_objects檢視關聯取得具體表資訊，ID2 值為0
對於TX 鎖
ID1以十進位制數值表示該事務所佔用的回滾段號和事務槽slot number號,其組形式:
0xRRRRSSSS,RRRR=RBS/UNDO NUMBER,SSSS=SLOT NUMBER
ID2 以十進位制數值表示環繞wrap的次數，即事務槽被重用的次數

v$locked_object
XIDUSN undo segment number ， 可以和v$transaction關聯
XIDSLOT undo slot number
XIDSQN 序列號
OBJECT_ID 被鎖定物件的object_id ， 可以和dba_objects關聯
SESSION_ID 持有該鎖的session_id， 可以和v$session關聯
ORACLE_USERNAME 持有該鎖的oracle帳號
OS_USER_NAME 持有該鎖的作業系統帳號
PROCESS 作業系統的程式號，可以和v$process關聯
LOCKED_MODE 鎖模式，含義同v$lock.lmode

Dba_locks 和v$lock 內容差不多,略

V$session 如果某個session被因為某些行被其他會話鎖定而阻塞，則該檢視中的下面四個欄位列出了這些行所屬物件的相關資訊
ROW_WAIT_FILE# 等待的行所在的檔案號
ROW_WAIT_OBJ# 等待的行所屬的object_id
ROW_WAIT_BLOCK# 等待的行所屬的block
ROW_WAIT_ROW# 等待的行在blcok中的位置

手工釋放鎖
alter system kill session 'sid,serial#';

深入淺出鎖---鎖阻塞的分析

上篇深入淺出oracle鎖---原理篇是以理論為主，此文章列舉三個關於鎖阻塞的例子，並對此作詳細的說明，話不多說，直接開題。

一：外來鍵沒有索引，引起阻塞

外來鍵沒有建立索引而引起的阻塞應該是最常見到，下面舉例對此詳細分析

SQL> DELETE EMP WHERE EMPNO=7900;

已刪除1行。

SQL> Select sid,type,id1,id2,lmode,request,ctime,block From v$lock Where Type In ('TM','TX');

SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

---------- ---- ---------- ---------- ---------- ---------- ---------- ----------

10 TX 458791 1813 6 0 416 0

10 TM 30139 0 3 0 416 0

10 TM 30137 0 2 0 416 0

SQL> select trunc(458791/power(2,16)) ,mod(458791,power(2,16)) from dual;

TRUNC(458791/POWER(2,16)) MOD(458791,POWER(2,16))

------------------------- -----------------------

7 39

再來查v$transaction，看看sid=10會話當前使用的undo segment和slot

SQL> select addr,xidusn,xidslot,xidsqn from v$transaction

2 where addr in (select taddr from v$session where sid=10);

ADDR XIDUSN XIDSLOT XIDSQN

-------- ---------- ---------- ----------

67BAB0CC 7 39 1813

對於tx鎖，v$lock中的id1即為持有該鎖的的回滾段號，事務槽號的組合

再來看

SQL> select owner,object_name from dba_objects where object_id in (30139,30137);

OWNER OBJECT_NAME

------------------------------ --------------------------------------------------------------------------------

SCOTT DEPT

SCOTT EMP

對於tm鎖，id1即為持有該鎖的物件的id，結合上一個查詢，可以看到，該會話對30139即emp表加了lmode=3的鎖，即rx鎖，同時，對30137即dept加了lmode=2的鎖，即rs鎖。

接下來在另外一會話中執行如下語句

delete dept where1=0；

該會話被阻塞

檢視v$lock

SQL> Select sid,type,id1,id2,lmode,request,ctime,block From v$lock Where Type In ('TM','TX');

SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

---------- ---- ---------- ---------- ---------- ---------- ---------- ----------

10 TX 458791 1813 6 0 416 0

10 TM 30139 0 3 0 416 1

10 TM 30137 0 2 0 416 0

12 TM 30139 0 0 4 372 0

12 TM 30137 0 3 0 372 0

可以看到，另一個會話(sid=12)對30137即dept加了lmode=3的鎖，即rx鎖。同時請求對30139即emp表加了lmode=4的鎖，即s鎖(request=4)，但該請求被阻塞(s和rx不相容)，可以透過id1,id2,,block欄位看到，此會話sid=10會話阻塞。

接下來，在emp的外來鍵欄位deptno建立索引

SQL> create index idx_emp_dept on emp(deptno);

Index created

按原步驟重複上面的實驗

SQL> DELETE EMP WHERE EMPNO=7900;

已刪除1行。

SQL> Select sid,type,id1,id2,lmode,request,ctime,block From v$lock Where Type In ('TM','TX');

SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

---------- ---- ---------- ---------- ---------- ---------- ---------- ----------

10 TX 196632 2251 6 0 386 0

10 TM 30139 0 3 0 386 0

10 TM 30137 0 2 0 386 0

可以看到，是否建立索引，對emp表的鎖情況沒有影響。

在另外一個會話中執行如下語句

SQL> DELETE DEPT WHERE 1=0;

已刪除0行。

該語句沒有被阻塞，可以執行。看看當前的鎖資訊

SQL> Select sid,type,id1,id2,lmode,request,ctime,block From v$lock Where Type In ('TM','TX');

SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

---------- ---- ---------- ---------- ---------- ---------- ---------- ----------

10 TX 196632 2251 6 0 435 0

10 TM 30139 0 3 0 435 0

10 TM 30137 0 2 0 435 0

12 TM 30139 0 2 0 9 0

12 TM 30137 0 3 0 9 0

可以看到，在外來鍵上建立索引後，刪除父表，對子表加的是rs鎖，比沒有索引加s的強度要低，這樣避免了阻塞的發生，提高了系統的並行性。

二：點陣圖索引帶來的阻塞

點陣圖索引適合建在低基數列上面，在資料倉儲比較常用，如果是在併發性要求較高的oltp系統就要慎重了，不當的應用，可能會帶來嚴重的阻塞。

SQL> create bitmap index bidx_emp_job on emp(job);

索引已建立。

SQL> DELETE EMP WHERE EMPNO=7369;

已刪除1行。

在另外一會話中執行語句

SQL> DELETE EMP WHERE EMPNO=7876;

該語句阻塞

SQL> Select sid,type,id1,id2,lmode,request,ctime,block From v$lock Where Type In ('TM','TX');

SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

---------- ---- ---------- ---------- ---------- ---------- ---------- ----------

10 TX 524312 2362 6 0 116 1

10 TM 30139 0 3 0 116 0

10 TM 30137 0 2 0 116 0

12 TX 589864 2399 6 0 98 0

12 TM 30139 0 3 0 98 0

12 TM 30137 0 2 0 98 0

12 TX 524312 2362 0 4 98 0

可以看到，sid=12的會話等待sid=10持有的tx鎖，雖然刪除的是不同記錄，但因為

empno等於7876，7369的job欄位值都是’CLERK’,而我們恰恰在job欄位建立了點陣圖索引，第一個dml語句引起了對job=CLERK點陣圖段的鎖定，進而阻塞了第二個會話對該點陣圖段其他記錄的dml操作（注：如此時對job<>CLERK的記錄做dml是不會阻塞的）。

三：Maxtrans帶來的阻塞

在建立一個物件的時候，可以指定initrans，maxtrans引數，這二個引數指定了分配給該物件中每個block初始和最大允許併發事務數的，對每個事務，在其受影響的block內都對應一個itl，受其影響的行都會在行的 byte（lb）位置此itl號（dump一個dml過的但還沒有commit或者rollback的block可以清楚的看到），如果在一個併發性非常高的系統中，甚至超過了maxtrans的值(或者block的free space用完)，那麼oracle就無法增加itl，因此過低的maxtrans同樣會引起sql語句的阻塞。

SQL> drop index bidx_emp_job;

索引已丟棄。

SQL> alter emp maxtrans 3;

表已更改。

SQL>select distinct dbms_rowid.rowid_relative_fno(rowid) file_id,dbms_rowid.rowid_block_number(rowid) block_id from emp;

FILE_ID BLOCK_ID

---------- ---------

1 50466

所有的記錄都在1號檔案的50466塊，開三個session，分別刪除三條不同的記錄，三個session都可以正常執行，現在再開第四個session，刪除一個不同的記錄，該session被阻塞