web-dev-qa-db-ja.com

SELECT ... INTO＃Temp2 FROM＃Temp1 JOIN LocalTable ...の実行でプロシージャがハングすることがあるのはなぜですか？

ジョブによって呼び出されるいくつかのストアドプロシージャがあり、特定のパターンに従います（ブロッキングを最小限に抑えるように設計されています）。これらのprocのいくつかは時々ハングする傾向があり、CPUを実行し、tempdbの割り当て、読み取り、書き込みが強制終了されるまで無期限に行われます。パターンは次のとおりです。

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
CREATE #RemoteTemp...;
INSERT INTO #RemoteTemp EXEC MyLinkedServer.DbName.SchemaName.ProcName;
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
SELECT...INTO #MixedTemp FROM #RemoteTemp JOIN LocalTable...;

次に、#MixedTemp。ただし、その最後のステートメントは、1秒未満で実行され、行カウントがすべての実行で同じであってもハングする場合があるステートメントです。何が原因でしょうか？

追加情報：

  • 1117と1118が有効になります。
  • この8コアインスタンスの8つのtempdbファイル。
  • Tempdbの自動拡張は行われていません。

ハング中：

  • Sch-Sローカルテーブルをロックします。

  • 読み込まれる一時テーブルで：

    Lock resource_type="HOBT.BULK_OPERATION" request_mode="S"
request_status="GRANT" request_count="1" Lock resource_type="OBJECT"
request_mode="X" request_status="GRANT" request_count="1"

  • 挿入される一時テーブルで：

    Lock resource_type="OBJECT"
 request_mode="X" request_status="GRANT" request_count="1"

Sp_lockから（6と7は一時テーブルに結合されるデータベース、2はtempdbです）：

spid   dbid   ObjId       IndId  Type Resource                         Mode     Status
------ ------ ----------- ------ ---- -------------------------------- -------- ------
96     6      0           0      DB                                    S        GRANT
96     7      0           0      DB                                    S        GRANT
96     6      702625546   0      TAB                                   Sch-S    GRANT
96     2      -1219105587 0      HBT  [BULK_OPERATION]                 S        GRANT
96     7      98099390    0      TAB                                   Sch-S    GRANT
96     2      -1219105587 0      TAB                                   X        GRANT
96     2      -1203105530 0      TAB                                   X        GRANT
96     7      115775811   0      TAB                                   Sch-S    GRANT
96     7      194099732   0      TAB                                   Sch-S    GRANT
sql-serversql-server-2012performancestored-proceduresinsert
6
Mark Freeman

不正なプランのXML showplanが提供されています は、クエリ内の2つのテーブルに行が示されていないことを示しています（プラン内の他のオブジェクトは問題ありません）。

Zero cardinality

SQL Sentry Plan Explorer のプランツリービューからキャプチャ

これは、統計の自動更新の問題が原因であるか、スナップショットアイソレーションで実行する際の問題が原因である可能性があります。まだ十分な情報はまだありません。いずれにせよ、これは調査する必要があるものです。

テーブルとインデックスの統計情報が実際に見つからない（または空である）場合、手動でこれらを作成すると、発生している問題をほぼ確実に解決できます。

誤った情報が与えられると、クエリオプティマイザーはネストされたループ結合を特徴とするプランを生成します。

NLJ plan

この計画は、実行時の行数がQOによって計画された数を大幅に超える場合、長時間実行される可能性があります。クエリはブロックされません。それは単に欠陥のある戦略を使用して実行し続けているだけです。

妥当な統計が利用可能なときに生成される「適切な計画」は、ハッシュ結合と並列処理を使用する実行計画を生成します。

Good plan

6
Paul White 9