我公司僱用的DBA解決死鎖問題剛剛告訴我，如果我們將事務級別設置爲READ COMMITTED從READ UNCOMMITTED，那麼我們的OLTP數據庫鎖定問題將得到改善。Sql 2005鎖定OLTP - 已提交還是未提交？
這不僅僅是100％錯誤嗎？ READ COMMITTED會導致更多鎖定，對嗎？
更多詳細信息：
我們的數據很 「孤立」 和特定的用戶。 99.9999999％的所有用戶交互與您自己的數據一起工作，如果發生這些情況，我們的骯髒閱讀方案几乎不能影響用戶正在嘗試做什麼。
感謝所有的答案，dba問題最終變得毫無用處，我們通過添加單個索引來解決鎖定問題。
我很遺憾，我沒有指定更新語句發生鎖定問題而不是常規選擇。從我的角度來看，兩種不同的查詢類型在處理鎖定問題時有不同的解決方案。
這聽起來像是一個輕率的決定，但沒有你的環境的所有細節都很難說。
您應該建議您的DBA考慮使用SQL Server的高級隔離功能，即使用行版本控制技術。這被引入到SQL Server 2005中，專門解決遇到高鎖定問題的OLTP數據庫問題。
以下白皮書包含相當複雜的主題，但它是所有異常DBA的必讀內容。它包括例如如何使用每個附加隔離級別的，在不同類型的環境即OLTP，卸載了報告環境等的
http://msdn.microsoft.com/en-us/library/ms345124.aspx
總之這將是既愚蠢和皮疹修改事務隔離對於所有的T-SQL查詢，無需先了解如何在您的環境中發生過度鎖定。
我希望這可以幫助，但請讓我知道，如果您需要進一步澄清。
乾杯！
難道這不取決於你的問題是什麼：例如，如果你的問題是死鎖，鎖定級別的增加可能不會導致早期獲取鎖，從而降低致命擁抱的可能性？
這聽起來很可怕。你真的想改變這些參數來避免死鎖嗎？也許數據需要被鎖定？
也就是說，可能是DBA引用了新的SQL Server 2005（採用SQL Server 2005）READ COMMITTED SNAPSHOT，它使用行版本控制並可以消除某些類型的死鎖。
它的數據是孤立的，你仍然得到死鎖，那麼你可能只需要ROWLOCK提示添加到正在導致問題，這樣的鎖行級拍攝，而不是查詢頁面級別（這是默認值）。
如果由於SELECT語句而鎖定數據，則READ UNCOMMITTED將減少鎖的數量。如果由於INSERT，UPDATE和DELETE語句而鎖定數據，那麼將隔離級別更改爲READ UNCOMMITTED將不會爲您執行任何操作。 READ UNCOMMITTED與向查詢添加WITH（NOLOCK）具有相同的效果。
+1用於根據正在執行的活動類型來限定分辨率的不同選項。 – 2009-06-14 16:06:59
「傻瓜和皮疹來修改交易隔離..」 你說的比我更好。 （+1） – RussellH 2009-02-02 19:08:33