SQL Server 2005デッドロックシナリオのトラブルシューティング
デッドロックのシナリオに遭遇しています。デッドロックの唯一の関係者は、単一のテーブルと、そのテーブルから削除する単一のストアドプロシージャであるように見えます。エラーログのトレースを解読するガイドラインとして以下のMSDNの記事を使用して、これらのデッドロックのいくつかの時点でのSQLエラーログの私の分析に基づいて、その結論を導き出しました。 テーブルDEXTableとストアドプロシージャClearDEXTableRowsを以下に定義します。DEXTableに行を挿入する別のストアドプロシージャInsertDEXTableRowがありますが、そのプロシージャはSQLエラーログのエントリに基づくデッドロックに関与していないようです。 DEXTableには約830万行があり、着実に成長する傾向があります。回答者のテーブルも大きく、着実に成長する傾向があります。 ClearDEXTableRowsとInsertDEXTableRowをすばやく連続して頻繁に呼び出すページがある、トラフィック量の多いWebサイトからアクセスされます。 デッドロックは、過去10日間、1日あたり0〜9回発生しました。 1222のSQLトレースを有効にし(DBCC TRACEON 1222を使用)、最近フラグ1204を有効にしました。デッドロックの検出と終了に関するこれらのフラグの出力については、適切な説明があります 私の質問は: この1つのストアドプロシージャClearDEXTableRowsだけがデッドロックの原因であることは理にかなっていますか? もしそうなら、誰もがこれがどのように起こり得るかの良い説明を提供し、それを修正する方法を勧めることができますか? 私の疑いは、DELETEステートメントが頻繁に再構築する必要があるDEXTableのPKで競合を引き起こしていることです。 そうでない場合、デッドロックの原因をさらに掘り下げるには、どのような追加のトレースを有効にする必要がありますか?(私はここで学びたいです) -- Table definition CREATE TABLE [dbo].[DEXTable]( [ExportID] [int] NOT NULL, [RespondentID] [int] NOT NULL, [Exported] [datetime] NOT NULL, CONSTRAINT [PK_DEXTable] PRIMARY KEY CLUSTERED ( [ExportID] ASC, [RespondentID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = …