2

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

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

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

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

在此处输入图像描述

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

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

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

仅供参考，这个问题类似于“登录 SSIS 的最佳方式”

在这个答案中，我还注意到 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 包执行日志记录级别为“无”。我不得不更改日志记录级别。

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

4

2 回答 2

1

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

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

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

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

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

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

于 2017-06-06T05:22:25.000 回答
0

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

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

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

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