実行にかかっているデータフロータスクがあります。
フローは単純で、異なるテーブルに対して2つのクエリを作成し(両方とも結合)、共通IDを使用してotuputsをソートおよびマージし、すべてのレコードに静的列を追加し、行数を保存します後で使用するためのユーザー変数で、最終的に別のDBのテーブルに挿入します。 OLE DB Sources and Destination。SourceはMSSQL 2000、DestinationはMSSQL 2012です。
症状:
失敗したソリューション:
追加ビット: 誰かが私を助けてくれることを本当に願っています。私はSSISを初めて使用しますが、これを使用するのは初めてです。私は通常、ETLのためにPentahoと連携していますが、クライアントはSSISに実装するソリューションを必要としています。私はここ数日この問題と戦っていて、それを解決するためのアイデアが尽き始めています。
コマンドラインを実行すると、スタックし、次の出力が表示されます。
Progress: 2013-03-19 14:36:26.21
Source: Load Sandbox Table
Validating: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.21
Source: Load Sandbox Table
Validating: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.22
Source: Load Sandbox Table
Validating: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.22
Source: Load Sandbox Table
Validating: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.23
Source: Load Sandbox Table
Validating: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.25
Source: Load Sandbox Table
Validating: 100% complete
End Progress
Warning: 2013-03-19 14:36:26.26
Code: 0x80047076
Source: Load Sandbox Table SSIS.Pipeline
Description: The output column "ITEM_OID (1)" (47) on output "Merge Join Outp
ut" (28) and component "Merge Join" (11) is not subsequently used in the Data Fl
ow task. Removing this unused output column can increase Data Flow task performa
nce.
End Warning
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.27
Source: Load Sandbox Table
Prepare for Execute: 100% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.31
Source: Load Sandbox Table
Pre-Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.34
Source: Load Sandbox Table
Pre-Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:45.69
Source: Load Sandbox Table
Pre-Execute: 50% complete
End Progress
その後、再びフリーズします。
[〜#〜] solution [〜#〜](自分の質問にさらに5時間答えられないため、ここに投稿します。許可されている場合)
ようやくわかりました。
検証に問題があることが判明しましたが、質問の4番目の失敗したソリューションで述べられているように、SSIS要素だけがその検証を通過しません。
CONNECTIONSも検証され、独自の遅延検証プロパティがあります。これはtrueに設定する必要があります。
その後、実行時間は40分以上または実行なしからフルプロセスの1分未満になりました(これは、より大きなプロセスのほんの1ステップです)
この問題に直面している人が多く、オンラインに投稿されたソリューションがほとんどないため、同じ問題を抱えている人がこのソリューションを簡単に見つけられることを願っています。
一言で言えば:タスクに関係するすべての要素を確認し、includeDB接続の遅延検証プロパティがTrueに設定されている。
やっと手に入れました。検証に問題があることが判明しましたが、質問の4番目の失敗したソリューションで述べられているように、SSIS要素だけが検証を通過するわけではありません。 CONNECTIONSも検証され、独自のDelay Validationプロパティがあります。これはtrueに設定する必要があります。その後、実行時間はフルプロセスの40分以上または実行なしから1分未満になりました(これははるかに大きなプロセスの1つのステップに過ぎません)この問題に直面している人々の数とオンラインで投稿されたソリューションはほとんどありません。
一言で言えば:タスクに関係するすべての要素(DB接続を含む)の遅延検証プロパティがTrueに設定されていることを確認します。
同じ症状が出ましたが、各コンポーネントで遅延検証をTrueに設定しても問題は解決しませんでした。
OLE DBメソッドをテーブルまたはビューからsqlコマンドに変更することで解決しました。
よろしく。
私はこれが古いことを知っていますが、これについて役立つリンクを見つけました。私は個人的にビューを使用してデータを外部データベースにエクスポートするだけで、データ検証にはビューの検証に過度の時間がかかります。
これの重要な部分はマイクロソフトの答えです
マイクロソフトによる2008年4月28日午後2時45分
これは既知の問題であり、現在の設計の結果です。
OLE DBソースのビューからデータをプルするには2つの方法があります。
「テーブルまたはビュー」アクセス方法を使用
「SQLコマンド」アクセス方法を使用し、「select * from ***」というクエリを入力します
2つのアプローチでは、異なる実行計画が生成されます。
前者で使用されているものは、後者ほど効率的ではありません。
最初のアプローチでパフォーマンスの問題が発生した場合は、回避策として2番目のアプローチに切り替えることができます。
また、この問題をブログに掲載しました-> http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-効率的に.aspx 。
これは「設計による」項目であり、回避策があると考えているため、現時点では変更を提供しません。その結果、提出に関連するケースをクローズします。同意できない場合は、お気軽に再送信してください。
SSISの時間、努力、サポートに感謝します。
データアクセスモードをSQLコマンドに変更し、OLE DBソースのSQLコマンドテキストにビューを貼り付けて問題を修正しました。
Delayed ValidationsはTrue
に設定されており、couldnt/didntはそれをSQLステートメントに変更したいと考えています。
データフローでValidateExternalMetadata
に変更したFalse
に出会い、それはチャンピオンのように機能するようです。
OPの手順を確認したところ、手順5でOPの手順を実行したとのことです
これが誰かを助けることを願っています。私はこれを使用してOLE DB SourceをSPで実行しました。何も返す必要はありませんでした。しかし、「sqlによって列情報が返されませんでした」と叫んだので、SPにダミーのsqlステートメントを構成しましたが、これは決してtrueに設定しませんでした。ジョブは実行前フェーズで停止したため、このテストを常にtrueに変更し、列を返し、それを実行しました。列には何もしませんが、そこで必要だと思います。
この問題は、SQL Server 2012/2014でも引き続きアクティブです。
上記の解決策はどれも役に立たなかった。実際、検証の遅延、OLD DB宛先の構成の変更、またはOLE DB接続。
問題は実行計画にあることが示唆されています。
これは私の場合に当てはまり、1 = 1をmy OLE DB Source構成に追加すると、SQLサーバーは問題を修正する新しい実行計画を生成するように強制しました。
試してみるべきもう1つのことは、「32ビットランタイムを使用する」チェックボックスをチェックすることです-これは、DBサーバーでジョブとしてパッケージを実行するときに問題が発生する場合です(64ビットで、私の場合は少なくとも、SQL Server 2008R2)。ジョブに移動して、右クリック>プロパティ…>ステップ> SSISパッケージステップを右クリック>プロパティ…>一般>実行オプション(タブ)> 32ビットランタイムを使用.
この問題は発生していましたが、サーバーにパッケージを展開したのは一度だけです(ログプロバイダーを有効にしていたため、「実行前」フェーズ後にスタックすることがわかりました)。 BIDSでは常に正常に実行されていました(別のサーバーでも正常に動作しましたが、奇妙なことに、それがなぜなのかまだわかりません)。
スレッド here は、このソリューションがうまくいくように思われましたが、私の問題は断続的に現れるので、YMMVです。そのスレッドには他の可能な解決策もあります。
数分前に同じ問題に遭遇しましたが、上記の提案はうまくいきませんでした(遅延検証= trueが答えになりそうです)。最近、パラメータースニッフィングに関する問題をいくつか発見しました。ストアドプロシージャで修正すると、パッケージは1分未満で実行されました。ストアドプロシージャをチェックして、これが原因かどうかを確認することを検討してください。