1

SSIS パッケージが開発サイクル (開発、QA、ステージング、および運用) 中に移動する環境がいくつかあるため、SSIS の構成を使用して、接続マネージャーでサーバー名を設定したいと考えています。これを手動で行う必要はありません。

xml 構成ファイル、SQL 構成テーブル、および環境変数の使用について読みました。ただし、QA 環境とステージング環境が同じサーバー上にあるものの、2 つの別個の SQL インスタンスを使用しているという問題があります。この場合、サーバー名を動的に構成するにはどうすればよいですか?

4

3 に答える 3

2

これが私たちの扱い方です。環境変数を使用して、残りの構成を読み取るデータベースを決定します。環境変数はユーザーに関連付けられているため、QA のジョブをあるユーザーに設定し、ステージングのジョブを別のユーザーに設定します。ユーザーは SQLQA や SQLstaging などと呼ばれ、ジョブの実行にのみ使用されます。次に、環境変数は、SSIS config の残りの構成を格納するデータベースを指します。

于 2012-06-22T15:33:35.620 に答える
0

この問題に対する私の解決策は、設計時の値が常に開発環境を指すようにすることでした。開発者は誰でもパッケージを開き、その環境に対して検証し、すべて問題ありません。

dev の外でパッケージを実行するということは、パッケージが SQL エージェントを介して実行されることを意味していました。そのレベルの制御を正確に行うことができれば、正しい構成リポジトリを指すようにジョブを作成するのは簡単なことです。

物理的に実装された、構成、ログ フレームワーク + 標準ログ テーブル (sysdtslog90/sysssislog) を保持する環境 (SYSDB) ごとのカスタム ssis カタログを使用しました。すべてのパッケージには変数が必要でありUser::Default_ConfigurationServer、その変数は Configuration Connection Manager の ConnectionString プロパティの式として使用されていました。複雑に聞こえますが、そうではありません---

  1. 文字列型の変数を作成する
  2. 構成接続マネージャーの接続文字列の値をコピーし、それを値として貼り付けます
  3. 構成接続マネージャーの ConnectionString プロパティに式を割り当てます。

開発における最終的な効果は、それが何もしないということですが、今では他の環境で動作させることができます. 私のエージェントはすべて次のように見えます

DECLARE @serverName sysname
,    @jobstep_command nvarchar(4000)
-- Lots of other stuff removed
SET @serverName = @@servername

SET @jobstep_command = N'/SQL "\MyPackage"' + '" /SERVER "' + @serverName + '" /CHECKPOINTING OFF /REPORTING E /SET "\Package.Variables[User::Default_ConfigurationServer].Properties[Value]";"\"Provider=SQLNCLI10;Data Source=' + @serverName + ';Initial Catalog=SYSDB;Integrated Security=SSPI;\""'

-- create the job, also removed
-- Create the job step
EXECUTE @return_code = msdb.dbo.sp_add_job 
    @job_name = @job_name
,   @enabled = @job_enabled
,   @description = @job_description
,   @start_step_id = @job_start_step
,   @category_name = @category_name
--, @category_id = @category
,   @owner_login_name = @job_owner_login_name
,   @notify_level_eventlog = @job_notify_level_eventlog
,   @notify_level_email = @job_notify_level_email
,   @notify_level_netsend = @job_notify_level_netsend
,   @notify_level_page = @job_notify_level_page
,   @notify_email_operator_name = @job_notify_email_operator_name
,   @notify_netsend_operator_name = @job_notify_netsend_operator_name
,   @notify_page_operator_name = @job_notify_page_operator_name
,   @delete_level = @job_delete_level
,   @job_id = @job_id OUTPUT

これで、ジョブが作成された場所に関係なく、その変数が正しい場所を指すようになり、パッケージが正しいリポジトリを検出するようになり、作業が減りました。

于 2012-06-22T15:04:39.230 に答える
0

QA とステージングに 1 つの構成ファイルを使用することもできます。ファイルに両方のサーバーを含めます。

次に、パッケージを実行する QA プロセスを構築するときに、パッケージを実行する特定の環境を受け取るオプションのランタイム パラメーターを含め、パッケージの先頭で小さなスクリプト タスクを使用して適切な変数を設定します。 （または動的変数だけでも）。

完璧ではありませんが、少なくともパッケージ自体を変更することなく、さまざまな環境で実行できるようにする必要があります。

于 2012-06-22T14:43:38.427 に答える