Sql*_*yan 13 sql-server sql-server-agent windows-server scheduled-tasks
由于我是一名 DBA（并且在许多情况下，事实上的系统管理员），SQL Server 安装在我必须定期使用的几乎每台服务器上。我最近意识到我在几乎所有情况下都使用 SQL 代理作为作业调度程序，而不是本机 Windows 任务调度程序。
从我的角度来看，SQL Agent 比原生的 Windows 任务计划程序有很多优势：
但是，我无法逃避这是一种不好的做法 - SQL 代理应该只保留用于与数据库相关的任务，并且我应该让操作系统级别的任务在 Windows 任务计划程序中运行，尽管我不喜欢它的可用性。
这样依赖SQL Agent可以吗？如果没有，我是否应该考虑使用第三方 Windows 任务调度程序来获得我正在寻找的某些功能？
在我之前的工作中，我正是这样做的，主要是因为这些工作都是从我们的中央主集群运行的，这是最明显的服务器。我可以在一个地方看到我们所有的计划任务，而不必去检查一堆服务器上的命令行内容。
虽然这在很大程度上是主观的（并且很难以这种格式得出“正确”的答案），但我认为这种方法除了成为单点故障之外没有任何本质上的错误。
如果所有任务都与正在启动的数据库服务器和正在运行的 SQL Server 服务（在我们的例子中，确实如此）交互或依赖，那么这可能无关紧要。
哦，您需要在任务尝试运行的服务器未启动的情况下添加错误处理 - 如果任务设置在该服务器上，您就不必这样做。
我个人认为最大的警告是难以组织工作清单。据我所知，您无法创建文件夹来组织作业，因此数量过多会很麻烦。不过，我不是 100% 确定这一点，因为我的服务器都没有超过十几个工作。Server 2008 和更高版本的任务计划程序允许更轻松的组织，IMO，并且通常比以前的版本具有更好的功能。我相信第三方应用程序做得更好。如果我必须使用 Server 2003 的任务调度程序或at.exe.
我能想到的第二个警告可能是在 SQL 服务器上施加了过多的负载。Agent 是一个小程序，但是运行一个很长或很复杂的任务很容易消耗大量资源。这些资源将不可用于 SQL 引擎。由于 SQL 引擎被编程为占用大约 80% 的可用系统内存，这可能是一个问题。
第三，备份可能是一个问题。您不仅需要备份文件系统，还需要备份 msdb 数据库以允许恢复作业（或使用某些东西将任务脚本写入文本文件）。这给灾难恢复增加了一层复杂性。
最后，您不希望仅仅为了运行 SQL Server 代理而支付 SQL Server 许可证费用。如果数据库停用，您需要制定迁移 SQL Server 代理的计划。