10

我在我的 SQL Server 2005 机器上安排了 2 个计划作业，这些作业计划在每天早上（凌晨 2:00 左右）运行。这些工作（大部分）多年来一直运行良好，虽然我遇到了一些小问题，但我不得不解决这个问题，这完全让我感到难过。

前两天早上，我的一个包开始报以下错误：

Executed as user: [Service Acount]. ...n 9.00.4035.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
     Started:  1:15:01 AM  Error: 2012-10-17 01:15:03.98
     Code: 0xC0016016
     Source:
       Description: Failed to decrypt protected XML node "DTS:Password" 
       with error 0x8009000B "Key not valid for use in specified state.". 
       You may not be authorized to access this information. This error 
       occurs when there is a cryptographic error. Verify that the 
       correct key is available.  End Error  Error: 2012-10-17 01:15:03.99
     Code: 0xC0016016
     Source:
       Description: Failed to decrypt protected XML node "DTS:Password" 
       with error 0x8009000B "Key not valid for use in specified state.". 
       You may not be authorized to access this information. This error 
       occurs when there is a cryptographic error. Verify that the 
       correct key is available.  End Error  Error: 2012-10-17 01:15:04.01
     Code: 0xC0016016     
Source:       
Description: Failed to ...  The package execution fa...  The step failed.

这似乎是一个常见问题，但是，我发现的任何建议都不适用于我的场景，我的实例似乎也不匹配发生这种情况的大多数其他情况。以下是有关我的实施的重要细节。

  • 该软件包将数据从 iSeries 系统导出到 SQL Server 2005 数据表。
  • 此过程成功运行，但在一个特定的表导出时不断崩溃。事实上，它在死亡之前运行了 2 个多小时没有任何问题。检查与此步骤关联的所有属性后，我可以看到与其他表导出步骤相比，此步骤没有什么不同，除了表/列导出映射。
  • 该软件包ProtectionLevel设置为DontSaveSensitive，并且 iSeries 凭据存储在 SQL Server 访问的配置文件中。
  • 我可以在我的机器上执行失败的步骤，在 BIDS 中。无论如何，它在服务器上不起作用，尽管服务器使用完全相同的凭据。
  • 正如我所提到的，我有两个包。它们实际上是一回事，除了一个是从一个 iSeries 数据库导出数据，另一个是从另一个 iSeries DB 导出几乎完全相同结构的数据。第一个包没有任何问题，即使它使用相同的 iSeries 凭据。
  • 需要明确的是，几个月来我的服务器上没有任何变化（据我所知）。这只是昨天早上才开始发生的。

任何提示或想法都会非常有帮助。这种导出非常重要，许多用户/工作人员在日常工作中依赖这些数据。

4

6 回答 6

14

好吧，我讨厌不得不发布这样的回复，但我已经解决了这个问题。

我遇到这个问题的简短答案是因为数据表中的一个字段定义不正确。在这种情况下，它被声明为 adecimal (11, 3)并且应该是 a decimal (13, 3)。(11, 3)直到将一个值发布到不适合该范围的表中时，我才遇到此问题。

这个问题突出了我对 SSIS 最大的抱怨之一。有时我会遇到错误，这些错误通常在 Internet 上都有详细记录。我搜索了所有日志，并在错误消息是真实的假设下尝试设置各种测试场景。然而，当我最终解决问题时，它与写入日志文件的错误消息完全无关。

在这种情况下，上面提到的错误与问题完全无关？！事实上，我很幸运看到了这个问题。我知道我的桌子上的更新可能是一个潜在的修复，因为我以前见过 SSIS 像这样误传。

我想将此归咎于空间轰炸我的服务器的中微子，但从这次经历中最好的收获是尝试根据其他人的建议解决您的 SSIS 问题，但是，如果他们的建议没有帮助，请意识到该问题可能与 SSIS 错误消息无关，并三重检查与故障点相关的所有内容。

于 2012-10-18T14:16:34.477 回答
5

我无法在评论中发布图像，因此将其发布为答案。

当您尝试将包导入 SQL Server 时，只要右键单击并执行“导入包”，您将看到以下窗口。

在此处输入图像描述

单击窗口右侧的矩形框。它将为您提供更改包保护级别的选项。将其更改为“不保存敏感”并尝试运行该包。请注意，这将要求您删除现有包并再次重新导入。因此，在接触现有配置之前，您可能想在另一台机器上尝试一下。

于 2012-10-17T18:23:18.917 回答
4

对我来说，这只是 SSIS 中连接管理器的密码，没有保存。输入密码 -> 确定 -> 关闭 dtsx 文件并重新打开。错误消失了。

于 2014-01-16T12:52:25.657 回答
3

在 SQL Server 2012 中遇到相同的错误消息。对我来说，重新启动 SQL Server Management Studio 解决了这个问题。问题可能是由于几天前我的域密码在 SSMS 打开时更改造成的。如果您遇到类似的问题并且简单的重启并没有消失，请确保检查Control Panel\User Accounts\Credential Manager缓存的帐户信息和/或尝试重启。

于 2015-10-07T17:25:06.627 回答
1

打开包 dtsx 然后转到属性集 ProtectionLevel EncryptSensitiveWithPassword 并输入密码。使用相同的密码连接打包形式的 sql server 作业。

请参阅http://support.microsoft.com/kb/918760和http://www.mssqltips.com/sqlservertip/2091/securing-your-ssis-packages-using-package-protection-level/

于 2015-03-04T19:47:45.873 回答
0

这是一种解决方法，可以首先避免在包中保存敏感密码的问题。

我删除了 FTP 任务并使用文件系统任务通过 ftp 服务器上的网络共享将文件复制到同一位置，并避免使用 ftp 协议。

我还能够将包保存到文件系统而不是 sql 服务器存储中，并且运行良好。

希望它可以帮助你！

于 2014-11-05T17:30:30.360 回答