我在Windows调度程序下配置了一个exe，用于对一组数据执行及时操作。
该exe调用存储过程来检索数据并执行一些计算并将数据更新回不同的数据库。
我想知道，使用 SSIS 包相对于预定的 exe 有什么优点和缺点。
您的意思是使用 SQL Server 代理作业来调度运行的 SSIS 包和命令 shell 执行的优点和缺点是什么？我不太了解 Windows 调度程序的优点，因此我将继续列出 SQL Server 代理作业的优点。
如果您已在服务器上使用 SQL Server 代理作业，则从代理运行 SSIS 包会将您需要监视的位置合并到一个位置。
SQL Server 代理作业具有内置的日志记录和通知功能。我不知道Windows Scheduler在这方面的表现如何。
SQL Server 代理作业不仅仅可以运行 SSIS 包。因此，您可能希望按照步骤 1 运行 T-SQL 命令，如果失败则重试，如果步骤 1 成功则最终移至步骤 2，或者如果从未满足步骤 1 的条件则停止作业并发送错误。这对于在运行 ETL 之前尝试监视另一台服务器的某些情况的 ETL 过程非常有用。
SQL Server 代理作业很容易报告，因为它们的数据存储在 msdb 数据库中。我们定期订阅 SSRS 报告，这些报告为我们提供有关工作的数据。这意味着我每天早上进入办公室之前都会收到一封电子邮件，告诉我一切是否进展顺利，或者是否有任何问题需要尽快解决。
SSRS 订阅使用 SQL Server 代理作业来进行调度。我通常需要通过调用作业计划来启动 SSRS 报告，因此我已经必须使用 SQL Server 代理作业。
SQL Server 代理作业可以链接在一起。我的 ETL 的一个常见场景是在早上按计划运行多个作业。一旦所有作业成功，就会调用另一个作业来触发多个 SQL Server 代理作业。有些作业并行运行，有些作业串行运行。
SQL Server 代理作业很容易编写脚本并加载到我们的源代码控制系统中。这使我们能够在必要时回滚到作业的早期版本。我们曾多次这样做过，特别是当有人意外删除作业时。
有一次，我们发现 Windows Scheduler 能够完成 SQL Server 代理作业无法完成的任务。在 SAN 迁移后的早期，我们有一些用于快照和克隆驱动器的脚本，这些脚本在 SQL Server 代理作业中不起作用。因此，我们使用 Windows Scheduler 任务来运行代码一段时间。大约一个月后，我们发现我们遗漏了什么，并能够将步骤移回 SQL Server 代理作业。
关于 SSIS 通过 exe 存储过程调用。
如果您所做的只是运行存储过程，那么 SSIS 可能不会为您带来太多帮助。这两种方法都有效，因此这实际上取决于 .exe 方法和 SSIS 所获得的内容之间的差异以及调用的存储过程的数量。
我更喜欢 SSIS，因为我们在团队中做了很多工作，我们必须从其他服务器下载数据、导入/导出文件，或者做一些疯狂的 https 帖子。如果我们只需要运行一组进程并且它们都是存储过程调用，那么 SSIS 可能就有点矫枉过正了。对于我的环境，SSIS 是移动数据的最佳工具，因为我们将各种类型的数据移入和移出服务器。如果您希望超越运行存储过程的范围，那么现在采用 SSIS 可能是有意义的。
如果您只是运行一些存储过程，那么您可以在没有 SSIS 的情况下通过 SQL Server 代理作业执行此操作。您甚至可以通过 msdb.dbo.sp_start_job“作业名称”使主作业启动多个作业来并行化作业。
如果您想要并行化大量存储过程调用，那么 SSIS 可能会击败链接 SQL Server 代理作业调用。虽然链接可以在代码中实现，但没有可视化界面，并且更难理解复杂的链接场景，而这些场景很容易在 SSIS 中通过序列容器和优先级约束实现。
从代码可维护性的角度来看，SSIS 胜过我团队中的任何 exe 解决方案，因为我团队中的每个人都可以理解 SSIS，而我们中很少有人能够在 SSIS 之外进行实际编码。如果您计划将其转移给下线的其他人，那么您需要确定什么对您的环境更易于维护。如果您正在构建的环境中，未来的替代者将是 .NET 程序员，而不是 SQL DBA 或商业智能专家，那么 SSIS 可能不是适合传递给未来程序员的代码库。
SSIS 为您提供开箱即用的日志记录。虽然您当然可以在代码中实现日志记录，但您可能需要将所有内容包装在 try-catch 块中，并找出一些在可执行文件之间集中日志记录的策略。使用 SSIS，您可以将日志记录集中到 SQL Server 表、将日志文件集中到某个集中文件夹中，或者使用其他日志提供程序。就我个人而言，我总是登录数据库，并且设置 SSRS 报告来帮助理解数据。我们通常根据 SQL Server 代理作业历史记录步骤详细信息对单个作业失败进行故障排除。从 SSIS 进行日志记录更多的是了解长期故障模式或监视不会导致故障的警告，例如删除未使用的数据流列（为我们提供底层源数据结构更改的早期指标）或性能指标（尽管已存储）程序在我们的系统中也有单独的登录形式）。
SSIS 为您提供视觉设计界面。我之前曾简要提到过这一点，但这是一个值得单独阐述的观点。 BIDS 是一个不错的设计界面，可以帮助您了解哪些内容按什么顺序运行。您不会通过在代码中编写 do-while 循环来得到这个。也许您有某种形式的可视化工具，但我从未使用过，但我对存储过程调用进行编码的经验总是发生在文本编辑器中，而不是在可视化设计层中。 SSIS 使得理解控制流中操作的优先级和顺序相对容易，如果您使用执行 sql 任务，控制流就是您工作的地方。
SSIS 的部署故事相当不错。我们使用 BIDS Helper（BIDS 的免费插件），因此只需右键单击解决方案资源管理器即可部署对包的更改。我们一次只需部署一个包。如果您正在编写运行所有 ETL 的主可执行文件，那么您可能必须在没有 ETL 运行时编译代码并部署它。 SSIS 包是模块化代码容器，因此如果您的服务器上有 50 个包，并且您对其中一个包进行了更改，那么您只需部署一个已更改的包。如果您将可执行文件设置为从配置文件运行代码并且不必重新编译整个应用程序，那么这可能不是一个重大胜利。
测试对单个包的更改通常可能比测试应用程序中的更改更容易。这意味着，如果您更改代码一部分中的一个 ETL 流程，您可能必须对整个应用程序进行回归测试（或单元测试）。如果更改一个 SSIS 包，通常可以通过在 BIDS 中运行它来测试它，然后在您对更改感到满意时部署它。
如果您必须通过发布流程部署所有更改，并且必须通过预发布测试流程，那么可执行方法可能会更容易。我从未找到自动对 SSIS 包进行单元测试的有效方法。我知道有一些框架和测试工具可以做到这一点，但我没有任何使用它们的经验，所以我不能谈论它们的功效或易用性。在我使用 SSIS 的所有工作中，我总是在编写更改后的几分钟或几秒钟内将更改推送到我们的生产服务器。
如果您需要我详细说明任何要点，请告诉我。祝你好运！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
