更新

Question

在this microsoft link的帮助下，我了解了许多与SSIS诊断相关的工具：

我只是想知道什么是SSIS的（非生产）诊断设置的基本“转到”方法。我是一名开发人员，可以访问我将执行诊断的QA和UAT服务器。

在我第一次尝试找到错误来源时，我使用SSMS查看运营报告。我只看到了这一点：

我按照上面显示的说明进行操作，但它所做的只是引导我走了一圈。概述允许我查看详细信息，但详细信息显示上述消息并要求我返回概述。简而言之，除了告诉我哪个任务在SSIS包中失败之外，没有错误信息。

我只是想达到一点，我终于可以看到关于错误的一些内容。

如果答案是我首先需要在我的包中配置一个OnError事件，那么我的下一个问题是：对于那个OnError事件，基本的“转到”designer-flow会是什么样的？

仅供参考，这个问题类似于“best way of logging in SSIS”

检测您的代码 - 让它生成日志条目，可能记录诊断，例如检查总计或计数。没有这个，几乎不可能进行故障排除。此外，断言检查是一种考虑错误处理的好方法（b中的行数相等，A：B关系实际为1：1）。

听起来不错！但是我想有一个更具体的例子......特别是为了向我提供生成特定错误的基础知识。

我试图避免学习所有SSIS诊断方法，只是为了选择一个好的“全方位”方法。

根据Nick.McDermaid的建议，在SSISDB DB中我运行了这个：

SELECT * FROM [SSISDB].[catalog].[executions] ORDER BY start_time DESC

这向我展示了我手动执行的包。时间戳正确反映我运行它们的时间。如果有任何异常（？），则reference_id，reference_type和environment_name列为空。所有其他列都有值。

更新＃2

我发现了一半我正在寻找的答案。没有错误信息的原因是因为默认情况下SSIS包执行日志记录级别为“none”。我必须change the logging level。

Nick.McDermaid通过解释我不需要深入研究OnError工具或SSIS日志记录提供程序工具，给了我剩下的回答。

Answer 1

我不确定您的报告存在什么问题，但在回答“我应该学习哪种SSIS诊断”的问题时，我建议开箱即用。

换句话说，使用内置的SSIS日志记录（不需要任何其他代码）来记录失败。然后使用内置报告（一旦让它们工作）来检查这些日志。

香草功能无需维护。自定义功能（即使用OnError事件填充包）需要更多维护。

您可能会发现需要学习一些SSISDB技巧进行故障排除的情况，但在第一种情况下，尝试从vanilla报告中获取所有内容。

如果您需要维护SQL 2012或现有系统之后，则内置所有此日志记录。不保证手动OnError添加内置

唯一需要注意的是脚本任务永远不会产生信息错误。我实际上建议你避免在SSIS中使用脚本任务。我觉得如果你有使用脚本任务，你可能使用了错误的工具

Answer 2

添加@ Nick.McDermaid的优秀答案。
我使用SSIS目录错误报告。在大多数情况下，它就足够了，并具有以下功能进行错误分析。重点是：

通常，第一个或第二个错误消息包含有关错误的有意义信息。后者是数据流中出现了一些错误... 。
如果您在错误消息部分的所有消息报告中查看第一条/第二条错误消息，您将看到错误上下文超链接。调用它将在程序包崩溃时向您显示环境，连接管理器和一些变量。

良好的错误分析比单纯的工具选择更像是一种方法和实践。以下是我的建议：

SSIS喜欢报告错误代码而不是有意义的解释。所以，Integration Services Error and Message Reference是你的朋友。
SSIS包含错误上下文（见上文）转储那些Include in ErrorDump属性设置为 true 的变量。
我在变量中为SQL Task或DataFlow Source构建SQL命令。这允许在错误上下文中显示错误时执行的SQL命令，当您在这些变量的Dump属性中设置incude时。
很好地构建变量。如果某个变量仅用于某个任务 - 在此任务上声明它。否则，一堆倾销的变量会比任何好处都更伤害你。