私は SSIS を初めて使用し、いくつか質問があります
同じデータベース内のあるテーブルから別のテーブルに 1,25,000 行を転送したいと考えています。しかし、私が使用するData Flow Taskと、時間がかかりすぎます。と を使用してみADO NET DestinationましたOLE DB Destinationが、パフォーマンスは受け入れられませんでした。同等のクエリを 内に記述したExecute SQL Taskところ、許容できるパフォーマンスが得られました。なぜこんなにも性能に差が出るのか。
INSERT INTO table1 select * from table2
最初の観察に基づいて、パッケージを変更しました。これはExecute SQL Tasks、直接クエリまたはストアド プロシージャのいずれかのみで構成されます。のみを使用して問題を解決できる場合Execute SQL Task、非常に多くのドキュメントや記事が示すように、なぜ SSIS を使用するのでしょうか。信頼性が高く、保守が簡単で、比較的高速であることを確認しました。
「単純な」データ フロー タスクおよび同等の SQL 実行タスクのパフォーマンスを引き起こす可能性のある要因は多数あります。
Execute SQL Tasks INSERT INTO のセットベースのアプローチとは対照的です。SSIS の最近のバージョンでは、デフォルトでアクセス方法が宛先の「高速」バージョンに設定されています。これは、セットベースの同等の機能と同様に動作し、パフォーマンスが向上します。Execute SQL Task単なるsである SSIS パッケージには、本質的に問題はありません。クエリを実行することで問題が簡単に解決できる場合は、SSIS を完全に忘れて、適切なストアド プロシージャを作成し、SQL エージェントでスケジュールして完了します。
多分。このような「単純な」ケースでも SSIS を使用することで私が気に入っているのは、一貫した成果物を保証できることです。大したことではないように聞こえるかもしれませんが、メンテナンスの観点からは、すべてがこれらのソース管理されたSSISパッケージに含まれているデータをいじっています。タスク AC は「単純」であるため、SQL エージェント ジョブから呼び出されるストアド プロシージャであることを新しい人に覚えたり、トレーニングしたりする必要はありません。タスク DJ、または K はそれよりもさらに単純なので、データをロードするためにエージェント ジョブで「インライン」クエリを実行するだけで、残りのパッケージを取得できます。Service Broker と一部の Web サービスを除いて、それらもデータベースを更新します。年齢を重ねるほど、触れる場所が増えるほど、やり過ぎであっても一貫したソリューション提供へのアプローチに価値を見出すことができます。
パフォーマンスがすべてではありませんが、SSIS チームは SSIS を使用して ETL ベンチマークを設定したため、一部のデータを急いでプッシュする機能を確実に備えています。
この回答が長くなるにつれて、SSIS の利点とストレート TSQL に対するデータ フローがネイティブであり、そのまま使用できるため、そのままにしておきます。
私のお金でそれらを打ち負かすのは難しい.