【问题标题】：Basic Approach to Diagnostic Logging in SSISSSIS 中诊断日志记录的基本方法
【发布时间】：2017-06-05 22:46:03
【问题描述】：

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

事件处理程序（特别是“OnError”）
错误输出
运营报告
SSISDB 视图
日志记录
调试转储文件

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

在我第一次尝试查找错误源时，我使用 SSMS 查看操作报告。我只看到了这个：

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

我只是想达到一个我终于可以看到有关错误的一些信息的地步。

如果答案是我首先需要在我的包中配置一个 OnError 事件，那么我的下一个问题是：该 OnError 事件的基本“转到”设计器流程是什么样的？

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

我还注意到overall strategy for success with SSIS in this answer。作者说：

检测您的代码 - 让它生成日志条目，可能会记录诊断信息，例如检查总数或计数。没有这个，故障排除几乎是不可能的。此外，断言检查是考虑错误处理的好方法（在 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 包执行日志记录级别为“无”。我必须change the logging level。

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

【问题讨论】：

不要在你的 SSIS 包中添加特殊的 OnError 处理程序。这是针对极端情况的，而且是劳动密集型的。唯一的例外是脚本任务错误，除非你在脚本中点击它们并明确写出它们，否则它永远不会给你任何有用的东西。很难说你的情况发生了什么。我刚刚查看了“所有处决”标准报告，然后单击了所有消息，它在那里向我显示了一个详细的错误。如果你的任务有错误，那是什么样的？
我从来没有费心比较表之间的行数。如果行数不匹配，则发生错误并且应该已经报告，或业务逻辑导致存在不同的计数或自行数以来源已更改被拍了。
@Nick.McDermaid 一个是“数据流”任务，另一个是sql脚本任务。
@Nick.McDermaid。轻微修正：一个“数据流”任务和一个“sql任务”。这两者是不相关的，并且在不同的 SSIS 包中找到......但两者都失败了，完全没有关于错误是什么的信息。
您在哪里找到了您描述的运营报告？试试这个：找到包（在 SSMS 的 Integration Services Catalogs 文件夹下），然后按 Reports / Standard Reports / All Executions。您应该在这里找到一个状态为“失败”的行。按所有消息链接。您应该会在此处找到您的任务以及详细的错误。请描述失败的地方。

标签： sql-server ssis ssis-2016

【解决方案1】：

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

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

原版功能无需维护。自定义功能（即用 OnError 事件填充你的包）需要更多的维护。

您可能会发现需要学习一些 SSISDB 技巧来进行故障排除的情况，但首先，请尝试从原始报告中获取所有可能的内容。

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

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

【讨论】：

我正在开发的 SSIS 包，恢复了其他开发人员开始的工作，根本没有任何日志记录提供程序。我现在已经添加了第一个也是唯一的日志记录提供程序（记录到 SQL Server），如果测试表明我终于可以看到错误信息，我会在明天发布消息。
不要被日志提供者弄糊涂了。这些在 SSIS 2012 及以后的版本中不是必需的，仅在以前的版本（SQL 2008 和更早版本）中才需要，因为在这些版本中日志记录不是“开箱即用”的。您根本不需要在 SQL 2016 中使用这些，除非您特别想记录到文件或 Windows 事件查看器或其他一些自定义日志存储库。按照我在这里的回答，任何额外的东西只会增加复杂性和维护开销。
好的，那我回到第一方。我有一个失败的“数据流”任务。我单击该任务，然后看到我的问题中显示的图像。没有任何错误信息。现在呢？
查看我的Update #2。

【解决方案2】：

补充@Nick.McDermaid 的出色回答。
我使用 SSIS 目录错误报告。在大多数情况下，它就足够了，并且具有以下错误分析功能。重点如下：

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

良好的错误分析更多的是一种方法和实践，而不仅仅是工具选择。以下是我的建议：

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

【讨论】：

我不确定您所说的“SSIS 目录错误报告”是什么意思。但是，当您说“带有错误上下文超链接的所有消息报告”时，听起来就像我打开的“所有执行”报告......其中包含您在我的问题中看到的屏幕截图。如您所见，它没有提供任何错误信息。它提供了选择“查看概述”的说明，这只会让我回到超链接列表......我选择了带有错误的超链接，并且我没有显示任何错误消息。它是对无处的循环引用。
@BrentArias，打开 All Executions 报告，然后打开失败包的 All Messages 报告。在报告标题之后，您将看到带有错误消息的 Error Messages 部分和靠近错误记录的 View Context 超链接。