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

Question

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

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

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

• 等

两个问题：

1. 有什么其他方法可以实现这个目标
2. 应该使用什么决策标准来决定最佳方法？

谢谢。

Answer 1

另一种可能性是在某处有一个任务队列，当另外使用数据库的应用程序执行某些操作时，它们也会从队列中执行某些任务。维基百科通过其作业队列做了类似的事情。调度不像其他方法那样确定，但您可以例如当服务器重负荷时，推迟做家政工作。

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

<强>优点

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

<强>缺点

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

Answer 2

我通常使用操作系统调度方法（Windows的任务调度程序，Unix的cron）。

我处理多个数据库平台（SQL Server，Oracle，Informix），并希望将任务调度保持尽可能通用。

此外，在我们的生产环境中，我们必须让DBA参与任何故障排除/重新启动数据库中运行的作业。我们可以更好地访问具有计划任务的应用程序服务器。

Answer 3

您无法真正依赖外部流程。我见过的所有基于“操作系统”的解决方案都无法在现实世界中实现：数据库不仅仅是数据，主要是因为备份/恢复策略，高可用性策略，灾难恢复策略以及所有其他您在SQL Server许可证中付费的'ities'。基于OS调度程序将是一个完全没有意识到并且与其中任何一个都没有集成的外部组件。 IE浏览器。您无法使用数据备份/恢复计划，也不会使用数据库进行故障转移，也无法通过SQL数据传送渠道将其发送到远程灾难恢复站点。

如果您有代理（即非Express版），则使用代理。具有悠久的使用历史，并且知道它的重要性。 Agent的唯一问题是它依赖于msdb，这使得它与应用程序数据库断开连接，因此不能很好地与基于镜像的可用性和可恢复性解决方案配合使用。

对于Express版本（即没有代理），最好的选择是根据conversation timers推送自己的调度程序（至少在SQL 2k5和转发版中）。您可以使用对话在所需的时刻制作自己的消息，并依靠activated procedures来运行任务。它们是事务性的并与您的数据库集成，因此您可以依赖它们在还原后以及镜像或群集故障转移后存在。不幸的是，知道如何使用它们是相当划线的，我在我的网站rusanu.com上有几篇关于这个主题的文章。我已经看到系统在Express上复制相当数量的Agent API，完全依赖于会话计时器。

Answer 4

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

它还与操作员通知集成，可以编写脚本，也可以通过SMO执行。

Answer 5

我认为决策标准的最佳方法是工作。如果它是一个完全内部的SQL Server任务或一组与外界无关的任务，我会说SQL Job是最好的选择。另一方面，如果您正在检索数据，然后在SQL Server之外使用它进行某些操作，在T-SQL中很难做到或者非常耗时，那么外部服务可能是最好的选择。