プライマリデータベースインスタンスとは異なるサーバーからSSISを実行する
現在、SQL ServerからDB2にデータを移動するために抽出転送ロード（ETL）プロセスを実行する単一のSQL Server Integration Services（SSIS）パッケージがあります。現在の運用サーバーでは、SSISはデータベースインスタンスと同じサーバーにインストールされ、パッケージの実行はジョブを介してSQLエージェントによって管理されます。
SQLインフラストラクチャをクラスタ化するようにアップグレードしており、上級データベース管理者が独自のサーバーにSSISをインストールしたいと考えているため、マシンに統合サービスサービスをインストールするだけでETLサーバーがセットアップされました。
SSISサーバーは、パッケージの実行を管理するために、独自のデータベースインスタンスやSQLエージェントを必要としますか？
このシナリオですべての要素がどのように機能するかを理解するのに問題があります。
SQL Server 2008 R2 SP1を使用しています。
MSDNでSSISについて読むことをお勧めします： 初期インストール（統合サービス） -これは、SSISのみのスタンドアロンインストールを参照しています。
上記のリンクからの引用：
SQL Server Integration Servicesは、SQL Server 2008セットアッププログラムを通じてインストールされます。 Integration Servicesを他のSQL Serverコンポーネントと一緒にインストールするか、Integration Servicesをスタンドアロンコンポーネントとしてインストールできます。 Integration Servicesには、クライアントアプリケーションとサーバーアプリケーションの両方が含まれています。
抽出、変換、および読み込み（ETL）プロセスに専用サーバーを使用するには、Integration Servicesをインストールするときに、SQL Serverデータベースエンジンのローカルインスタンスをインストールすることをお勧めします。 Integration Servicesは通常、パッケージをデータベースエンジンのインスタンスに格納し、SQL Serverエージェントを使用してこれらのパッケージをスケジュールします。 ETLサーバーにデータベースエンジンのインスタンスがない場合は、データベースエンジンのインスタンスがあるサーバーからパッケージをスケジュールまたは実行する必要があります。つまり、パッケージはETLサーバーではなく、パッケージの起動元のサーバーで実行されます。その結果、専用ETLサーバーのリソースが意図したとおりに使用されていません。さらに、実行中のETLプロセスによって他のサーバーのリソースに負担がかかる可能性があります。
その他の情報もここにあります： Integration Servicesのインストールに関する考慮事項 。ライセンスも考慮して、スタンドアロンサーバーが適切にライセンスされていることを確認することをお勧めします。
どのような場合でもデータベースを使用することをお勧めします。例外レコード、構成、実行されたパッケージのログ情報、ステージングテーブルなどを保存するために使用します。