SQL Server 代理执行 SSIS 包失败的排查与修复方案

故障根源分析

当作业日志仅返回“以 xxxx 用户身份执行失败”而无详细堆栈时，通常意味着底层操作系统层面的调用被阻断，或者应用程序层的凭据验证未通过。SSIS 包在执行时需要访问文件系统或连接数据库，如果 SQL Server 服务账户没有相应权限，或者 SSIS 包加密方式导致非交互账户无法解密，都会导致静默失败。

第一步：启用 xp_cmdshell 支持

xp_cmdshell 允许 SQL Server 调用操作系统命令行，是许多自动化任务（包括某些 SSIS 执行方式）的基础。默认情况下它处于禁用状态以提升安全性。

操作入口： SQL Server Management Studio (SSMS) → 新建查询窗口。

操作步骤：

1. 显示高级选项： 运行以下脚本以允许更改高级服务器配置。

-- 允许更改高级选项
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

2. 启用 xp_cmdshell： 激活该功能并更新配置。

-- 启用 xp_cmdshell 特性
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

-- 完整检查代码
EXEC sp_configure 'show advanced options', 1 GO
RECONFIGURE GO
EXEC sp_configure 'xp_cmdshell', 1 GO
RECONFIGURE GO

完成判断： 执行后无报错即表示成功。注意生产环境中请评估安全风险评估后再开启此功能。

第二步：修正 SSIS 包的保护级别

如果在通过工具导入或执行时报错“无法解密受保护的 XML 节点”，说明包设置了需要特定密钥或用户凭据才能打开的保护模式。对于自动化代理执行，推荐使用依靠角色控制的模式。

操作入口： Business Intelligence Development Studio (BIDS/VS) 或 SSMS 的 Integration Services。

操作步骤：

• 在开发环境中： 打开 SSIS 包属性，将 ProtectionLevel 修改为