web-dev-qa-db-ja.com

Parallelism（Repartition Streams）オペレーターが行の見積もりを1に減らすのはなぜですか？

SQL Server 2012 Enterpriseを使用しています。 SQLプランに出くわしましたが、まったく直感的ではないいくつかの動作を示しています。重い並列インデックススキャン操作の後、並列処理（Repartition Streams）操作が発生しますが、インデックススキャン（Object10.Index2）によって返される行の見積もりが強制終了され、見積もりが1に減少します。一部の検索を実行しましたが、この動作を説明するものは何も見つかりませんでした。クエリは非常に単純ですが、各テーブルには数百万のレコードが含まれています。これはDWHロードプロセスの一部であり、この中間データセットは全体を通して数回処理されますが、私が持っている質問は、特に行の見積もりに関連しています。正確な行の推定値がParallelism（Repartition Strems）オペレーター内で1になる理由を誰かが説明できますか？また、これは私がこの特定の状況で心配すべきことですか？

プラン全体を Paste the Plan に投稿しました。

問題の操作は次のとおりです。

enter image description here

コンテキストを追加する場合に備えてプランツリーを含める：

enter image description here

ポールホワイトが提出した このコネクトアイテム のいくつかのバリエーションに遭遇する可能性がありますか（彼のブログ こちら ）？少なくとも、TOP演算子が機能していなくても、実行しているものにかなり近いように見えるのは、これだけです。

sql-serversql-server-2012execution-plancardinality-estimates
12
John Eisbrener

ビットマップフィルターを使用したクエリプランは、読みにくい場合があります。から 再パーティションストリームのBOLの記事 （私の強調）：

Repartition Streamsオペレーターは、複数のストリームを消費し、レコードの複数のストリームを生成します。レコードの内容とフォーマットは変更されません。 クエリオプティマイザーがビットマップフィルターを使用する場合、出力ストリーム内の行数は減少します。

さらに、ビットマップフィルターの 記事 も役立ちます。

ビットマップフィルタリングを含む実行プランを分析する場合、データがプランをどのように流れ、フィルタリングが適用される場所を理解することが重要です。ビットマップフィルターと最適化されたビットマップは、ハッシュ結合のビルド入力（ディメンションテーブル）側で作成されます。ただし、実際のフィルタリングは通常、ハッシュ結合のプローブ入力（ファクトテーブル）側にある並列処理演算子内で行われます。ただし、ビットマップフィルターが整数列に基づいている場合、フィルターは並列処理演算子ではなく、初期テーブルまたはインデックススキャン操作に直接適用できます。この手法は、行内最適化と呼ばれます。

私はそれがあなたのクエリで観察していることだと信じています。ビットマップ演算子がファクトテーブルに対してIN_ROWである場合でも、比較的単純なデモを考えて、再分割ストリームオペレーターが基数の見積もりを減らすことを示すことができます。データ準備：

create table outer_tbl (ID BIGINT NOT NULL);

INSERT INTO outer_tbl WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;

create table inner_tbl_1 (ID BIGINT NULL);
create table inner_tbl_2 (ID BIGINT NULL);

INSERT INTO inner_tbl_1 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

INSERT INTO inner_tbl_2 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

実行すべきではないクエリを次に示します。

SELECT *
FROM outer_tbl o
INNER JOIN inner_tbl_1 i ON o.ID = i.ID
INNER JOIN inner_tbl_2 i2 ON o.ID = i2.ID
OPTION (HASH JOIN, QUERYTRACEON 9481, QUERYTRACEON 8649);

計画 をアップロードしました。 inner_tbl_2の近くの演算子を見てください。

repartition losing rows

また、Paul Whiteによる Nullable列でのハッシュ結合 の2番目のテストも参考になります。

行削減がどのように適用されるかには、いくつかの不整合があります。少なくとも3つのテーブルがあるプランでしか見ることができませんでした。ただし、予想される行の削減は、適切なデータ分散では妥当なようです。ファクトテーブルの結合された列に、ディメンションテーブルに存在しない多くの繰り返し値があるとします。ビットマップフィルターは、それらの行が結合に到達する前にそれらを削除する場合があります。クエリでは、推定値が1にまで減少します。行がハッシュ関数にどのように分散されているかによって、良いヒントが得られます。

