2
SELECT / INSERTデッドロック
このインスタンスは、SharePoint 2007データベース（SP）をホストします。SPコンテンツデータベース内の使用率の高い1つのテーブルに対して、多数のSELECT / INSERTデッドロックが発生しています。関連するリソースを絞り込みました。両方のプロセスで非クラスター化インデックスのロックが必要です。INSERTはSELECTリソースでIXロックを必要とし、SELECTはINSERTリソースでSロックを必要とします。デッドロックグラフは、3つのリソースを示しています。1）SELECT（プロデューサー/コンシューマーパラレルスレッド）からの2つ、および2）INSERTです。確認のためにデッドロックグラフを添付しました。これはMicrosoftのコードとテーブルの構造であるため、変更を加えることはできません。 ただし、MSFT SPサイトで、MAXDOPインスタンスレベルの構成オプションを1に設定することを推奨していることを確認しました。このインスタンスは他の多くのデータベース/アプリケーション間で共有されているため、この設定を無効にすることはできません。 したがって、私はこれらのSELECTステートメントが並列にならないようにすることを試みました。これは解決策ではなく、トラブルシューティングに役立つ一時的な変更であることがわかっています。そのため、ワークロードが変更されていない（SELECT / INSERTが頻繁に発生する）にもかかわらず、デッドロックがなくなったにもかかわらず、「並列処理のコストしきい値」を標準の25から40に増やしました。私の質問はなぜですか？ SPID 356 INSERTは、非クラスター化インデックスに属するページにIXロックを持っています SPID 690 SELECT実行ID 0は、同じ非クラスター化インデックスに属するページにSロックを持っています 今 SPID 356はSPID 690リソースのIXロックを要求しますが、SPID 690がSPID 690によってブロックされているため、それを維持 できません。 1はSPID 356によってブロックされており、デッドロックが発生しています。 実行計画は私のSkyDriveにあります 完全なデッドロックの詳細はここにあります 誰かが私になぜそれを本当に感謝するか理解するのを手伝ってくれるなら。 EventReceiversテーブル。 Id uniqueidentifier no 16 Name nvarchar no 512 SiteId uniqueidentifier no 16 WebId uniqueidentifier no 16 HostId uniqueidentifier no 16 HostType …