SSIS 最佳实践 - 做 2 件事情中的 1 件

Question

我有一个正在处理队列的 SSIS 包。 我目前有一个单独的包裹，分为 3 个容器 1.收集一些元数据 2.做作业 3. 重新检查元数据，根据我们认为发生的情况更新队列（成功或失败）

我对速度不是很满意，部分原因是我在仓鼠驱动的服务器上运行，但这是我无法控制的。

中间部分可能提供改进的机会...... 有 20 个表可能需要更新。 每个队列项目将更新 1 个表。 我目前有一个包含 20 个序列容器的序列。

它们基本上都做同样的事情，但我想不出一种方法来抽象它们。

每个中的第一个框是一个空的脚本动作。如果表名匹配，则有条件流向“胆量”。

所以我打开了 20 个序列任务、20 个空脚本任务并进行了 20 个 T/F 检查。

观看黄/绿灯表演，这似乎很慢。

有没有更有效的方法？我认为让它变得更好的唯一方法是将 20 个空脚本放在序列容器之外。可以节省的是打开容器。我不敢相信打开一个序列容器会那么贵。它是否可能每次都重新验证容器中的每个任务？

只是钓鱼，如果有人有任何想法，我会很高兴听到他们的意见。

谢谢

格雷格

Answer 1

您现在的主要问题是您在 BIDS 中运行它。这是为了使包的开发和调试变得容易，所以对你来说是的，它会在运行时验证所有对象。此外，“黄/绿灯秀”的开销更大，可以向您展示包运行时发生的情况。当您使用 DTSExec 或作为 Sql server 的计划任务的一部分运行它时，您将获得更好的性能。你在记录你的包裹吗？如果是这样，请从服务器运行并查看日志以验证该过程在服务器上实际花费的时间。如果此时仍然需要太长时间，那么您可以实现 @registered user 的一些想法。

Answer 2

您是否并行运行每个任务？如果它必须连续循环遍历所有 60 个对象，那么您的主要改进空间是并行运行每个对象。如果您正在尝试并行化流程，那么您可以采取一些解决方案：

1. 创建所有 60 个对象，每个链包含 3 个对象。这是设置劳动密集型的，但它是最容易排除故障的，并且允许您在必要时对其进行自定义。显然这并没有抽象出任何东西！

2. 创建一个父包和一个子包。子包将包含您要执行的结构。父包包含 20 个执行包任务。这类似于 1，但它提供的优势是您只需为 3 任务序列容器维护一组代码。这可能意味着您将转向表驱动的元数据模型。如果您要将数据从一台服务器传输到另一台服务器，这在 SSIS 中与 CozyRoc Data Flow Plus 任务配合得很好。如果您在同一台服务器上执行所有操作，那么您很可能正在组织存储过程执行，这很容易使用此模型完成。

3. 创建一个使用 CozyRoc Parallel Task 和 Data Flow Plus 的包。这可以让您将所有逻辑封装在一个包中并并行执行所有逻辑。 警告 我在 SQL Server 2008 R2 中尝试了这种方法并取得了巨大成功。但是，当 SQL Server 2012 发布时，CozyRoc 并行任务的行为与我在以前版本中的行为方式不同，因为 SSIS 中的一些隐藏更改。我将此记录为 CozyRoc 的错误，但据我所知，此问题尚未解决（截至 2013 年 4 月 1 日）。此外，此模型可能会抽象出过多的 ETL，并使将来的初始加载和对单个表加载进行故障排除变得更加困难。

就个人而言，我使用解决方案 1，因为我的任何团队成员都可以成功实现此代码。元数据驱动的解决方案很有吸引力，但更难正确编码。

Answer 3

我可以建议将您的 20 个更新包装在一个存储过程中。不知道你的输入数据有多大的可变性，我不知道这有多合适，但这是我的第一反应。

Answer 4

嗯 - 这就是我所做的......

我在父序列容器的“顶部”添加了一个虚拟任务。从中，我为每个子序列容器 (CSC) 添加了 20 个流链接。现在每个 CSC 仅在必要时才打开。

我的吞吐量确实增加了大约 30%（26 rpm--> 34 rpm 最小采样）。

我可以使用 zmans 回答或注册用户。两者都很有帮助。我选择 zmans 是因为真正的答案总是从查看日志开始，以确切了解某件事需要多长时间（根据我的经验，绿色/黄色并不真正可靠）。

谢谢