【问题标题】：SSIS Package Not Running as 32bit in SQL Server 2012SSIS 包在 SQL Server 2012 中未作为 32 位运行
【发布时间】：2015-04-03 10:01:32
【问题描述】：

我有一个在 VS2012 中开发的包（使用 SQL Data Tools 组件），它使用 VFPOLEDB 提供程序从 DBF 文件中收集数据，并将其放入 SQL Server 2012 X64 服务器上的数据库中。包含该包的项目将 Run64BitRuntime 的 DebugOption 设置为 false。我已将此包导入测试和实时服务器的 SSIS 包存储（相同的设置）。两台机器上都安装了 VFPOLEDB 提供程序，我可以在两台机器的注册表中看到它用于 32 位运行时。

包在测试机器上运行良好，但在现场机器上失败。 SQL 的实时实例似乎无法识别已安装的 32 位 VFPOLEDB 提供程序。

SQL 实例的唯一区别是实时环境设置了集成服务目录，而测试没有设置。查看服务器的日志，当live启动时，它运行sp_ssis_startup，然后记录有关正在加载的不安全程序集的消息。这个SP没有在测试环境中运行，因为没有目录。

我创建的作业将标志设置为使用 32 位运行时，但我不禁觉得 SSIS 目录与我正在使用的 VFPOLEDB 存在问题，并且没有加载它。

我真的对 SSIS 目录一无所知，所以有人能建议我前进的方向吗？

更新：这是我的工作步骤配置。设置了 32 位运行时标志。

更新 #2：

OLEDB 提供程序已正确安装。
两台机器上都安装了相同版本的提供程序。
OBDCAD32.exe 显示相同版本的 VFPOLEDB 提供程序。两台机器上都没有定义 DSN。我的本地机器确实定义了 DSN，所以我会尝试为 dBASE 文件添加一个，看看是否有帮助。
现在正在尝试此步骤。我正在寻找一种无需创建 SSISDB 目录即可使用 dtexec 工具的方法。尽管我确实删除了现有的 SSIS 目录并停止了在服务启动时执行 sp_ssis_startup。我没有看到有关不安全程序集的日志条目，但该作业仍然失败，并出现与往常一样的错误。我将报告 4 并可能进一步寻求进一步的指导。

更新 #3：
我刚刚检查过，测试和实际环境与我最初所说的不同。实时服务器没有 dtexec.exe 的 32 位版本（尽管我认为这并不重要，因为 TechNet 说使用 SQL Server 代理运行的作业将始终使用 64 位版本。我想我使用的是 x86 和 i64 ISO 来设置测试环境，但只有 64 位版本的 live 版本。我想改变它需要从 live box 中卸载 Integration Services 共享组件并使用双 iso 重新安装它。

我猜设置“使用 32 位运行时”选项只有在使用 32 位版本时才有效？这或许可以解释一些事情。

【问题讨论】：

发布您的工作步骤定义。如果您已指示作业步骤应使用 32 位版本，则将调用 dtexec
啊啊啊啊，我看到了 SQL Server 2012 标记，假设您使用的是项目部署模型，因此，您的包已部署到 SSISDB。如果我更仔细地查看您的 SQL 代理图片，那应该很明显。或阅读理解“SSIS Package Store”Mea culpa

标签： ssis sql-server-2012 oledbconnection visual-foxpro ssis-2012

【解决方案1】：

默认情况下，一切都将在服务器上以 64 位运行。要更改此行为，您需要指明应该使用 32 位版本的 dtexec。对于 2012 SSISDB，我们有两种简单的方法来调用我们的包：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 调用，这是为 SQL 代理保留的特殊参数（检查开头的 BOL 链接），以指示 32 位还是 64 位版本应该使用 dtexec。命令行调用将要求我们显式使用正确的 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 都在正确的空间中定义。这个咬人的原因有很多。我认为直到 Server 2012 才可以通过在文件系统上找到 odbcad32.exe（与管理工具相关的可执行文件 -> 数据源 (ODBC) 相关的可执行文件）来获得 32 位版本。更令人困惑的是，可执行文件名为 odbcad32.exe，无论它是在 System32 还是 SysWOW64 中，这两个文件夹分别用于 64 位驱动程序和 32 位驱动程序。是的，未来的读者，这不是一个错字。 64位版本的应用在System32，32位的版本在SysWOW64。这是一个旨在尽量减少影响的设计决策。

在测试和正式服务器上，运行C:\Windows\SysWOW64\odbcad32.exe 找到您的 FoxPro 驱动程序和相关的 DSN，它们是否符合预期？

第 4 步 - 奇怪的权限检查。以“普通”帐户登录到两台服务器并从命令行运行包。重复此步骤，但使用代理执行它，使用您可能定义或未定义的任何代理。如果第一个有效但后者失败，这通常表明存在权限问题。可能是 SQL Server 或代理帐户无法访问驱动程序安装到的任何文件夹。可能是该帐户需要 InteractWithDesktop 权限或其他一些被拒绝或未明确授予的权限。

【讨论】：

我很欣赏详尽的解释。我在最初的问题中确实声明了 32 位运行时标志被用于确保可以使用 32 位程序集。
@AdamH 完美，那么除非您正在使用外部进程调用从同一个包中启动另一个包，否则“bittedness”没有机会从 32 位更改回 64 位.添加了更多检查以识别并希望解决您的问题
我添加了更新 #2 以响应您的 4 个步骤。
我添加了更新 #3，其中包含第 4 步帮助我识别的内容。它可能是什么，也可能什么都不是。你对此有意见吗？我仍在努力以不同权限级别的用户从命令行运行它。
我安装了 SQL Data Tools 组件，因此有一个 32 位版本的 dtexec.exe 可以运行（我假设这是它试图对执行选项标志集进行的操作）并且它运行良好。我猜在没有 32 位的情况下，它最终会使用它拥有的唯一版本 64 位来运行它。感谢您的指导和帮助。

【解决方案2】：

如果要在 32 位模式下从 64 位 SQL Server 代理作业运行包，请选择作业步骤类型 o-->操作系统，然后输入命令行或使用调用32 位版本的 dtexec.exe

命令：CD "C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\" DTExec.exe /f "C:\Download\Root\SQL Package.dtsx"

或命令： "C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe" /FILE "C:\Download\Root\SQL Package.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING V /CONSOLELOG NCOSGXMT

注意：我使用的是 SQL 2014 64 位版本。

【讨论】：