DB2鎖兼容性是怎樣的？死鎖又是怎麼回事？下文對這些問題都作了詳細的解答，如果您在此方面遇到過類似的問題，不妨一看。
鎖兼容性
如果數據資源上的一種鎖狀態允許在同一資源上放置另一個鎖，就認為這兩種鎖（或兩種狀態）是兼容的。每當一個事務持有數據資源上的鎖，而第二個事務請求同一資源上的鎖時，DB2 數據庫管理器檢查兩種鎖狀態以確定它們是否兼容。如果鎖是兼容的，則將鎖授予第二個事務（假定沒有其它事務在等待該數據資源）。但是，如果鎖不兼容，則第二個事務必須等待，直到第一個事務釋放它的鎖為止，然後才可以獲取對資源的訪問權並繼續處理。（如果資源上有多個與新請求的鎖不兼容的鎖，則第二個事務必須等到它們全部被釋放為止。）請參閱 IBM DB2 Universal Database Administration Guide：Performance 文檔（或在 DB2 信息中心搜索 Lock type compatibility 主題）以獲取關於各個鎖之間是否兼容的特定信息。
鎖升級
所有的鎖都需要存儲空間；因為可用空間並不是無限的，所以 DB2 數據庫管理器必須限制鎖可以使用的空間（這是通過 maxlocks 數據庫配置參數完成的）。為了防止特定數據庫代理超過已建立的鎖空間限制，當獲取的（任意類型的）鎖過多時，會自動執行稱為鎖升級的進程。鎖升級是一種轉換，它將同一表內幾個單獨的行級鎖轉換成一個單獨的表級鎖。因為鎖定升級是在內部處理的，所以唯一可從外部檢測到的結果可能只是對一個和多個表的並發訪問減少了。
以下是鎖定升級的工作原理：當事務請求鎖，而鎖存儲空間已滿時，就選定與該事務相關聯的一個表，幫它獲取一個表級鎖，釋放所有該表的行級鎖（以在鎖列表數據結構中創建空間），並將表級鎖添加到鎖列表。如果這個過程所釋放的空間不夠，則選定另一個表，重復這個過程，直到釋放了足夠的可用空間為止。這時，事務將獲取所請求的鎖並繼續執行。但是，如果在該事務的所有行級鎖都已經升級之後，仍然沒有獲得必要的可用鎖空間，則（通過 SQL 錯誤代碼）要求事務提交或回滾它啟動以來所作的所有更改，然後事務終止。
死鎖
有時兩個或更多個事務對鎖的爭用會引起稱為死鎖的情況。說明死鎖發生原因的最佳方式是舉例說明：假定事務 1 在表 A 上獲取了互斥（X）鎖，而事務 2 在表 B 上獲取了互斥（X）鎖。現在，假定事務 1 嘗試在表 B 上獲取互斥（X）鎖，而事務 2 嘗試在表 A 上獲取互斥（X）鎖。這兩個事務的處理都將被掛起，直到同意第二個鎖請求為止。但是，因為在任何一個事務釋放它目前持有的鎖（通過執行或回滾操作）之前，（兩者中的）任一事務的鎖請求都不會被同意，而且又因為兩個事務都不能釋放它目前持有的鎖（因為它們都已掛起並等待鎖），所以兩個事務都陷入了死鎖狀況。
當死鎖狀況發生時，除非某些外部代理采取行動，否則所涉及的所有事務將無限期地等待釋放鎖。DB2 通用數據庫用於處理死鎖的工具是稱為死鎖檢測器的異步系統後台進程。死鎖檢測器的唯一職責是定位和解決在鎖定子系統中找到的任何死鎖。死鎖檢測器在大多數時間處於休眠狀態，但會在預置的時間間隔被“喚醒”，以確定是否存在死鎖狀況。如果死鎖檢測器在鎖定子系統中發現死鎖，則選擇死鎖涉及的一個事務、終止並回滾它。（被終止和回滾的事務收到一個 SQL 錯誤代碼，它所獲得的所有鎖都被釋放。）通常，剩下的一個或多個事務就可以繼續執行了。
鎖超時
任何時候當一個事務在特定數據資源（例如，表或行）上持有鎖時，直到持有鎖的事務終止並釋放它所獲取的所有鎖之前，其它事務對該資源的訪問都可能被拒絕。如果沒有某種適當的鎖超時檢測機制，則事務可能無限期地等待鎖的釋放。例如，有可能出現這種情況：一個事務在等待另一個用戶的應用程序所持有的鎖被釋放，而該用戶離開了他（或她）的工作站，但忘了執行一些允許應用程序終止擁有鎖的事務的交互。顯然，此類情況會導致極差的應用程序性能。要避免發生此類情況時阻礙其它應用程序的執行，可以在數據庫的配置文件中指定鎖超時值（通過 locktimeout數據庫配置參數）。使用之後，該參數就控制任何事務將等待獲取所請求的鎖的時間。如果在指定的時間間隔過去之後還未獲得想要的鎖，則等待的應用程序接收一個錯誤，並回滾請求該鎖的事務。分布式事務應用程序環境特別容易產生此類超時；可以通過使用鎖超時避免它們。
