王德山

[摘要]不同的數(shù)據(jù)庫管理系統(tǒng)提供的封鎖類型、封鎖協(xié)議、達到的系統(tǒng)一致性級別不盡相同，但其依據(jù)的基本原理和技術是共同的。通過對melinets圖書管理系統(tǒng)死鎖問題的研究，分析了SYBASE數(shù)據(jù)庫鎖的機制，提出了預防死鎖的幾種措施，并給出了解除死鎖的相關方法。

[關鍵詞]melinets sybase 死鎖

中圖分類號：TP3文獻標識碼：A文章編號：1671－7597（2009）0420041－02

Melinets是北京郵電大學開發(fā)的一種集采訪、編目、流通、期刊等子系統(tǒng)在內(nèi)的圖書館自動化管理系統(tǒng)，其后臺采用SYBASE數(shù)據(jù)庫。它通過鎖的方式保護被活動的事務正在使用的表、數(shù)據(jù)頁或者數(shù)據(jù)行。加鎖是實現(xiàn)數(shù)據(jù)庫并發(fā)控制的一個非常重要的技術。當事務在對某個數(shù)據(jù)對象進行操作前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務就對該數(shù)據(jù)對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數(shù)據(jù)對象進行更新操作。確切的控制由鎖的類型來決定。原鄭州經(jīng)濟管理干部學院（現(xiàn)河南工程學院）于2003年至2008年10月一直使用該圖書管理系統(tǒng)，在對圖書進行數(shù)據(jù)加工，書目數(shù)據(jù)發(fā)送等過程中，經(jīng)常出現(xiàn)進程阻塞甚至死鎖的現(xiàn)象。本文從SYBASE數(shù)據(jù)庫死鎖的原理出發(fā)，結合melinets死鎖發(fā)生的具體情況，提出了在應用melinets過程中預防和處理死鎖的相關措施。

一、Sybase鎖的類型及作用

（一）共享鎖（Share Lock）

共享（S）鎖允許并發(fā)事務讀?。⊿elect）一個資源。資源上存在共享鎖時，任何其他事務都不能修改數(shù)據(jù)。Sybase對讀操作加Share鎖。如果一個S鎖已經(jīng)加在一個表、數(shù)據(jù)頁、數(shù)據(jù)行或索引頁上，即使加鎖的事務是活動的，其他事務仍然可以獲得S鎖。但在表或數(shù)據(jù)頁或數(shù)據(jù)行上的所有S鎖被釋放前，其他事務都不能獲得該表或頁面或行的exclusive鎖。這就意味著多個事務可以同時讀表、頁面或行，但沒有事務能對已經(jīng)加S鎖的表、頁面或行中的數(shù)據(jù)進行修改，而必須等待S鎖釋放后才能繼續(xù)。

（二）排他鎖（Exclusive Lock）

排他（X）鎖是為修改數(shù)據(jù)而保留的，可以防止并發(fā)事務對資源進行訪問。排他鎖與其他鎖不兼容。Sybase對數(shù)據(jù)更改操作加Exclusive鎖。如果一個事務獲得了一個Exclusive鎖，那么在這個事物結束時釋放Exclusive鎖之前，其他事務在相應的表或頁面或行上不能獲得任何類型的鎖。其他事務必須等到Exclusive鎖釋放后才能繼續(xù)。

（三）更新鎖（Update Lock）

一般更新模式由一個事務組成，此事務讀取記錄，獲取資源（頁或行）的共享鎖，然后修改行，此操作要求鎖轉換為排他鎖。如果兩個事務獲得了資源上的共享模式鎖，并試圖同時更新數(shù)據(jù)，則其中一個事務會嘗試將鎖轉換為排他鎖。因為一個事務的排他鎖與其他事務的共享模式鎖不兼容，所以從共享模式到排他鎖的轉換必須等待一段時間。而此時，第2個事務也試圖獲取排他鎖以進行更新，于是就出現(xiàn)同時持有共享模式鎖的兩個事務彼此等待對方釋放共享模式鎖的情形，從而發(fā)生死鎖。要避免這種潛在的死鎖問題，就要使用更新鎖．一次只有一個事務可以獲得資源的更新鎖。如果事務修改資源，則更新鎖轉換為排他鎖，否則轉換為共享鎖。Sybase在Update，Delete或Fetch的初始階段加Update鎖。如果頁面或者行的內(nèi)容需要修改，只要沒有其他Share鎖在上面，Update鎖立即升級為Exclusive鎖。

