私の会社がデッドロックの問題をトラブルシューティングするために雇ったDBAは、トランザクションレベルをREADUNCOMMITTEDからREADCOMMITTEDに設定すると、OLTPデータベースのロックの問題が改善されると言っていました。
それは100％間違っているのではありませんか？READ COMMITTEDは、より多くのロックを引き起こしますよね？
詳細：
私たちのデータは非常に「サイロ化」されており、ユーザー固有です。すべてのユーザーインタラクションの99.9999999％は独自のデータで機能し、ダーティリードシナリオが発生した場合、ユーザーが実行しようとしていることにほとんど影響を与えません。
すべての回答に感謝し、問題のdbaは役に立たなくなったため、単一のインデックスを追加することでロックの問題を修正しました。
通常の選択ではなく、更新ステートメントでロックの問題が発生していることを指定しなかったことを残念に思います。私のグーグルから、2つの異なるクエリタイプには、ロックの問題に対処する際の明確な解決策があります。
それは少し性急な決定のように聞こえますが、環境のすべての詳細がなければ、それを言うのは困難です.
SQL Server の高度な分離機能の使用、つまり行のバージョン管理手法の使用を検討するよう DBA にアドバイスする必要があります。これは、高いロックが発生する OLTP データベースの問題に具体的に対処するために、SQL Server 2005 に導入されました。
次のホワイト ペーパーには、非常に複雑な内容が含まれていますが、優れた DBA は必ず読む必要があります。これには、OLTP、オフロード レポート環境などのさまざまなタイプの環境で、追加の各分離レベルを使用する方法の例が含まれています。
http://msdn.microsoft.com/en-us/library/ms345124.aspx
要約すると、環境内で過剰なロックがどのように発生しているかをしっかりと理解する前に、すべての T-SQL クエリのトランザクション分離を変更するのは愚かで無謀です。
これがお役に立てば幸いですが、さらに説明が必要な場合はお知らせください。
乾杯！
データがサイロ化されていて、まだデッドロックが発生している場合は、問題の原因となっているクエリに行ロックヒントを追加するだけで、ページレベル（デフォルト）ではなく行レベルでロックが取得されるようになります。
SELECTステートメントが原因でデータをロックしている場合、READUNCOMMITTEDはロックの数を減らします。INSERT、UPDATE、およびDELETEステートメントが原因でデータをロックしている場合は、分離レベルをREADUNCOMMITTEDに変更しても何も起こりません。READ UNCOMMITTEDは、クエリにWITH（NOLOCK）を追加するのと同じ効果があります。
問題が何であるかに依存しませんか? たとえば、問題がデッドロックである場合、ロック レベルを上げると、ロックの取得が早くなり、致命的な抱擁の可能性が減少するのではないでしょうか?
これは怖いですね。デッドロックを回避するためにこれらのパラメータを変更しますか? おそらくデータをロックする必要がありますか？
そうは言っても、DBA は、行のバージョン管理を使用し、ある種のデッドロックを排除できる新しい (SQL Server 2005 の) READ COMMITTED SNAPSHOT を参照している可能性があります。