您是说使用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 over 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的所有工作中,我总是在编写更改的几分钟或几秒内将更改推送到生产服务器.
如果您需要我详细说明任何要点,请告诉我.祝好运！