（四）意向鎖（Intent Lock）

意向（I）鎖指出在一個表上有頁級或行級鎖。Sybase對每一個有Share或Exclusive的頁或行鎖的表加意向鎖。所以意向鎖可以是Exclusive

鎖，也可以是Share鎖。設置意向鎖可以防止其他后來的事務在有鎖住的頁的表上獲得沖突的表級鎖。意向鎖持續(xù)的時間和事務中頁或行鎖的時間一樣長。

二、melinets死鎖的產(chǎn)生與預防

一般來說，如果事務T1封鎖了數(shù)據(jù)R1，T2封鎖了R2，然后TI又請求封鎖R2，因為R2已經(jīng)被T2封鎖，于是TI等待T2釋放R2，上的鎖。接著T2又申請封鎖R1，因為TI已經(jīng)封鎖了R1，于是T2也只能等待T1釋放R1上的鎖。這樣一來，就出現(xiàn)了T1封鎖R1同時等待R2，T2封鎖R2同時等待R1。于是T1，T2兩個事務永遠不能完成，就形成死鎖。

例如在應用melinets集中進行數(shù)據(jù)批量發(fā)送過程中，經(jīng)常容易引起死鎖。melinets數(shù)據(jù)發(fā)送過程實際就是將已編目好的書目表數(shù)據(jù)向流通典藏表更新的過程，批量發(fā)送就相當于批量更新。尤其是在同一時間段進行批量發(fā)送的用戶越多，這時就更容易造成用戶之間對表鎖和數(shù)據(jù)頁鎖的爭用，從而加大了死鎖的發(fā)生。

死鎖的頻繁發(fā)生將極大影響工作的效率，甚至可能對系統(tǒng)造成無法挽回的損失，因此我們應盡量預防發(fā)生死鎖。防止死鎖的發(fā)生其實就是破壞死鎖的條件。理論上預防死鎖有兩種方法：

1．一次封鎖法。一次封鎖法，要求每個事務必須一次將所有要使用的數(shù)據(jù)全部加鎖，否則就不能繼續(xù)執(zhí)行。顯然一次封鎖法可以有效的防止死鎖的發(fā)生，但由于一次將以后要用到的全部數(shù)據(jù)加鎖，擴大的封鎖的范圍，也就降低了系統(tǒng)的并發(fā)度。

2．順序封鎖法。順序封鎖法是預先對數(shù)據(jù)對象規(guī)定一個封鎖順序，所有事務都按這個順序?qū)嵭蟹怄i。順序封鎖法也可以有效的防止死鎖，但它同樣存在問題。由于數(shù)據(jù)庫中封鎖的對象多，而且事務的封鎖請求可以隨著事務的執(zhí)行而動態(tài)的決定，因此要維持這樣的封鎖順序不但成本很高，而且很難實現(xiàn)。

針對melinets實際應用過程中，我們可以通過合理調(diào)度不同任務的執(zhí)行順序和時間，避免資源過多占用，這樣也可以有效的預防死鎖的發(fā)生。例如：在進行批量發(fā)送時，分批次分時間段進行。同時利用系統(tǒng)過程對數(shù)據(jù)庫相關參數(shù)進行合理設置：

（1）帶有加鎖方式的讀提交設置，通過改變釋放共享鎖的時間點來減少死鎖的發(fā)生，命令如下：

Sp_config 'read committed with lock'，0|1

（2）在考慮掃描一張表之前，需要確定在一張表中能有多少頁，采用如下命令在頁級結構中加以配置：

