0

私はSSISパッケージについて学び始めたばかりなので、私の質問の答えがあなたにとって明らかであると思われる場合は、ご容赦ください:-)

DEV/SYSTEST/DTE/LIVE などのさまざまな環境にインストールする必要がある SSIS パッケージがあります。SQL Server 接続文字列は環境ごとに異なることに注意してください。そのため、異なる構成ファイルが必要です。

これを展開するために私が考えている方法は

  • 環境ごとに個別のパッケージ構成ファイルを作成する
  • 構成ファイルのパスを保持するために、「MyPackageConfigPath」などの環境変数を作成します。
  • /ConfigFile スイッチを指定した DtExec コマンドを使用してパッケージを実行します。

私の質問:

  • これは、さまざまな環境に SSIS パッケージを展開する良い方法ですか?
  • このシナリオでパッケージを実行する他のより良い方法はありますか?

ありがとうございました！

4

3 に答える 3

1

2005 ～ 2008 R2 または 2012 とパッケージ展開モデルを想定すると、構成のオプションは次のとおりです。

  1. 親パッケージ
  2. レジストリ値
  3. 環境変数
  4. コマンドラインの割り当て
  5. XML ファイル
  6. データベース テーブル

一般に、単一値構成 (1 ～ 4) と複数値構成 (5 ～ 6) にグループ化できます。それらすべてに長所と短所がありますが、プライマリ構成リポジトリとしてデータベース テーブルを使用すると、最高の経験が得られます。すべての値は特定の環境用にそこに保存されるため、各環境 (開発、テスト、ロード、ステージ、本番) サーバーには、構成用のテーブルを含む専用のカタログがあります (ログやその他の ETL 固有のものも同様です)。

テーブルアプローチ

私のテーブルが気に入らない場合は、独自のテーブルを作成するか、BIDS/SSDT に任せることができます。

CREATE TABLE dbo.SSISConfig
(
    id identity(1,1) NOT NULL PRIMARY KEY
,   ConfigurationFilter nvarchar(150) NOT NULL -- Package Name
,   ConfiguredValue nvarchar(255) NULL -- Value of setting, such as a connection string
,   PackagePath nvarchar(255) NOT NULL -- Target within SSIS package where value is written
,   ConfiguredValueType nvarchar(20) NOT NULL -- Data type such as String, Int32, or DateTime
)

DEVサーバーでの例は次のようになります

id  | ConfigurationFilter| ConfiguredValue                                                                         | PackagePath                                              | ConfiguredValueType
100 | Default.2005.Sales | Data Source=DEV;Initial Catalog=SALESDEVDB;Provider=SQLNCLI.1;Integrated Security=SSPI; | \Package.Connections[SLSDB].Properties[ConnectionString] | String

本番環境の同じ行は次のようになります

id  | ConfigurationFilter| ConfiguredValue                                                                          | PackagePath                                              | ConfiguredValueType
123 | Default.2005.Sales | Data Source=PROD;Initial Catalog=SALESPRODB;Provider=SQLNCLI.1;Integrated Security=SSPI; | \Package.Connections[SLSDB].Properties[ConnectionString] | String

データベースとサーバー名の変更を処理するために展開されるサーバーを考慮した構成展開スクリプトがあるため、維持するスクリプトは 1 つだけです。そのような場合、XML ファイルの同期を維持するのは難しいと思います (がらくた、プロダクションの構成ファイルを更新するのを忘れて、間違ったデータを取得しました)。

トリック

2 番目の箇条書きで特定したように、これを機能させる秘訣は、SSIS に別の構成セットを使用するように指示するメカニズムが必要なことです。マルチインスタンス マシンを使用していない場合は、環境変数を使用するのが優れたアプローチであることがわかります。パッケージを実行するサーバーごとに 1 回定義すれば完了です。マルチインスタンス環境で作業する場合は、よりトリッキーな状況になります。

HLGEM は、マルチインスタンス環境でローカル環境変数を使用してさまざまなサービス アカウントを使用するという回答で、かなり巧妙なアプローチをとったと思います。下にスクロールして、マルチインスタンス マシンでの私のアプローチを確認できます。

構成について説明したさまざまな回答

于 2012-07-11T20:02:51.373 に答える
0

最良の答えは、あなたの状況に適したものです。信じられないほど役に立ちませんが、これで終わりです。あなたのソリューションがうまくいかない理由がわかりません。

一部の場所では、運用マシンに環境変数を追加することに少しうるさいです。それができれば問題ありません。そうでない場合、構成ファイルを各マシンの同じ場所に置き、その場所をハードコーディングできますか? さらに、展開時に心配することが 1 つ少なくなります。

于 2012-07-03T15:00:58.893 に答える
0

環境変数をいじるのは好きではなく、パッケージ構成で「SQL Server」構成要素を使用する方が簡単だと思います。選択したデータベースに事前定義された構造の構成テーブルを作成します。そのデータベースは、サーバー「localhost」の「config123」でさえあるかもしれません。それが私がすることです。次に、その構成データベースをローカル開発マシンとサーバーの両方に保持しますが、構成エントリの値は異なります。これは、開発時にパッケージがローカルの構成設定を使用し、サーバーで実行されるときに本番サーバーの構成を自動的に使用することを意味します。:-)

また、msdb にパッケージを保持し (DeploymentManifests は Visual Studio によって作成されますが、大したことではありません)、SQL Server エージェントがそれらのパッケージを定期的に実行できるようにします。これにより、変更の展開が非常に簡単になります。更新されたパッケージを msdb にデプロイするだけで準備完了です。

于 2012-07-04T08:25:04.137 に答える