ORACLE鎖介紹

shely發表於2009-02-19

深入淺出oracle鎖---原理篇

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


深入淺出oracle鎖---原理篇在現代的多使用者多工系統中,必然會出現多個使用者同時訪問共享的某個物件,這個物件可能是表,行,或者記憶體結構,為了解決多個使用者併發性訪問帶來的資料的安全性,完整性及一致性問題,必須要有一種機制,來使對這些共享資源的併發性訪問序列化,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 字典鎖,用來保護資料物件的結構,如table,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 即lock 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來表示。不同的SQL操作產生不同型別的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---鎖阻塞的分析

上篇深入淺出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 segmentslot

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,結合上一個查詢,可以看到,該會話對30139emp表加了lmode=3的鎖,即rx鎖,同時,對30137dept加了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)30137dept加了lmode=3的鎖,即rx鎖。同時請求對30139emp表加了lmode=4的鎖,即s(request=4)但該請求被阻塞(srx不相容),可以通過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語句

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等於78767369job欄位值都是’CLERK’,而我們恰恰在job欄位建立了點陣圖索引,第一個dml語句引起了對job=CLERK點陣圖段的鎖定,進而阻塞了第二個會話對該點陣圖段其他記錄的dml操作(注:如此時對job<>CLERK的記錄做dml是不會阻塞的)。

三:Maxtrans帶來的阻塞

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

SQL> drop index bidx_emp_job;

索引已丟棄。

SQL> alter table 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被阻塞

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7299296/viewspace-555687/,如需轉載,請註明出處,否則將追究法律責任。

相關文章