Sp_chgattribute，”concurrency_opt_threshold”，

（3）適當設置臨時表空間大小，避免臨時表空間被占滿而發(fā)生阻塞。

另外，數(shù)據(jù)庫死鎖還與系統(tǒng)綜合性能有關。如系統(tǒng)I/O通常是影響系統(tǒng)性能的瓶頸。如果能提高I/O性能，事務執(zhí)行時間相對縮短，從而鎖爭用和死鎖的可能性就隨之減少。

三、死鎖的解除

在事務和鎖的使用過程中，死鎖是一個不可避免的現(xiàn)象。當死鎖發(fā)生時，我們應盡快查找死鎖的原因并解除死鎖。通常，當系統(tǒng)檢測到死鎖發(fā)生時，采用的方法是：選擇一個處理死鎖代價最小的事務，將其撤消，釋放此事務持有的所有的鎖，使其他事務得以繼續(xù)下去。當然對撤消的事務所執(zhí)行的數(shù)據(jù)修改操作必須加以恢復。針對melinets圖書管理系統(tǒng)具體方法如下：

1．死鎖發(fā)生時用系統(tǒng)進程SP_WHO查看系統(tǒng)進程信息。

SP_WHO返回結果如圖（1），結果解釋如下：

Fid進程所屬的組

Spid 進程號

Status進程狀態(tài)

Loginname啟動進程的用戶登錄名

Blk阻塞進程的ID

Dbname該進程訪問的數(shù)據(jù)庫

Cmd 該進程執(zhí)行的命令和進程

如果用戶進程正被另一用戶進程阻塞，則status列顯示“l(fā)ock sleep”，而blk列顯示保持該鎖或這些鎖的進程標識，即被誰鎖定。Loginname列顯示登錄操作員。這樣結合相應的操作員信息表，便可知道操作員是誰。

2．用SP_LOCK獲得當前狀態(tài)中鎖的分配和使用情況。

通過SP_LOCK命令可以查看系統(tǒng)被鎖數(shù)據(jù)表的情況，包括數(shù)據(jù)表的ID號。被鎖的類型（前綴sh為共享鎖，ex為排它鎖，后綴blk表明該進程正在阻礙另一個需要請求鎖的進程）以及數(shù)據(jù)庫名稱dbname。

3．結合二者結果與庫表SYSOBJECTS查出被鎖定的庫表以及鎖住別人的操作員。

4．詢問相關操作員并撤消相關事務，從而達到解除死鎖的目的。

當然，當死鎖發(fā)生時，重新啟動melinets數(shù)據(jù)庫服務器也可以達到解除死鎖的目的，但這是個笨方法，因為這樣既無法保證數(shù)據(jù)的完整性，也耗費資源。因此作為數(shù)據(jù)庫DBA而言不到萬不得以不應該采用重啟的方式。

四、結語

死鎖是任何數(shù)據(jù)庫系統(tǒng)都無法避免的一種現(xiàn)象，頻繁的死鎖將為我們的工作帶來很大的不便，甚至是無法估計的損失。因此我們應該盡量減少死鎖的發(fā)生。而一旦死鎖發(fā)生時，應該積極采取有效的應對措施來解決死鎖。melinets作為一款現(xiàn)代信息集成圖書管理系統(tǒng)，在使用過程中或多或少由于SYBASE數(shù)據(jù)庫的特性，或者一些其他的人為因素也可能會發(fā)生死鎖，但只要我們了解死鎖的原理，再根據(jù)實際情況，通過合理的調(diào)度，就可以盡量減少由于死鎖而為我們帶來的麻煩。

參考文獻：

[1]薩師宣、王珊，數(shù)據(jù)庫系統(tǒng)概論[M].第三版，高等教育出版社，2004.

[2]SYBASE，數(shù)據(jù)庫維護參考手冊，Version2.0.

[3]連宇江、唐穎，Melinets圖書管理系統(tǒng)的管理和維護點淺談[J].科技文獻信息管理，2005.1.