SSIS包相对于windows预定exe的优势

Question

我在windows scheduler下配置了一个exe，可以对一组数据进行及时的操作。

exe 调用存储过程来检索数据并执行一些计算并将数据更新回不同的数据库。

我想知道，使用 SSIS 包而不是预定的 exe 有什么优点和缺点。

Answer 1

您的意思是使用 SQL Server 代理作业来安排正在运行的 SSIS 包和命令 shell 执行的优缺点是什么？我不是很了解windows scheduler 的优点，所以我会坚持列出SQL Server Agent Jobs 的优点。

1. 如果您已经在服务器上使用 SQL Server 代理作业，则从代理运行 SSIS 包会将您需要监控的位置合并到一个位置。

2. SQL Server 代理作业具有内置的日志记录和通知功能。我不知道 Windows Scheduler 在这方面的表现如何。

3. SQL Server 代理作业不仅可以运行 SSIS 包。因此，您可能希望将 T-SQL 命令作为第 1 步运行，如果失败则重试，如果第 1 步成功则最终移动到第 2 步，或者如果第 1 步条件从未满足，则停止作业并发送错误。这对于在运行 ETL 之前尝试监控另一台服务器的某些情况的 ETL 流程非常有用。

4. SQL Server 代理作业易于报告，因为它们的数据存储在 msdb 数据库中。我们定期订阅 SSRS 报告，为我们提供有关我们工作的数据。这意味着我每天早上进入办公室之前都会收到一封电子邮件，告诉我一切是否顺利，或者是否有任何问题需要尽快解决。

5. SSRS 订阅将 SQL Server 代理作业用于调度目的。我通常需要通过调用其作业计划来启动 SSRS 报告，因此我已经必须使用 SQL Server 代理作业。

6. SQL Server 代理作业可以链接在一起。我的 ETL 的一个常见场景是在早上按计划运行多个作业。所有作业成功后，将调用另一个作业来触发多个 SQL Server 代理作业。有些作业并行运行，有些作业串行运行。

7. SQL Server 代理作业很容易编写脚本并加载到我们的源代码控制系统中。这允许我们在必要时回滚到早期版本的作业。我们曾在少数情况下这样做过，尤其是当有人意外删除工作时。

在一次情况下，我们发现 Windows 调度程序能够执行我们无法使用 SQL Server 代理作业执行的操作。在 SAN 迁移后的早期，我们有一些用于快照和克隆驱动器的脚本，这些脚本在 SQL Server 代理作业中不起作用。所以我们使用了一个 Windows Scheduler 任务来运行代码一段时间。大约一个月后，我们弄清楚了我们缺少什么，并且能够将步骤移回 SQL Server 代理作业。

关于 SSIS over exe 存储过程调用。

1. 如果您所做的只是运行存储过程，那么 SSIS 可能不会为您增加太多。这两种方法都有效，因此它实际上归结为您从 .exe 方法和 SSIS 获得的结果之间的差异，以及被调用的存储过程的数量。

2. 我更喜欢 SSIS，因为我们在团队中做了很多工作，我们必须从其他服务器下载数据、导入/导出文件，或者做一些疯狂的 https 帖子。如果我们只需要运行一组进程并且它们都是存储过程调用，那么 SSIS 可能已经过大了。对于我的环境，SSIS 是移动数据的最佳工具，因为我们将各种类型的数据移入和移出服务器。如果您希望超越运行存储过程，那么现在采用 SSIS 可能是有意义的。

3. 如果您只是运行一些存储过程，那么您可以在没有 SSIS 的情况下通过 SQL Server 代理作业执行此操作。您甚至可以通过 msdb.dbo.sp_start_job 'Job Name' 让主作业启动多个作业来并行化作业。

4. 如果您想并行处理大量存储过程调用，那么 SSIS 可能会胜过链接 SQL Server 代理作业调用。尽管在代码中可以进行链接，但没有可视表面，并且很难理解在具有序列容器和优先约束的 SSIS 中易于实现的复杂链接场景。

5. 从代码可维护性的角度来看，SSIS 胜过我团队的任何 exe 解决方案，因为我团队中的每个人都能理解 SSIS，而我们中很少有人能够真正在 SSIS 之外编写代码。如果您打算将其转移给下线的某个人，那么您需要确定什么对您的环境更易于维护。如果您在未来的替代者将是 .NET 程序员而不是 SQL DBA 或商业智能专家的环境中构建，那么 SSIS 可能不适合传递给未来的程序员。

6. SSIS 为您提供开箱即用的日志记录。尽管您当然可以在代码中实现日志记录，但您可能需要将所有内容包装在 try-catch 块中，并找出一些在可执行文件之间集中日志记录的策略。使用 SSIS，您可以将日志集中到 SQL Server 表中，将文件记录在某个集中的文件夹中，或者使用另一个日志提供程序。就个人而言，我总是登录到数据库并设置 SSRS 报告以帮助理解数据。我们通常根据 SQL Server 代理作业历史记录步骤详细信息对单个作业失败进行故障排除。从 SSIS 进行日志记录更多的是关于了解长期故障模式或监视不会导致故障的警告，例如删除未使用的数据流列（我们的基础源数据结构更改的早期指标）或性能指标（尽管存储程序在我们的系统中也有单独的登录形式）。

7. SSIS 为您提供可视化设计界面。我之前简要地提到过这一点，但这是值得单独扩展的一点。 BIDS 是一个不错的设计界面，用于了解以什么顺序运行的内容。你不会通过在代码中编写 do-while 循环来得到这个。也许您有某种我从未使用过的可视化工具，但我编写存储过程调用的经验总是发生在文本编辑器中，而不是可视化设计层中。 SSIS 可以相对容易地理解控制流中操作的优先级和顺序，如果您使用执行 sql 任务，您将在其中工作。

8. SSIS 的部署故事相当不错。我们使用 BIDS Helper（一个免费的 BIDS 插件），因此只需在解决方案资源管理器上单击鼠标右键即可对包进行更改。我们一次只需要部署一个包。如果您正在编写一个运行所有 ETL 的主可执行文件，那么您可能必须编译代码并在没有任何 ETL 运行时部署它。 SSIS 包是模块化代码容器，因此如果您的服务器上有 50 个包并且您在一个包中进行了更改，那么您只需部署一个更改的包。如果您将可执行文件设置为从配置文件运行代码并且不必重新编译整个应用程序，那么这可能不是一个重大胜利。

9. 测试单个包的更改通常可能比测试应用程序的更改更容易。这意味着，如果您在代码的一部分中更改一个 ETL 流程，您可能必须对整个应用程序进行回归测试（或单元测试）。如果您更改了一个 SSIS 包，您通常可以通过在 BIDS 中运行它来测试它，然后在您对更改感到满意时部署它。

10. 如果您必须通过发布流程部署所有更改并且必须通过发布前测试流程，那么可执行方法可能更容易。我从来没有找到一种有效的方法来自动对 SSIS 包进行单元测试。我知道有框架和测试工具可以做到这一点，但我对它们没有任何经验，所以我不能说它的功效或易用性。在我与 SSIS 的所有工作中，我总是在编写更改后的几分钟或几秒钟内将更改推送到我们的生产服务器。

如果您需要我详细说明任何要点，请告诉我。祝你好运！

Answer 2

如果您依赖于 Windows 功能，例如日志记录、事件、访问 Windows 资源，请转到 Windows 调度程序/Windows 服务路由。如果只是 db 到 db 的移动，或者如果您需要某种繁重的 db 函数使用，请转到 SSIS 路由。