深入理解資料庫鎖

oracle中分為兩種模式的鎖,一種是排他鎖(x鎖),另一種是共享所(s鎖).

鎖是實現併發的主要手段,在資料庫中應用頻繁,但很多都由資料庫自動管理,當事務提交後會自動釋放鎖.

oracle為了使資料庫實現高度併發訪問,它使用了不同型別的鎖來管理併發會話對資料物件的操作.oracle的鎖按作用物件不同分為如下幾種型別.

這裡主要介紹下常用的dml鎖,它主要保證了併發訪問時資料的完整性.它又可以分為以下兩種型別的鎖:

行級鎖(tx),也可以稱為事務鎖.當修改表中某行記錄時,需要對將要修改的記錄加行級鎖,防止兩個事務同時修改相同記錄,事務結束,該鎖也會釋放,是粒度最細的鎖.該鎖只能屬於排他鎖(x鎖).

表級鎖(tm),主要作用書防止在修改表的資料時,表的結構發生變化.例如,會話s在修改表a的資料時,它會得到表a的tm鎖,而此時將不允許其他會話對該錶進行變更或刪除操作. 該情況的驗證過程如下:

update table_name set column= 'test' where id = 'id';

此時已經鎖定該錶,表級鎖將不允許在事務結束前其他會話對錶table_name進行ddl操作.

其次,在執行drop table table_name操作,執行後會提示ora-00054錯誤.

原因是:

在執行dml操作時，資料庫會先申請資料物件上的共享鎖，防止其他會話對該物件執行ddl操作。一旦申請成功，則會對將要修改的記錄申請排他鎖，如果此時其他會話正在修改該記錄，那麼等待其事務結束後再為修改的記錄加上排他鎖。

下表列出了以上5中模式相互之間的相容關係.其中,✔表示相互相容,×表示相互不相容\rs

srxsrxxrs✔

✔✔✔×

s✔✔×

××rx✔

×✔✔×

srx✔××

××x×

××××

下面所示是oracle中的各種sql語句所產生的表級鎖模式以及允許的鎖定模式情況的彙總.

sql語句

表鎖模式rss

rxsrx

xselect ...from table

noneyy

yyyinsert into ...rxy

nynn

update table ...rxy

nynn

delete from table ...rxy

nynn

select * from table for updaterxy

nynn

lock table table in row share modersy

yyyn

lock table table in row exclusive moderxy

nynn

lock table table in share modesy

nnnn

lock table table in share row exclusive mode

srxynn

nnlock table table in exclusive modexn

nnnn

在oracle中除了執行dml時自動為表新增tm鎖外,也可以主動地為表新增tm鎖,語法如下:

lock table [schema.] table in 
[exclusive] 
[share]
[row exclusive]
[share row exclusive]
[row share* | share update*]
mode [nowait]

ddl鎖也可以稱為資料字典鎖,主要作用是保護模式中物件的結構.當執行ddl操作時首先oracle會自動地隱式提交一次事務,然後自動地給處理物件加上鎖;當ddl結束時,oracle會隱式地提交事務並釋放ddl鎖.與dml不同的是,使用者不能顯式的要求使用ddl鎖.

ddl鎖分為如下3類:

在某些情況下由於占用的資源不能及時釋放,而造成鎖等待,也可以叫鎖衝突.鎖等待會嚴重地影響資料庫效能和日常工作.

例如當乙個會話修改表a的記錄時,它會對該記錄加鎖,而此時如果另乙個會話也來修改此記錄,那麼第二個會話將因得不到排他鎖而一直等待,此時會出現執行sql時資料庫長時間沒有響應的現象.直到第乙個會話把事務提交,釋放鎖,第二個會話才能對資料進行操作.

下面為大家示例鎖等待現象:

開啟slq*plus視窗,修改productinfo 表中productid 欄位為1的記錄,指令碼如下:

update productinfo set origin = '修改1' where productid = 1;

此時雖然提示已更新,但事務並沒有提交.接下來進行第二步操作.

開啟另乙個sql*plus 視窗,同樣修改productinfo 表中productid欄位為1的記錄,指令碼如下:

update productinfo set origin = '修改2' where productid = 1;

此時執行效果不會提示已更新,而是一直等待.

此時的情況是因為第乙個會話封鎖了該記錄,但事務沒有結束,鎖不會釋放,而這時第二個會話也要修改同一條記錄,但它缺沒有辦法獲得排他鎖,所以只能等待.如果第乙個會話修改資料的事務結束,那麼第二個會話會結束等待.及時地結束事務是解決鎖等待情況發生的有效方法.

死鎖的發生和鎖等待不同,它是鎖等待的乙個特例,通常發生在兩個或者多個會話之間.假設乙個會話想要修改兩個資源物件,可以是表也可以是字段,修改這兩個資源的操作在乙個事務當中,當它修改第乙個物件時需要對其鎖定,然後等待第二個物件,這時如果另外乙個會話也需要修改這兩個資源物件,並且已經獲得對第二個物件的鎖定,那麼就會出現死鎖,因為當前會話鎖定了第乙個物件等待第二個物件,而另乙個會話鎖定了第二個物件等待第乙個物件.這樣,兩個會話都不能得到想要得到的物件,於是出現死鎖.

這裡例子就不在展示,大家可以自行試一試.實際開發中出現死鎖情況大致有以下幾種原因:

使用者沒有良好的程式設計習慣,偶爾會忘記提交事務,導致長時間占用資源.

操作的記錄過多,而且操作過程中沒有良好地對其分組.對於資料兩很大的操作,可以將其分成幾組提交事務,這樣可以避免長時間的占用資源.

邏輯錯誤,兩個會話都想得到已占有的資源.

深入理解資料庫鎖

深入理解資料庫併發控制原理

mysql深入理解資料庫索引結構

深入理解資料庫事務 W18

深入理解資料庫鎖

深入理解資料庫併發控制原理

mysql深入理解資料庫索引結構

深入理解資料庫事務 W18

相關推薦