外部キーはデッドロックを引き起こし、READ COMMITTED SNAPSHOTを妨げることができますか？

19

これは次の質問です：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 tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
        [fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
    FROM INSERTED;
END

したがって、このトリガーは、update-triggerを起動する原因となるRMA-Tableを更新します（類似の動作）。デッドロックグラフは私の仮定を確認しますか？これらの列はSSAS-Cube（Molap）専用であるため、これらのトリガーを削除し、完全に十分な1日1回実行されるSPを作成すると思います。

編集：ところで、これらのトリガーを削除したので、もうデッドロックはありませんでした:)

sql-server sql-server-2005 deadlock

— ティム・シュメルター
ソース

16

SQLCATチームが、読み取りコミットされた分離を使用してFK 検証が行われたと言った場合、彼らは何について話しているのかを知る必要があります。検証の重視。本当の質問は、なぜレポートがFK検証をトリガーするのかということです。書き込み時に検証が行われ、レポートは読み取りと見なされます。レポートが書き込みを引き起こしている場合、その場合、スナップショット分離レベルは何の役にも立たず、デッドロックの原因も異なります。

前進させる唯一の方法は、デッドロックグラフをキャプチャすることです。

中を見て：あなたはスナップショット分離の下で動作する場合は、他の質問については、どのように確認することができますsys.dm_tran_active_snapshot_database_transactions。

— レムス・ルサヌ
ソース

2

外部キーの検証は、正確さのためにコミットされた（ロック）読み取りで発生する必要があります。スナップショット分離：整合性の脅威をご覧ください。詳細については、ヒューゴ・コルネリスによる。

デッドロックのグラフはRM2.dbo.RMA、デッドロックを引き起こす2つの同時実行を示しています。トリガーにRMAとの間の結合条件がありませんinserted。

これは見落としであり、トリガーがすべての行を誤って更新してRMAいる可能性が高いため、複数のトリガーが同時に実行されている場合、デッドロックが発生する可能性が非常に高くなります。

— user126897
ソース