|
|
1
Registered User
16 年前
-
如果您已经在服务器上使用SQL Server代理作业,则从代理运行SSIS包会将需要监视的位置合并到一个位置。
-
SQLServer代理作业具有内置的日志记录和通知功能。我不知道Windows调度程序在这方面的性能如何。
-
SQLServer代理作业可以运行的不仅仅是SSIS包。因此,您可能希望在步骤1中运行T-SQL命令,如果失败,请重试,如果步骤1成功,则最终转到步骤2,或者如果从未满足步骤1条件,则停止作业并发送错误。这对于在运行ETL之前试图监视另一台服务器的某些状况的ETL过程非常有用。
-
SQL Server代理作业很容易报告,因为它们的数据存储在msdb数据库中。我们定期订阅SSRS报告,为我们提供有关工作的数据。这意味着我可以在每天早上进办公室之前收到一封电子邮件,告诉我是否一切顺利,或者是否有任何问题需要尽快解决。
-
SQL Server代理作业由SSRS订阅用于调度目的。我通常需要通过调用SSRS报告的作业计划来启动它们,因此我已经需要处理sqlserver代理作业了。
-
-
SQLServer代理作业很容易编写脚本并加载到我们的源代码管理系统中。这允许我们在必要时回滚到作业的早期版本。我们已经在一些场合这样做了,特别是当有人意外删除了一个工作。
在一次会话中,我们发现了一种情况,在这种情况下,Windows调度程序可以执行SQL Server代理作业无法执行的操作。在SAN迁移后的早期,我们有一些用于快照和克隆驱动器的脚本,这些脚本在SQL Server代理作业中不起作用。因此,我们使用Windows调度程序任务来运行代码一段时间。大约一个月后,我们发现缺少了什么,并能够将步骤移回SQLServer代理作业。
关于SSIS over exe存储过程调用。
-
-
我更喜欢SSIS,因为在我的团队中,我们需要从其他服务器下载数据、导入/导出文件,或者发布一些疯狂的https帖子。如果我们只需要运行一组进程,而这些进程都是存储过程调用,那么SSIS可能已经被过度杀戮了。对于我的环境,SSIS是移动数据的最佳工具,因为我们在服务器之间移动各种类型的数据。如果您希望超越运行存储过程,那么现在采用SSIS可能是有意义的。
-
如果您只是在运行一些存储过程,那么您可以在没有SSIS的情况下从SQL Server代理作业中轻松完成这项工作。您甚至可以通过使主作业通过msdb.dbo.sp\u启动\u作业'作业名称'。
-
-
从代码可维护性的角度来看,SSIS胜过我的团队的任何exe解决方案,因为我的团队中的每个人都能理解SSIS,而我们中很少有人能真正在SSIS之外编写代码。如果您计划将其传输给其他人,那么您需要确定什么对您的环境更具可维护性。如果您正在构建的环境中,您未来的替代者将是.NET程序员,而不是SQL DBA或商业智能专家,那么SSIS可能不是传递给未来程序员的合适代码库。
-
SSIS提供了现成的日志记录。尽管您当然可以实现登录代码,但您可能需要将所有内容封装在try-catch块中,并找出一些策略来集中可执行文件之间的日志记录。使用SSIS,您可以将日志集中到SQL Server表,将文件记录在某个集中的文件夹中,或者使用另一个日志提供程序。就我个人而言,我总是登录到数据库,并且我有SSRS报告设置来帮助理解数据。我们通常根据SQLServer代理作业历史记录步骤的详细信息来解决单个作业故障。从SSIS记录更多的是了解长期故障模式或监视不会导致故障的警告,例如删除未使用的数据流列(对我们来说是底层源数据结构更改的早期指标)或性能指标(尽管存储过程在我们的日志中也有单独的记录形式)系统)。
-
-
SSIS的部署情况相当不错。我们使用BIDS-Helper(一个免费的BIDS插件),所以只需在解决方案资源管理器上单击鼠标右键就可以将更改部署到包中。我们一次只需要部署一个包。如果您正在编写一个运行所有ETL的主可执行文件,那么您可能必须编译代码,并在没有任何ETL运行时部署它。SSIS包是模块化的代码容器,因此如果您的服务器上有50个包,并且您在一个包中进行了更改,那么您只需要部署一个更改的包。如果您将可执行文件设置为从配置文件运行代码,并且不必重新编译整个应用程序,那么这可能不是一个重大的胜利。
-
测试单个包的更改通常比测试应用程序中的更改容易。也就是说,如果您在代码的某个部分更改了一个ETL进程,那么您可能需要对整个应用程序进行回归测试(或单元测试)。如果您更改了一个SSIS包,通常可以通过在BIDS中运行它来测试它,然后在您对更改感到满意时部署它。
-
如果你需要我详细说明什么,请告诉我。祝你好运!
|
