|
死鎖的發(fā)生對系統(tǒng)的性能和吞吐量都有重要影響，經(jīng)檢測發(fā)現(xiàn)，管理信息系統(tǒng)的死鎖主要是因為兩個或多個線程(登錄)搶占同一表數(shù)據(jù)資源。引起長時間搶占同一資源不是因為我們需要處理的事務太復雜，時間太長，而往往是因為我們在前端應用程序對數(shù)據(jù)庫作操作時忘了提交。本文介紹一種處理解決這種死鎖的方法。
Sybase封鎖原理 數(shù)據(jù)共享與數(shù)據(jù)一致性是一對不可調和的矛盾，為了達到數(shù)據(jù)共享與數(shù)據(jù)一致，必須進行并發(fā)控制。并發(fā)控制的任務就是為了避免共享沖突而引起的數(shù)據(jù)不一致。Sybase SQL Server并發(fā)控制的方法是加鎖機制(LOCKING). 鎖的類型 可申請的鎖 已有的鎖 S U X S ∨ ∨ × U ∨ × × X × × × Sybase SQL Server有三種封鎖類型：排它鎖(exclusive lock,簡稱X鎖); 共享鎖(share lock,簡稱S鎖); 更新鎖(update lock,簡稱U鎖)。這三種鎖的相容矩陣表如下： ×:表示不兼容?！牛罕硎炯嫒?。 Sybase SQL Server是自動決定加鎖類型的。一般來說，讀(SELECT)操作使用S鎖，寫(UPDATE,INSERT和delete)操作使用X鎖。U鎖是建立在頁級上的，它在一個更新操作開始時獲得，當要修改這些頁時，U鎖會升級為X鎖。 鎖的力度 SQL Server有兩級鎖：頁鎖和表鎖。通常頁鎖比表鎖的限制更少(或更小)。頁鎖對本頁的所有行進行鎖定，而表鎖則鎖定整個表。為了減小用戶間的數(shù)據(jù)爭用和改進并發(fā)性，SQL Server試圖盡可能地使用頁鎖。 當SQL Server決定一個語句將訪問整個表或表的大多數(shù)頁時，它用表鎖來提供更有效的鎖定。鎖定策略直接受查詢方案約束，如果update或delete語句沒有可用的索引，它就執(zhí)行表掃描或請求一個表鎖定。如果update或delete語句使用了索引，它就通過請求頁鎖來開始，如果影響到大多數(shù)行，它就要請求表鎖。一旦一個語句積累的頁鎖超過鎖提升閾值，SQL Server就設法給該對象分配一個表鎖。如果成功了，頁鎖就不再必要了，因此被釋放。表鎖也在頁層提供避免鎖沖突的方法。對于有些命令SQL Server自動使用表鎖。 鎖的狀態(tài) SQL SERVER加鎖有三種狀態(tài)： 1)意向鎖(intend)—是一種表級鎖，它表示在一個數(shù)據(jù)頁上獲得一個S或X鎖的意向。意向鎖可以防止其他事務在該數(shù)據(jù)頁的表上獲得排它鎖。 2)阻塞(blocking,簡記blk)—它表明目前加鎖進程的狀態(tài)，帶有blk后綴的鎖說明該進程目前正阻塞另一個需要獲得鎖的進程，只有這一進程完成，其他進程才可以進行。 3)需求鎖(demand)—表示此時該進程企圖得到一個排它鎖。它可以防止在這一表或頁上加過多的S鎖，她表示某一事務是下一個去鎖定該表和該頁的事務。 需求鎖是一個內(nèi)部過程，因此用sp_lock是無法看見的。 死鎖DEADLOCK 簡單地說，有兩個用戶進程，每個進程都在一個單獨的頁或表上有一個鎖，而且每個進程都想在對方進程的頁或表上請求不相容鎖時就會發(fā)生“死鎖”。在這種情況下，第一個進程在等待另一進程釋放鎖，但另一進程要等到第一個進程的對象釋放時才會釋放自己的鎖。 SQL Server檢查是否死鎖，并終止事務中CPU時間積累最小的用戶(即最后進入的用戶)。SQL Server回滾該用戶的事務，并用消息號1205通知有此死鎖行為的應用程序，然后允許其他用戶進程繼續(xù)進行。 在多用戶情形下，每個用戶的應用程序都應檢查每個修改數(shù)據(jù)的事務是否有1205號消息，以此確定是否有可能死鎖。消息號1025表示該用戶的事務因死鎖而終止并被回滾。應用程序必須重新開始這個事務處理。 查找死鎖原因 既然管理信息系統(tǒng)長時間死鎖的原因是由于我們提交或者是提交不當，那么我們就可以通過修改程序防止出現(xiàn)死鎖。定位死鎖出錯處主要經(jīng)過以下三步： 1)在死鎖出現(xiàn)時，用SP_WHO,SP_LOCK獲得進程與鎖的活動情況。 2)結合庫表sysobjects和相應的操作員信息表查出被鎖的庫表與鎖住別人的操作員。 3)根據(jù)鎖定的庫表與操作員的崗位，可以估計出程序大約出錯處。詢問操作員在死鎖時執(zhí)行的具體操作即可完全定位出錯處。最后查找程序并修改之。 用sp_who獲取關于被阻礙進程的信息 系統(tǒng)過程sp_who給出系統(tǒng)進程的報告。如果用戶的命令正被另一進程保持的鎖阻礙，則： ◆status列顯示“l(fā)ock sleep”。 ◆blk列顯示保持該鎖或這些鎖的進程標識，即被誰鎖定了。 ◆loginame列顯示登錄操作員。結合相應的操作員信息表，便可知道操作員是誰。 Fid spid status loginame origname blk dbname cmd 0 1 lock sleep lm lm 18 QJYD SELECT 0 2 sleeping NULL NULL 0 master NETWORK HANDLER 0 3 sleeping NULL NULL 0 master NETWORK HANDLER …… 用sp_lock瀏覽鎖 要得到關于當前SQL Server上保持的鎖的報告，可用系統(tǒng)過程sp_lock [spid1[,spid2]]，spid1,spid2是表master.dbo.sysprocesses中的sql server進程id號，用sp_who可以得到鎖定與被鎖定的spid號： ◆locktype列顯示加鎖的類型和封鎖的粒度，有些鎖的后綴還帶有blk表明鎖的狀態(tài)。前綴表明鎖的類型：Sh—共享鎖，Ex—排它鎖或更新鎖，中間表明鎖死在表上(”table”或’intent’)還是在頁上(page). 后綴“blk”表明該進程正在障礙另一個需要請求鎖的進程。一旦正在障礙的進程一結束，其他進程就向前移動?！癲emand”后綴表明當前共享鎖一釋放， 該進程就申請互斥鎖。 ◆table_id列顯示表的id號，結合sysobjects即可查出被封鎖的表名。 執(zhí)行該進程后屏幕顯示 Fid Spid locktype table_id page row dbname Class context 0 1 Sh_intent 678293476 0 0 QJYD Non Cursor LockFam dur 0 1 Sh_page 678293476 31764 0 QJYD Non Cursor Lock 0 18 Ex_intent 9767092 0 0 QJYD Non Cursor LockFam dur …… 定位出錯處 根據(jù)sp_who與sp_lock命令的結果，結合sysobjects和相應的操作員信息表。得到操作員及其在死鎖時所操作的庫表，便大約可以知道應用程序的出錯處，再詢問操作員在死鎖時執(zhí)行什么操作以進一步認證。最后查找程序并修正之。  【責任編輯 陳東方】 |
|
|
來自： icecity1306 > 《數(shù)據(jù)庫資料》
