外部キーはデッドロックを引き起こし、READ COMMITTED SNAPSHOTを妨げることができますか？
これは次の質問です：https : //stackoverflow.com/questions/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically 大規模なレポートを同時に実行すると、ASP.NETアプリケーションでデッドロック/タイムアウトが発生しますREAD_COMMITTED_SNAPSHOT ON。 そこで、2つの質問があります。 トランザクション分離レベルスナップショットが期待どおりに機能しているかどうかを確認するにはどうすればよいですか？ 外部キー（レポートテーブルへのWebアプリケーションのテーブル内）がデッドロックの原因であると想定しています。私はこの興味深い記事を見つけました： 注 SQL Serverは、トランザクションが読み取りコミットスナップショット（行バージョン管理を使用して読み取りコミット）またはスナップショット分離レベルを使用している場合でも、外部キーの検証時に共有ロックを取得します。これらのトランザクション分離レベルが使用されている場合、トランザクションのデッドロックグラフを調べるときは、このことに注意してください。共有ロックが表示される場合は、外部キーによって参照されているオブジェクトでロックが取得されているかどうかを確認してください。 FKがデッドロック/タイムアウト状況に本当に責任があるかどうかを確認するにはどうすればよいですか？つまり、デッドロックを防ぐためにそれらの外部キーを削除できますか？ 注：デッドロックを引き起こすテーブルからの読み取りのみです。 このトピックに関するご意見は大歓迎です。 編集 ここはDeadlock-Graphです。誰かがデッドロックの原因を理解するのを助けてくれるかもしれません。2つのトランザクションが同じテーブル（1つの更新と1つの挿入、挿入はStored-Procedureとして）を書きたいときに、Webアプリケーションによってのみ実行されるレポートなしで発生したようです。ページロックを取得する理由と、行ロックのみを有効にする方法 Insert-SPはすでにを使用していTRANSACTION ISOLATION LEVEL REPEATABLE READます。 2つのトリガー（1つの更新と1つの挿入）がデッドロックの原因であると強く疑っています。挿入トリガーは次のとおりです。 CREATE TRIGGER [dbo].[CreateRMAFiDates] ON [dbo].[RMA] AFTER INSERT AS BEGIN SET NOCOUNT ON; UPDATE RMA SET [fiCreationDate]=(SELECT idDate FROM tdefDate WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text), [fiPopDate]=(SELECT idDate FROM …