SSIS パッケージが SQL Server 2012 で 32 ビットとして実行されない

デフォルトでは、すべてがサーバー上で 64 ビットで実行されます。この動作を変更するには、32 ビットバージョンの dtexec 使用すべきです。 2012 SSISDB では、パッケージを呼び出す簡単な方法が 2 つあります。SQL エージェントと catalog.start_execution です。方法。

catalog.start_execution

単一サービングパッケージの実行の場合、SSISDB カタログでパッケージを見つけて、それらを右クリックして Execute... できます。

表示されるポップアップダイアログで、[詳細設定] タブに移動し、32-bit runtime を確認する必要があります。箱。これは、パッケージの実行ごとに行われます。

バックグラウンドでは、ウィザードが生成する SQL は次のようになります

DECLARE @execution_id bigint
EXEC [SSISDB].[catalog].[create_execution]
    @package_name = N'Package.dtsx'
,   @execution_id = @execution_id OUTPUT
,   @folder_name = N'POC'
,   @project_name = N'SSISConfigMixAndMatch'
,   @use32bitruntime = True
,   @reference_id = NULL
SELECT
    @execution_id
DECLARE @var0 smallint = 1
EXEC [SSISDB].[catalog].[set_execution_parameter_value]
    @execution_id
,   @object_type = 50
,   @parameter_name = N'LOGGING_LEVEL'
,   @parameter_value = @var0
EXEC [SSISDB].[catalog].[start_execution]
    @execution_id
GO

ご覧のとおり、@use32bitruntime パラメータには True の値が渡され、32 スペースで実行する必要があることを示します。

SQL エージェント

定期的なパッケージの実行には、通常、スケジュールツールを使用します。エージェントでパッケージの 32 ビット設定にアクセスするには、基本的に同じクリックパスを使用しますが、最初に [構成] タブをクリックし、次にをクリックする必要があります。 [詳細] タブをクリックして、32-bit runtime を選択します。

ジョブステップの定義は次のようになります

EXEC msdb.dbo.sp_add_jobstep
    @job_name = N'Do it'
,   @step_name = N'Run in 32bit'
,   @step_id = 1
,   @cmdexec_success_code = 0
,   @on_success_action = 1
,   @on_fail_action = 2
,   @retry_attempts = 0
,   @retry_interval = 0
,   @os_run_priority = 0
,   @subsystem = N'SSIS'
,   @command = N'/ISSERVER "\"\SSISDB\POC\SSISConfigMixAndMatch\Package.dtsx\"" /SERVER "\".\dev2014\"" /X86 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E'
,   @database_name = N'master'
,   @flags = 0

@command 呼び出しで、ウィザードが /X86 を生成することがわかります。 dtexec の 32 ビットバージョンと 64 ビットバージョンのどちらを使用する必要があるかを示すために、SQL エージェント用に予約されている特別な引数である呼び出し (最初の BOL リンクを確認してください)。コマンドライン呼び出しでは、正しい dtexec を明示的に使用する必要があります。デフォルトでは、64 ビットの dtexec が PATH 環境の最初にリストされます

64 ビット dtexec の場所

C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe

32 ビット dtexec の場所

C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe

ドライバーのさらなるトラブルシューティング

あるサーバーでは実行されますが、別のサーバーでは実行されません。

ステップ 1 - ドライバーがインストールされていることを確認します。愚かなことは明らかですが、SSIS パッケージ/.ispac をデプロイすると、参照されているすべてのアセンブリもデプロイされると誤解されているという疑問が数多くありました。これは nuget ではないので、すべての前提条件をインストールし、適切にインストールする必要があります (ツールを使用する代わりに、アセンブリを GAC にコピーしようとする人が見られます)

ステップ 2 - ドライバーのインストールがサーバー全体で一致していることを確認します。繰り返しますが、明らかなように思えますが、一般的に VS_NEEDSNEWMETADATA という痛みを経験しました。ドライバーバージョン 4.0.2.013 の点の違いで、4.0.2.014 とは異なる結果が生成されました。

ステップ 3 - 定義した DSN が正しいスペースで定義されていることを確認します。これは、いくつかの理由で人々を噛みます。サーバー 2012 までは、32 ビットバージョンの odbcad32.exe (管理ツール -> データソース (ODBC) に関連する実行可能ファイル) をファイルシステム上で見つけることしかできなかったと思います。さらに紛らわしいのは、System32 にあるか SysWOW64 にあるかに関係なく、実行可能ファイルの名前が odbcad32.exe であり、これら 2 つのフォルダーがそれぞれ 64 ビットドライバーと 32 ビットドライバー用であることです。はい、将来の読者の皆さん、それはタイプミスではありません。アプリケーションの 64 バージョンは System32 にあり、32 ビットバージョンは SysWOW64 にあります。これは、影響を最小限に抑えることを目的とした設計上の決定でした。

テストサーバーとライブサーバーで、C:\Windows\SysWOW64\odbcad32.exe を実行します。 FoxPro ドライバーと関連する DSN を見つけてください。期待どおりですか?

ステップ 4 - 奇妙なパーミッションチェック。「通常の」アカウントとして両方のサーバーにログオンし、コマンドラインからパッケージを実行します。この手順を繰り返しますが、エージェントを使用して実行します。プロキシは、定義したかどうかに関係なく、任意です。前者は機能するが後者が失敗する場合、通常は権限の問題を示しています。 SQL Server またはエージェントアカウントが、ドライバーがインストールされたフォルダーにアクセスできない可能性があります。そのアカウントには、InteractWithDesktop アクセス許可、または拒否された、または明示的に付与されていないその他のアクセス許可が必要である可能性があります。