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
int no 4
ItemId int no 4 DirName nvarchar no 512
LeafName nvarchar no 256
Type int no 4
SequenceNumber int no 4
Assembly nvarchar no 512
Class nvarcharいいえ512
データnvarcharいいえ512
フィルターnvarcharいいえ512
SourceId tContentTypeIdいいえ512
SourceType int no 4
Credential int no 4
ContextType varbinary no 16
ContextEventType varbinary×16
ContextId varbinary
× 16 ContextObjectId varbinary×16
ContextCollectionId varbinary × 16

index_name index_description index_keys
EventReceivers_ByContextCollectionId非クラスター化はPRIMARY SiteIdにあり、ContextCollectionId
EventReceivers_ByContextObjectId非クラスター化はPRIMARY SiteIdにあり、ContextObjectId
EventReceivers_ById非クラスター
化は、PRIMARY SiteIdにあります。 ContextId、ContextType、ContextEventType、SequenceNumber、Assembly、Class
EventReceivers_IdUnique非クラスター化、一意、PRIMARY Idにある一意のキー

一見すると、これは古典的なルックアップデッドロックのように見えます。このデッドロックパターンに不可欠な要素は次のとおりです。

• SELECTキールックアップで非カバリング非クラスター化インデックスを使用するクエリ
• INSERTクラスタ化インデックス、その後、非クラスタ化インデックスを変更するクエリ

はSELECT最初に非クラスター化インデックスにアクセスし、次にクラスター化インデックスにアクセスします。INSERTアクセスクラスタ化インデックス最初に、その後、非クラスタ化インデックス。もちろん、同じリソースに異なる順序でアクセスして互換性のないロックを取得することは、もちろんデッドロックを「達成する」ための優れた方法です。

この場合、SELECTクエリは次のとおりです。

...そしてINSERTクエリは：

緑で強調表示された非クラスター化インデックスのメンテナンスに注意してください。

SELECTプランのシリアルバージョンがパラレルバージョンと非常に異なる場合は、プランのシリアルバージョンを確認する必要がありますが、ジョナサンケハイアスがデッドロックの処理に関するガイドで指摘しているように、この特定のデッドロックパターンは、タイミングと内部クエリ実行の実装の詳細に非常に敏感です。このタイプのデッドロックは、明らかな外部の理由なしにしばしば行き来します。

関連するシステムへのアクセスと適切な権限があれば、最終的に並列計画でデッドロックが発生するのに、シリアルではなくなぜデッドロックが発生するのかを正確に突き止めることができると確信しています（同じ一般的な形を想定しています）。潜在的な問い合わせ行には、最適化されたネストされたループのチェックやプリフェッチなどが含まれます-どちらも、ステートメントの期間中、内部的に分離レベルをエスカレートできREPEATABLE READます。並列インデックスシーク範囲の割り当ての一部の機能が問題の原因である可能性もあります。シリアルプランが利用可能になった場合は、興味を引く可能性があるため、詳細をさらに調査することに少し時間をかけることがあります。

このタイプのデッドロックの通常の解決策は、インデックスをカバーすることですが、この場合の列の数はそれを非現実的にする可能性があります（それに加えて、SharePointでそのようなことを混乱させることは想定されていません）。結局のところ、SharePointを使用する場合のシリアルのみのプランの推奨は、理由があります（それには、必ずしも適切なものではありませんが）。並列処理のコストしきい値の変更により、現時点で問題が修正されている場合、これは問題ありません。長期的には、おそらくリソースガバナーを使用してワークロードを分離し、SharePointの内部クエリで目的のMAXDOP 1動作が得られ、他のアプリケーションで並列処理を使用できるようにすることを検討します。

デッドロックの痕跡に現れる交換の問題は、私にとっては赤いニシンのようです。技術的にツリーに表示されなければならないリソースを所有する独立したスレッドの単なる結果。交換自体がデッドロックの問題に直接貢献していることを示唆するものは何もありません。

これが従来のルックアップデッドロックであった場合、リソースリストにはクラスター化インデックスと非クラスター化インデックスの両方が含まれます。通常、SELECTはNCインデックスのSHAREDロックを保持し、CIのSHAREDロックを待ちますが、INSERTはCIのEXCLUSIVEロックを取得して、NCのEXCLUSIVEロックを待ちます。この場合、デッドロックxmlのリソースリストには、これらの両方のオブジェクトがリストされます。

デッドロックグラフにはNCインデックスのみが含まれるため、そのオプションを除外できます。

また、これがUNORDERED PREFETCHでのネストされたループ結合によるデッドロックであった場合、実行プランはUNORDERED PREFETCHアルゴリズムが使用されているかどうかを通知しますが、これはここでは当てはまりません（以下の更新を参照）。

そのため、これは並列プランによるデッドロックであると想定する必要があります。

デッドロックグラフは適切にレンダリングされませんが、デッドロックXMLを見ると、SELECTステートメント（SPID 690）からの2つのスレッドがデッドロックに関係していることがわかります。コンシューマスレッドは、ページ1219645で共有ロックを保持し、ポート801f8ed0（e_waitPipeGetRow）でプロデューサを待機しています。プロデューサスレッドは、ページ1155940で共有ロックを待機しています。

INSERTステートメントは、ページ1155940でIXロックを保持しており、ページ1219645でIXロックを待機しているため、デッドロックが発生しています。

SELECTステートメントにシリアルプランを使用すると、複数のページでSHAREDロックを必要としないため、デッドロックが回避されると思います。また、シリアルプランはパラレルプランとほぼ同じになると思います（並列化演算子を除きます）。

[ポールのコメントに基づいて更新]

どうやら計画はOPTIMIZEDネストループアルゴリズムを使用しています

これが、SHAREDロックがステートメントの終わりまで保持される理由を説明しています。パラレルプランと組み合わせてREPEATABLE READを実行すると、シリアルプランよりもデッドロックの影響を受けやすくなります。これは、パラレルプランがインデックスの異なる範囲からロックを取得して保持するのに対し、シリアルプランはより順次的な方法でロックを取得するためです。