通过Control-M运行SSIS包读取CSV文件失败的技术咨询

我之前碰到过几乎一模一样的场景，咱们一步步拆解问题、找解决办法：

核心问题分析 #

SQL Agent能成功但Control-M不行，说明执行SSIS包的账号上下文或环境存在差异——毕竟SQL Agent是在Windows服务器本地运行，而Control-M从Unix触发，跨系统的执行环境会带来不少坑。

排查&解决步骤 #

1. 优先检查文件路径格式 #

• 确保SSIS包中使用UNC路径（比如\\FileServer\SharedFolder\yourfile.csv），绝对不要用映射驱动器（比如Z:\yourfile.csv）。映射驱动器是会话级别的，Control-M触发的SSIS执行会话可能没有加载这个映射，直接导致找不到文件。
• 如果路径是Control-M传递的参数，注意Unix系统对反斜杠的解析：Unix里\是转义符，所以如果Control-M配置的路径是\\FileServer\...，传到Windows可能变成\FileServer\...（少了一个反斜杠）。可以试试把路径改成//FileServer/SharedFolder/yourfile.csv——Windows其实支持用正斜杠作为路径分隔符，能避开Unix的转义问题。

2. 确认执行SSIS的实际账号权限 #

你说已经给Control-M连接配置的账号加了文件权限，但要注意：Control-M配置的账号不一定是实际执行SSIS包的账号。

• 先搞清楚Control-M是怎么触发SSIS的：是通过远程调用Windows服务器上的dtexec命令？还是通过SSIS Catalog的远程执行？
• 手动用「你认为的执行账号」登录到SSIS所在的Windows服务器，直接访问文件服务器的共享文件夹，尝试打开目标CSV文件。如果这一步都失败，说明权限配置有问题（比如共享权限和NTFS权限都要设置）。
• 如果手动访问没问题，就在SSIS服务器上用该账号手动执行dtexec /f "C:\YourPackage.dtsx"命令，看能不能成功。如果手动执行成功但Control-M触发失败，说明Control-M调用时的账号上下文不对——可能是用了本地系统账号或者其他未授权的账号执行命令。

3. 排查Kerberos双跳问题 #

这是跨服务器场景的常见坑：

• SQL Agent在Windows服务器本地运行，访问文件服务器是「单跳」（本地账号直接访问）；但Control-M从Unix触发SSIS，相当于「Unix → Windows SSIS服务器 → 文件服务器」的双跳。如果Kerberos委托没配置好，SSIS服务器无法将身份传递给文件服务器，就会出现权限拒绝。
• 解决方法：在Active Directory中，给SSIS所在Windows服务器的服务账号（比如SQL Server Integration Services的运行账号）配置约束委托，允许它向文件服务器的CIFS服务进行委托。

4. 查看详细错误日志 #

别只看SSIS返回的0xC020200E错误，去SSIS所在Windows服务器的事件查看器里找更详细的日志——比如身份验证失败、权限不足的具体信息，能帮你快速定位问题。

内容的提问来源于stack exchange，提问作者Shubham Agarwal