0

百万以上のレコードを持つテーブルがあります。

  1. SSMSでクエリを実行すると、どの時点でも確実に2分未満で約1:24かかり、約600,000レコードが返されます。
  2. SSISには数時間以上かかりますが、実際には1回だけエクスポートできました。

サンプルSQLは次のとおりです。

SELECT distinct 
A.Col1, A.Col2, A.Col3, A.Col4, A.Col5, A.Col6, A.Col7, B.Col3
FROM tblA  A
inner join tblB B on A.Col1 = B.col1 and 
A.Col2 = 'AB' AND A.Col3 Not In ('A','B','C') AND 
A.Col3 In ('FPC','FPE','PRN','SUB','RVW','FPO','FEV','PRM')

注：インデックスは、select sqlクエリのすべての列（およびwhere句で言及されている列）に存在します。

SSISでは、

  1. 制御フローに関するデータフロータスクがあります。
  2. SQLクエリコマンドを使用したOleDBソース。
  3. OleDBDestinationtbl。

SSISの遅延の原因は何ですか？

4

2 に答える 2

1

問題は、OLEDB変換先と行を受け入れることができる速度にある可能性があります。これは、OLEDB変換先を削除したパッケージのコピーをテストすることで確認できます。

その場合、最も一般的な理由は、SQLServerに配信するOLEDB変換先で[高速ロード]オプションを使用しないことです。

于 2013-02-26T02:44:14.693 に答える
1

私の経験では、これは次の2つのうちの1つである可能性があります。

  1. これは、パラメータスニッフィングとして知られているものである可能性があります。これは単に、悪い（遅い）クエリプランをクエリ+パラメータにバインドすることがあり、キャッシュが原因でこの悪いプランが「スタック」し、特定のアプリケーションや用途に継続的に再利用される可能性があることを意味します。これを検出する方法は、SQLプロファイラーを使用してSSISタスクのクエリのクエリプランをキャプチャし、それを高速実行SSMSバージョンのクエリプランと比較することです。クエリプランが大幅に異なる場合は、パラメータスニッフィングの問題が発生している可能性があります。

  2. ただし、SSISの場合、より一般的な問題があります（私のコメント/質問とMike Honeyの回答でほのめかされています）：SSISはパイプラインアーキテクチャを使用するため、パイプライン全体を停止するために必要なのは、チェーン内の1つの低速コンポーネントだけです。また、コンポーネントが遅い原因の1つは、データフロータスクに最適なタスク設定を使用していないことです。

「高速ロード」の使用は1つの可能性ですが、私の経験では、ネットワークを介したパイプライン処理でより一般的に問題となる別の設定、つまり「DefaultBufferMaxRows」があります。これのデフォルトは10,000ですが、これはネットワーク接続には高すぎることが常にわかっており、これらの状況ではおそらく100から1000の間であるはずです。

これは、制御フローの宛先DFT（データフロータスク）のプロパティであるため、変更するには、制御フロービューでそのタスクのアイコンを選択するだけです。プロパティペイン（[その他]の下）にDefaultBufferMaxRowsが表示されます。「DefaultBufferSize」も比例して小さくすることもできます。

于 2013-02-26T15:36:04.650 に答える