“Oracle兩個同時進行的insert不會被阻塞…..”

Oracle是目前支援並行操作處理最好的資料庫系統。在開始提供商業化資料庫產品的階段，事務行鎖和多版本一致讀的特性就奠定了Oracle商業資料庫領軍的地位。這兩個特性的最終目的就是提高資料庫系統的併發操作能力。

併發操作可以最大限度的提升系統的整體效能，但是也必然引起資源的公用。無論在資料庫系統，還是在作業系統等其他系統中，資源的共享與互斥必然回引入鎖技術。過小的範圍鎖不能滿足資源共享保護需求，過大的範圍鎖又會限制並行特性的發揮。

多版本一致讀

在Oracle中，一般性select讀操作是不會阻塞其他dml操作的。同時，在進行dml操作的時候，也不會影響到select操作獲取資料。舉例來說：當一個會話session1進行資料表資料dml操作的時候，沒有進行commit/rollback操作。另一個會話session2是可以進行select操作，獲取的資料是session1進行修改之前的資料。

當session1提交了事務之後，所有會話select的資料就是提交之後的資料集合。整個過程中，所有其他會話發出的select操作是不會因為session1的事務而被阻塞。

事務行級鎖

事務行級鎖是Oracle的另一個出色特性。當進行事務的時候，為了防止其他會話對資料進行修改，不同的資料庫系統是採用不同的控制方法的。通常的做法有資料表級鎖、頁級鎖等。但是這些型別鎖都不免將鎖定資源的範圍擴大化。Oracle提供了事務行級鎖，每個事務只會鎖定該事務修改的資料行，不會影響到其他與事務無關的資料。一些資料中，將Oracle這個特性也叫行級鎖，很多人理解為Oracle在每個資料行進行加鎖，這實際上是不準確的。因為即使我們修改了多行，從Oracle的角度看，也只是加了一個鎖，鎖住了多行資料集而已。

那麼，回到開篇的“Oracle兩個同時進行的insert不會被阻塞…..”，這種說法對嗎？下面我們分別進行一系列的實驗，來證明這種說法。

下面是環境準備。

SQL> conn scott/tiger@orcl;

已連線。

SQL> create table t (id number(10), name varchar2(20));

表已建立。

SQL> alter table t add constraint pk_t_id primary key (id); //確立主鍵

表已更改。

1、無關資料行插入

首先我們同時使用兩個會話，進行無關資料行的插入。

//session1

SQL> conn scott/tiger@orcl;

已連線。

SQL> select sid from v$mystat where rownum<2;

SID

----------

158

SQL> insert into t values (1,'ddd');

已建立 1 行。

首先，啟動了一個會話（sid=158），下面開啟另一個會話。

//session2

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 2月 19 20:15:16 2011

SQL> conn scott/tiger@orcl;

已連線。

SQL> select sid from v$mystat where rownum<2;

SID

----------

141

SQL> insert into t values(2,'dkl');

已建立 1 行。

我們發現，啟動兩個會話，同時開啟資料庫事務，插入兩條無關資料，不會發生阻塞。注意：我們強調的是無關資料，就是兩條資料可以在資料表中提交併存。

此時，我們觀察一下系統的鎖檢視情況。

//鎖狀態

SQL> select * from v$locked_object;

XIDUSN XIDSLOT XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAME OS_USER_NAME PROCESS LOCKED_MODE

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

4 45 870 53606 141 SCOTT IBM-VS2A1BHCNS0\ibm 772:3932 3

3 19 842 53606 158 SCOTT IBM-VS2A1BHCNS0\ibm 636:1036 3

//object_id=53606對應資料表T

SQL> select * from dba_objects where object_id=53606;

OWNER OBJECT_NAME

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

SCOTT T

//鎖狀態檢查

SQL> select * from v$lock where sid in (141,158);

ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK

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

6BDC4074 6BDC408C 158 TM 53606 0 3 0 226 0

6BDC4138 6BDC4150 141 TM 53606 0 3 0 214 0

6BE185A8 6BE186C4 158 TX 196627 842 6 0 226 0

6BE29A54 6BE29B70 141 TX 262189 870 6 0 214 0

SQL> select sid, serial#, lockwait, sql_id, blocking_session_status,EVENT#, EVENT

2 from v$session where sid in (141,158);

SID SERIAL# LOCKWAIT SQL_ID BLOCKING_SESSION_STATUS EVENT# EVENT

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

141 47 NO HOLDER 256 SQL*Net message from client

158 122 NO HOLDER 256 SQL*Net message from client

額外說明：檢視v$locked_object前三個資料列，xidusn為進行dml操作時候，使用undo段的編號，xidslot為段物件的slot編號，xidsqn為段物件的系列號。三個欄位表示了物件在undo表空間上的對應位置。對應的xidsqn對應v$lock鎖的id2屬性。

從v$lock檢視的情況下，我們不難發現並行插入的過程。首先，兩個會話在資料表T上加一個表級別（TM）的共享鎖（LMODE=3）。LMODE=3是可以共享的，在資料表上加共享鎖的目的就是防止在事務進行中，嘗試對資料表結構進行一些修改。同時，在不同的資料行，發起事務鎖（TX），模式為獨佔模式。分別排他鎖住兩個資料行。這兩個會話事務結構之間不會發生阻塞情況。

那麼，在這樣的方式下，是不是不會發生blocking型別的阻塞？下面我們進行一些其他實驗。

DML操作引起的blocking（一）

相關文章