我正在使用SQL Server代理计划甚至非数据库任务-这是一个坏主意吗？

由于我是DBA（在许多情况下，事实上是sysadmin），因此SQL Server几乎安装在我必须定期使用的每台服务器上。最近我意识到，在几乎每种情况下，我都一直在使用SQL Agent作为作业调度程序，而不是使用本机Windows Task Scheduler。

在我看来，与本地Windows Task Scheduler相比，SQL Agent具有许多优点：

• （从我的工作站）远程启动/停止/监视任务
• 共享时间表（而不是每个任务自己执行）
• 多个步骤和控制流程
• 不同类型的任务
• 失败/完成警报
• 可以配置为充当不同的用户
• （适度）描述性错误消息，而不仅仅是错误代码

但是，我无法避免这种做法不好的感觉-尽管我不喜欢SQL代理的可用性，但应该仅将SQL Agent保留给与数据库相关的任务，并且应该让Windows任务计划程序中运行OS级别的任务。

以这种方式依赖SQL Agent可以吗？如果没有，我是否应该考虑使用第三方Windows任务计划程序来获得我正在寻找的某些功能？

我个人认为最大的警告是保持工作清单井井有条。据我所知，您无法创建文件夹来组织作业，因此，大量文件夹会很麻烦。不过，我不确定100％是否如此，因为我的服务器都没有超过十个工作岗位。Server 2008和更高版本的Task Scheduler可以简化组织IMO，并且通常比以前的版本具有更好的功能。我敢肯定，第三方应用程序可以做得更好。如果必须使用Server 2003的任务计划程序或，我会哭泣at.exe。

我能想到的第二点警告可能是对SQL服务器施加过多的负载。该代理是一个小程序，但是运行长时间或复杂的任务很容易消耗大量资源。这些资源将不可用于SQL引擎。由于将SQL引擎编程为占用约80％的可用系统内存，所以这可能是个问题。

第三，备份可能是一个问题。您不仅需要备份文件系统，还需要备份msdb数据库以允许恢复作业（或使用某些脚本将任务编写为文本文件）。这给灾难恢复增加了一层复杂性。

最后，您不想只是为了运行SQL Server代理而为SQL Server许可证付费。如果数据库已停用，则需要制定计划以从SQL Server代理迁移。

在我之前的工作中，我确实做到了这一点，主要是因为这些工作都是从我们的中央主群集运行的，该群集是最可见的服务器。我可以在一个地方看到所有计划的任务，而不必去检查一堆服务器上的命令行内容。

尽管这在很大程度上是主观的（并且很难以这种格式得出“正确的”答案），但我认为这种方法除了成为单点故障之外，没有任何内在的错误。

如果所有任务都与正在启动的数据库服务器交互或依赖于正在运行的SQL Server服务（在我们的示例中确实如此），则这可能无关紧要。

哦，对于要尝试运行任务的服务器未启动的情况，您需要添加错误处理-如果在该服务器上设置了任务，则无需执行此操作。

我可能会将SQL Agent移交给Windows任务管理器...显然是与数据库相关的任务。

如果您完全可以编写代码，或者拥有可以编写代码的人员，则可以使用控制台应用程序做很多工作，并将它们包装到TopShelf之类的服务创建者中（http://topshelf-project.com/），这可能很便宜/简单的技巧可以使所有内容都与SQL Agent脱钩，并且还可以为您提供一个排队层。

就个人而言，您似乎对此很在意，并且对您的陷阱很了解，我认为您会没事的。是那些不在乎/知道我真的担心的人。毫无疑问，您将在合理的时间间隔内评估解决方案并采取相应的措施。

另一个选择是使用存储过程为计划任务创建表，以从中更新消息队列表。然后，SQL Server代理会如此频繁地调用存储过程以创建消息并更新任务状态。其他系统将通过SQL连接或Web API层作为JSON查询消息队列表。