DB Locks - 如何處理長事務並保持高並發？
我們正在維護一個內置於 powerbuilder 中的 POS/WMS 應用程序，該應用程序在 SQL Server 2008 R2 後端上執行。最近，我們遇到了很多鎖定問題，我相信這與我們處理事務的方式有關。我們正在考慮在我們的數據庫上啟用已送出讀快照，但根據這個答案，它似乎並不能真正解決任何問題，而且以後容易引入更多問題。
從訂購產品到發貨的整個過程非常複雜（該應用程序已經使用了 19 年，並且一直被眾多開發人員持續維護）。這是一個從 excel 文件上傳的批量訂購過程如何鎖定我們的數據庫的虛擬碼：
Load all items from excel files Begin Transaction Loop per item Perform all validation checks, such as checking current stocks, authorization to order etc (There's a lot of complex checks going on here) Insert new item to order table If an error occurs during insert, rollback and return End Loop Commit Transaction由於我們的訂單表在一個事務中，這意味著其他使用者必須等到整個工作完成才能對其執行任何操作。這尤其給倉庫員工帶來了很多問題，他們必須等待很長時間才能在我們的訂單表上將商品標記為已發貨，然後才能實際發貨。
有人可能會說“交易應該盡可能地短”，但問題是，如果在這個訂單過程中發生任何錯誤，整個作業應該回滾到初始狀態。這是程序要求的一部分。
我不是數據庫專家，所以我可能在這裡遺漏了一些關鍵的東西，但鑑於我們的要求，似乎唯一的選擇是對我們的事務啟用行版本控制。
我真的很想知道如何解決這類問題。
首先，應先驗證批次訂單，然後再送出。正如您所說，將插入送出到數據庫中的事務應該盡可能短。在完美的世界中，這意味著您在開始事務和送出之前預先進行所有驗證。
從你所說的來看，我懷疑這樣的重組是否可行，所以我建議調查一下為什麼交易會鎖定整個表。理想情況下，這樣的插入將只有行級鎖。
根據數據的結構，可能會在每一行之後打開事務並送出。
最後，也許可以批量處理數據並將其全部發送到數據庫進行處理。
所有這些選項都需要進行大量的更改。
編輯：
鑑於您的評論，您似乎需要在單個事務中進行此批處理。這將表明鎖定是正確的。下一步是了解是什麼導致批處理需要這麼長時間。如果批處理需要相當長的時間，則讀取用於驗證的數據的查詢或驗證所需數據的儲存方式存在問題。
您將需要開始查看作為驗證的一部分執行的每個查詢，以了解耗時最長的查詢，然後優化該查詢等等，直到整個過程更加簡化。