案例再現：

　　一家企業已經部署了ERP系統，其后臺就用到了Oracle數據庫系統。不過這個ERP系統沒有人事管理系統模塊。企業后來為了加強人事管理，故又采用了一款人事管理的系統。由于ERP系統是開源的，故通過簡單的開發就可以跟人事管理系統進行集成。由于人事管理跟ERP系統的相關模塊基本上沒有很大的內在聯系，所以最后只有User表是與人事管理系統共用的，其他都是通過視圖的形式進行數據交流。但是當企業開始用這個系統的時候，就出現了問題。如采購員需要維護供應商聯系人(其需要用到User表)的時候，往往會發現數據庫會出現長時間的停頓現象。有時候甚至需要到第二天才能夠順利更改或者添加供應商聯系人。

　　數據庫管理員剛開始懷疑是否是服務器性能的問題。但是檢查了CPU以及內存的使用情況來看，問題不是發生在性能上面。再經過深入細致的調查，才發現是鎖沖突導致了User表反映的遲緩。這個人事管理系統本來就是人事管理人員在用，基本上就是一個單機版的系統。這個應用程序在設計的時候，可能出于數據庫兼容性的考慮，故在表級別上實現了鎖。也就是說，即使對User表其中的一條記錄進行修改，應用程序也會為整個User表進行加鎖。如此的話，當人事管理人員在更該員工信息的話，這個表其他用戶就不能夠更改，直到人事管理人員完成更改。而由于供應商聯系人信息其也是存儲在User表中，為此采購員就會感覺到User表會出現長時間的停頓顯現。

　　問題解析：

　　數據庫鎖主要是用來解決并發行訪問可能出現的問題。根據加鎖內容的不同，可以在不同的級別上實現鎖。如可以在整個表上實現加鎖;也可以對特定的行實現加鎖。有些應用軟件為了兼容于市場上每個基于SQL語句的數據庫，會例行公事地在表級別上而不是在航級別上鎖定資源。采用了不必要的高級別加鎖機制從而導致了不必要的鎖沖突。所以所在應用程序設計的時候需要注意因為鎖設置不當而給數據庫造成的負面影響。

　　那么應用程序的哪些不恰當設計會增加鎖沖突發生的機率呢?根據筆者的經驗，如果應用程序如下幾個方面設計不當的話，則會大大增加鎖沖突發生的機會。

　　1、事務運行時間過長導致鎖沖突。這是最容易發生的情況。如在ERP系統中，有一個批量結束采購訂單的作業。因為在采購訂單管理中，有時候會出現尾數的情況。如采購訂單明細中有一個產品，采購訂單上寫著是1998套，而中18套可是出于損耗率而考慮購買的。但是供應商由于生產線的限制，其可能只供應了1995套，即少供應商了3套。此時由于供應商交貨數量沒有達到采購數量，故此時系統中這張采購訂單或者采購訂單中的這個采購條目永遠不會結束。這會導致管理上很大的麻煩。如采購員可能需要定期導一份未結案采購明細表以追蹤物料。可此時哪些尾數問題，會導致導出來的報表中內容虛多。另外在根據采購單轉收貨單作業中，這些未結案的采購訂單也會老是在那個窗口中顯示，這給系統用戶選擇增添了一定的困難。故系統中設計了這個作業，用來幫助用戶批量的結束采購訂單。可是這個程序如果設計的不好的話，會造成比較大的麻煩。因為這個作業其需要更新好多張表，如采購明細表、采購訂單頭表等等。而且還會涉及到比較復雜的業務邏輯，如需要判斷采購行行中的所有采購條目是否都已經結束，只有在全部結束后程序才會更新采購訂單頭的結束碼字段，即這張采購訂單全部結束。如果所有明細沒有全部結束，還有部分產品沒有到料的話，那么只結束這個具體的條目，而采購訂單沒有結案。由于涉及到的表比較多、業務邏輯比較復雜，如果記錄再比較多的話，那么此時這個作業運行就會需要比較長的時間。而在執行這個作業的時候，系統會把這個作業所涉及表中的記錄鎖起來，不允許其他用戶進行更改。此時若其他用戶需要對他們更改的話(更改同一條記錄的其他字段)，就會造成鎖沖突。其他用戶必須等待這個作業完成之后才能夠更改相關的記錄。

