![我们的环境](https://linux22.com/image/580644/%E6%88%91%E4%BB%AC%E7%9A%84%E7%8E%AF%E5%A2%83.png)
我在 SQL 服务器 (SQL Server 2012) 上安装了一个 SSIS 包。它相当简单,只需从远程数据源获取数据并将其添加到本地表中。远程连接字符串使用 SQL 服务器身份验证,而本地连接使用 Windows 身份验证。远程连接密码受到保护,并且包已导入,保护级别设置为依靠服务器存储和角色进行访问控制。
如果我手动运行 SSIS 包,它会起作用。如果我使用 从命令行运行它dtexec
,它会起作用。如果我使用runas
切换到 SQL 服务器代理正在运行的域帐户,然后使用 运行包dtexec
,它会起作用。如果我创建一个 SQL 代理作业,只需一步即可运行包,它会失败,并且几乎不会提供有关正在发生的事情的详细信息。我猜它无法获取登录远程 SQL 服务器的密码,因为它失败得非常快。此外,如果我勾选“记录到表”并查看结果文件,我会得到以下内容:
Description: ADO NET Source has failed to acquire the connection {0D8F2CD4-A763-4AEB-8B52-B8FAE0621ED3} with the following error message: "Login failed for user 'username'.".
如果我尝试在作业步骤对话框中手动在连接字符串中添加密码data sources
,它会拒绝保存它,似乎总是删除连接字符串的“密码”位。
我认为 SQL Server 代理作业始终在 SQL Server 代理所运行的帐户上下文中运行。此帐户位于sysadmin
本地 SQL Server 上,并且包在该帐户下运行dtexec
,那么为什么在尝试作为代理作业运行时会失败?
答案1
我也遇到了同样的问题。经过一番研究并说服我无法控制的服务器将 Windows 身份验证帐户添加到其位置,并从以下 URL 获得一些见解后,我让它正常工作了:
我们的环境
- SQL Server 2012 托管集成服务目录,它汇集了来自不同域的各种 SQL Server 版本的数据。
- 两个互相信任的域
- 域A
- 域 A 中的 SSIS 目录,域 A 上运行 SSIS 包的 SQL Server 代理作业。
- 域 B
- SSIS 包使用 SSIS 包中设置的 Windows 身份验证连接从域 B 上的数据库提取数据。该包运行良好。
- 属于域 B 的一个服务帐户可以访问所有相关的数据源。
- 域A
解决方案
这让我了解了它们在 SQL Server 代理作业中的运行方式差异。考虑到我的 SSIS 包正在访问不同域上的远程服务器,并且我的错误与步骤中的“以身份运行”用户帐户有关,我决定创建另一个“以身份运行”帐户。这也称为代理(SQL Server 代理 > 代理 > SSIS 包执行)。
在创建代理之前,我必须设置一个凭证。以下是为我解决此问题的步骤:
所有步骤均假定您的 SSIS 包已加载到 Integration Services 目录中,并且已创建 SQL Server 代理作业,并且已从 SSIS 目录(包源)运行该包。
- 创建凭证(安全 > 凭证)。使用凭证中的身份作为上面提到的服务帐户。
- 创建 SSIS 包执行代理(SQL Server 代理 > 代理 > SSIS 包执行)。为了帮助理解所有内容,我给它取了与服务帐户相同的名称。
- 转到 SQL Server 代理作业,然后执行步骤。将 SQL Server 代理服务帐户的运行身份更改为您新创建的代理帐户。按 OK 和 OK。
- 运行作业进行测试。
这对我们的情况有用,并允许我们的 SSIS 包按计划运行并跨域遍历到不同的 SQL Server 框并提取数据。
答案2
如果您可以使用 Windows 身份验证而不是 SQL 身份验证,通常会更容易使这些工作正常进行。