Sql server 计划执行代码以在SQL Server中执行数据库操作

如果我想按计划执行一些数据库操作，我可以：

• 使用SQL Server代理（如果是SQL Server）定期调用存储过程和/或执行T-SQL

• 运行一些执行数据库操作的外部进程（例如，由操作系统的任务调度器调度）

• 等等

两个问题：

实现这一点的其他方法是什么

应该使用什么决策标准来决定最佳方法

---

谢谢。

另一种可能是在某处有一个任务队列，当使用数据库的应用程序执行某些操作时，它们也会在队列外执行一些任务。Wikipedia的作业队列就是这样。日程安排不像其他方法那样确定，但当服务器负载过重时，您可以推迟执行内务管理工作

编辑： 它不一定比其他技术更好或更差。它适用于不必在任何特定截止日期前完成的任务，但应该“不时”完成，或者“很快，但不一定是现在”

优势

• 您不需要编写单独的应用程序或设置SQL Server代理
• 您可以使用您可以编程的任何条件来决定是否运行任务：立即、一旦某个时间过去，或者仅当服务器未处于重载状态时
• 如果计划的任务是优化索引之类的任务，那么您可以在不太必要时（例如更新很少时）减少执行这些任务的频率，而在更新很常见时更频繁地执行这些任务

缺点

• 您可能需要修改多个应用程序才能正确协作
• 您需要确保队列不会堆积太多
• 您无法可靠地确保任务在特定时间之前运行
• 您可能有很长一段时间没有收到任何请求（例如，在夜间），延迟/计划的任务可以完成，但没有。你可以把它和其他的想法结合起来，用一个特殊的程序只做队列中的工作，但是你根本就不用担心队列

---

我会选择SQL Server代理。它与SQL Server集成良好；各种SQL Server功能都使用代理（例如，日志传送）。例如，您可以创建一个代理作业来运行一个或多个SSIS包

---

它还与操作员通知集成在一起，可以编写脚本，或者通过SMO执行。
我认为决定标准的最佳方法是作业是什么。如果它是一个完全内部的SQL Server任务或一组与外部世界无关的任务，我认为a是最好的选择。另一方面，如果您正在检索数据，然后对其执行SQL Server之外固有的操作，在T-SQL中很难执行或很耗时，那么外部服务可能是最佳选择。
我通常使用操作系统调度方法（Windows的任务调度程序，Unix的cron）
我处理多个数据库平台（SQLServer、Oracle、Informix），希望任务调度尽可能通用

---

此外，在我们的生产环境中，我们必须让DBA参与数据库中正在运行的作业的任何故障排除/重新启动。我们可以更好地访问带有计划任务的应用程序服务器。
您不能真正依赖外部进程。我见过的所有基于“操作系统”的解决方案都未能在现实世界中提供：数据库不仅仅是数据，这主要是因为备份/恢复战略、高可用性战略、灾难可恢复性战略以及您在SQL Server许可证中支付的所有其他“活动”。基于操作系统调度器的系统将是一个完全不知道的外部组件，并且与它们中的任何一个都不集成。也就是说，您不能用数据备份/恢复您的计划，它不会对您的数据库进行故障转移，您不能通过SQL数据传送通道将其传送到远程灾难恢复站点
如果您有代理（即非特快版），则使用代理。它有着悠久的使用历史，并且它的技术诀窍非常重要。代理的唯一问题是它依赖于msdb，这使得它与应用程序数据库断开连接，因此无法很好地使用基于镜像的可用性和可恢复性解决方案

---

对于Express Edition（即无代理），最好的选择是基于（至少在SQL 2k5和forward中）滚动您自己的调度程序。您可以使用对话在所需的时间安排自己的消息，并依靠对话来运行任务。它们是事务性的，并且与您的数据库集成在一起，因此您可以依靠它们在恢复后以及镜像或群集故障转移后的存在。不幸的是，关于如何使用它们的诀窍相当肤浅，我的网站上有几篇关于这个主题的文章。我见过一些系统在Express上完全依赖对话计时器复制大量代理API
Doug，这是另一种可能性，但是你能说它比其他的更好吗？我建议你避免在SQL提供基于队列的、激活启动的处理时重新发明轮子，这种处理从2K5开始就支持计时器…@remus：好的，我没有意识到。您应该使用它，而不是滚动您自己的.JP，也许您的意思是，“除非您使用SSI执行此外部操作”？John同意，这一点非常好。SSIS是一种接触外部世界的好方法。就我个人而言，我已经有点偏离了计划SSIS包，因为它们可能有点昂贵（旋转新流程等等），但这可能是我的错误看法。-1：对于混合平台，你是对的。但问题是关于SQL Server的。实际上，这是一个相当开放的问题，c