讓我們分別來看看每個情況以便找到我們如何解決這個問題。也讓我們平衡SQL Server由於某種原因都有一個鎖管理的事實。這是為了在一個高度一致的數據庫環境中確保數據完整性。所以更改SQL Server的默認行為並不是一種好的做法，在做任何改動之前應該完全明白這一點。
報告所定
對於報告的情況，看看下面的選項是否是可能的。
l 對於特殊的和重復的報告，是否有可能在另外一個SQL Server例如一個報告服務器上執行這些報告呢?數據可以用很多種不同的方式復制(事務復制，日志傳送，第三方復制等)，但是數據可能會稍微過期。盡管如此，它可能會阻止報告與聯機事務處理應用程序競爭。
l 對於重復的報告，看看報告數據是否可以每分鐘或者每5分鐘預先匯總。數據再一次會輕微過期，但是可以計算值一次然後重復讀取而不用每次執行查詢時都導致基本表上的鎖定問題發生。當執行計算時，鎖定只在一分鐘或者每五分鐘發生一次。
l 如果這些選項都是不可能的，那麼考慮下面的：
如果讀取你應用程序中的髒數據沒有問題並且報告應用程序支持會話級別參數，那麼考慮從報告應用程序中使用更改每個會話的隔離級別。最有可能的情況是：它們遵循READ COMMITTED的SQL Server(2000和2005) 默認的隔離級別。READ COMMITTED隔離級別不允許讀取髒數據也避免非重復的讀取。同樣地，適合於你環境的隔離級別可能是READ UNCOMMITTED，因為沒有一個共享鎖是執行的，也沒有一個獨占鎖是光榮的。就在哪裡和如何更改你應用程序中的隔離級別而言，參考你報告工具中的文檔。
這是包含在你的報告應用程序中的SQL Server會話開始處的示例代碼：
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
聯機事務處理鎖定
在聯機事務處理應用程序鎖定視圖的情況下，使用某個非默認隔離級別可能是不理智的，因為你不想降低一致性，也不想從整個會話中讀取髒數據。在這種情況下，你可能只想把 NOLOCK提示增加到你的SELECT語句中僅用於代碼集。記住有了NOLOCK提示，沒有一個共享鎖會執行也沒有獨占鎖會很榮幸。
