SQLServer2005でのデッドロックの診断

MSDNによると：

http://msdn.microsoft.com/en-us/library/ms191242.aspx

READCOMMITTEDSNAPSHOTまたはALLOWSNAPSHOTISOLATIONデータベースオプションのいずれかがオンの場合、データベースで実行されるすべてのデータ変更に対して論理コピー（バージョン）が維持されます。特定のトランザクションによって行が変更されるたびに、データベースエンジンのインスタンスは、以前にコミットされた行のイメージのバージョンをtempdbに格納します。各バージョンには、変更を加えたトランザクションのトランザクションシーケンス番号が付けられています。変更された行のバージョンは、リンクリストを使用してチェーンされます。最新の行の値は常に現在のデータベースに保存され、tempdbに保存されているバージョン管理された行にチェーンされます。

短期間のトランザクションの場合、変更された行の嫌悪感は、tempdbデータベースのディスクファイルに書き込まれることなく、バッファプールにキャッシュされる可能性があります。バージョン管理された行の必要性が短命である場合、それは単にバッファプールから削除され、必ずしもI/Oオーバーヘッドが発生するわけではありません。

余分なオーバーヘッドに対してわずかなパフォーマンスの低下があるように見えますが、無視できる場合があります。確認するためにテストする必要があります。

このオプションを設定して、本当に必要な場合を除いて、コードクエリからすべてのNOLOCKを削除してみてください。 NOLOCKまたはデータベースコンテキストハンドラーでグローバルメソッドを使用してデータベーストランザクション分離レベルと戦うことは、問題に対するバンドエイドです。 NOLOCKSは、データレイヤーの基本的な問題を覆い隠し、信頼性の低いデータの選択につながる可能性があります。この場合、行の自動選択/更新のバージョン管理が解決策のようです。

ALTER Database [StackOverflow.Beta] SET READ_COMMITTED_SNAPSHOT ON