row distro

それに基づいて、Object1.Column21列に繰り返し値がたくさんあると思います。繰り返される列がObject4.Column19の統計ヒストグラムにない場合、SQL Serverはカーディナリティの見積もりを非常に誤ったものにする可能性があります。

クエリのパフォーマンスを向上させることができるかもしれないことを心配する必要があると思います。もちろん、クエリが応答時間またはSLA=要件を満たしている場合は、さらに調査する価値はないかもしれません。ただし、さらに調査したい場合は、実行できることがいくつかあります（その他統計を更新するよりも）クエリオプティマイザーがより良い情報を持っている場合に、より良いプランを選択するかどうかを把握します。Database1.Schema1.Object10とDatabase1.Schema1.Object11の間の結合の結果を一時テーブルに入れて、ネストされたループ結合を引き続き取得する場合。その結合をLEFT OUTER JOINに変更すると、クエリオプティマイザはそのステップで行数を減らしません。クエリにMAXDOP 1ヒントを追加できます何が起こるかを確認します。TOPを派生テーブルと一緒に使用して、結合を強制的に最後に実行するか、クエリから結合をコメント化することもできます。

質問の connect item については、質問に関連している可能性はほとんどありません。その問題は、行の見積もりが悪いこととは関係ありません。これは、並列処理の競合状態と関係があり、バックグラウンドのクエリプランで処理される行が多すぎます。ここでは、クエリが余分な作業を行っていないようです。

9
Joe Obbish

ここでの中心的な問題は、最初の結合の結果のカーディナリティの推定が不十分であることです。これはさまざまな理由で発生する可能性がありますが、ほとんどの場合、古くなった統計か、オプティマイザのデフォルトモデルが独立していると想定している、いくつかの相関結合述部です。

後者の場合、 FIX：SQL Server 2008またはSQL Server 2008 R2またはSQL Server 2012で相関AND述語を含むクエリを実行すると、パフォーマンスが低下します は、サポートされているトレースフラグ4137を使用すると関連する場合があります。トレースフラグ4199を使用してクエリを試し、オプティマイザの修正を有効にしたり、2301を使用して拡張機能のモデリングを有効にしたりすることもできます。匿名化された計画に基づいて知ることは困難です。

ビットマップの存在は、結合のカーディナリティの推定に直接影響しませんが、初期の準結合縮小を適用することで、その効果をより早く目に見えるようにします。ビットマップがなければ、最初の結合のカーディナリティの見積もりは同じになり、残りの計画はそれに応じて最適化されます。

興味がある場合は、テストシステムで、トレースフラグ7498を使用してクエリのビットマップを無効にできます。最適化されたビットマップ（オプティマイザーによって考慮され、カーディナリティの推定に影響を与える）を無効にして、最適化後のビットマップ（検討対象外）に置き換えることもできます。オプティマイザによって、カーディナリティへの影響はありません）トレースフラグ7497と7498の組み合わせ。ドキュメント化も運用システムでの使用もサポートされていませんが、オプティマイザが通常検討できる計画を生成するため、計画ガイド。

上記のように、これはいずれも最初の結合の貧弱な見積もりの​​中心的な問題を解決しません。そのため、私は単に利益のためにそれについて言及しています。

ビットマップとハッシュ結合についてさらに読む：

6
Paul White 9

twitterであなたに返信しました。添付のXMLを見ると、不均衡な並列処理が見られました。 1つのスレッドには実際の行のほとんどすべてが含まれていますが、他のほとんどのスレッドには含まれていません。それは不均衡な並列処理が発生していることを叫びます。したがって、私はキー/結合値とそのそれぞれの統計とカーディナリティを調べます。

貼り付けたプランには私が見たどこにもTOPが含まれていないので、あなたの別の考えによると、私は接続アイテムが適用されるとはあまり確信していません。

0
SQLBek