　　所以說，應用程序設計時設計事務比較繁瑣，將使得鎖沖突的幾率大大提高。為此筆者建議各位應用程序開發人員，在設計事務時，最好能夠遵循簡短化的操作。如相關的業務邏輯、所涉及到的表等等，能夠簡單就簡單，能夠少就少。如果真的需要很多步驟才能夠完成一個事務的話，那就可以適當考慮把這個事務分成幾個獨立的事務來完成。另外在給企業用戶培訓的時候，最好能夠說明這個問題。建議企業員工在執行這些事務的時候，選擇一個合適的時間。如可以讓員工在下班后執行這個作業，以降低對其他用戶的影響。

　　2、由于所級別設置不當所造成的鎖沖突。在Oracle10G以后的版本中，一個事務能夠鎖定一行、多行或者整個表。雖然用戶也可以手工對行或者表進行加鎖，但是Oracle數據庫服務器能夠自動在盡可能低的級別上鎖定必要的行，以保證數據完整性，并最小化與其他可能需要訪問該表中其他行的事務之間的沖突。

如筆者一開始提到的案例，一些應用軟件為了提高其軟件的兼容性，提高其軟件支持的數據庫系統，就會例行公事的采取高級別的鎖機制。在本來只需對行進行加鎖的情況下，而對表進行了加鎖。這就會影響其他用戶對該表進行維護工作。為此筆者認為，應用程序在設計的時候，考慮了軟件與數據庫系統的兼容性，那本來是件好事情。但是在設計的時候能否再到位一點的。如可以根據數據庫接口的不同，來考慮到底是采取行級別鎖呢還是采取表級別鎖。而不能夠一刀切，不分青紅皂白一律采用表鎖。這會大大降低應用程序的性能，是一個不合理的設計方法。也即是說，應用程序應該可以根據所采用數據庫的不同(甚至版本的不同)來判斷這些數據庫是否支持行鎖。如果支持行鎖的話，則就只需要對行加鎖即可。其實要實現這個也不是很難，只需要在應用程序初始化的時候進行設置即可。先進一點的直接可以從數據庫接口中獲得數據庫的品牌與版本信息，并進行相應的調整。遲鈍一點的需要系統管理員在初始化參數中手工指定所采用的數據庫品牌與版本。即使采取后面這種笨辦法也要比采用一刀切的表級別鎖方式好得多。

　　3、沒有嚴格限制用戶從數據庫表中更新數據。

　　有些軟件在設計時，允許用戶可以直接在數據庫中修改相關的數據。這或許能夠給企業帶來一定的便利性，但是也會造成比較到的隱患。如某個系統管理員可能從數據庫表中更新了相關的數據。但是他在更新完成后，可能是出于疏忽的原因，沒有立即執行commit語句。此時利用當前會話進行查詢的話，會發現數據已經被更改。而利用另外一個會話查詢的時候，其查詢到的仍然是更改前的數據。也就是說，此時系統管理員更改的數據還沒有提交到數據庫表中。此時對于所涉及到的行就會進行加鎖。而且有時候出于性能等方面的考慮，數據庫甚至會對整張表進行加鎖。由于用戶忘了執行commit指令，這個鎖就會一直在那邊。那么其他用戶就不能夠對這些記錄進行任何的更改作業。#p#分頁標題#e#

　　類似的情況筆者遇到的還是比較多的。因為有些系統管理員沒有受到過專業的數據庫培訓，是半路出家的。為此他們對于這個鎖的機制與Commit命令的功用沒有直觀的印象。所以他們從數據庫中更新數據后，往往會忘記執行Commit命令。所以筆者認為如果把數據庫開發給企業的話，可能對數據庫的性能會產生比較大的影響，因為用戶很容易忘記執行commit指令。而如果企業用戶的更新動作都通過前臺應用程序來完成，那么很少會發生這種情況了。在應用程序設計的時候，肯定會在SQL語句的最后加上一個Commit指令。這就可以防止因為沒有恰當執行commit指令而導致的鎖沖突事件的發生。

　　筆者認為由于應用程序開發與數據庫設計是處于兩個不同的領域。故數據庫管理員需要跟應用程序開發者進行有效溝通。只有在雙方共同努力下，才能夠在最大限度內避免這種情況的發生。