我的情况让我非常摸不着头脑。这是一个 SQL Server 2008r2 实例,用作大型企业 SharePoint 服务的数据库服务器。由于我的公司为其提供数据库支持,我所做的其中一件事是设置一些维护计划来处理日常事务,包括在晚上 7 点对所有数据库进行夜间完整备份。
这一切都很好,除了它偶尔也会在清晨的某个时间运行。
到目前为止,这已经发生了 3 次,一次是 11 天前凌晨 2:47,一次是 4 天前凌晨 3:43,一次是两天前凌晨 3:49。我找不到为什么它应该在这些零星的随机时间运行的理由。
这给我们带来了严重的问题,因为清晨是服务器托管提供商运行他们的备份和维护工作的时候。它们的执行时间比正常时间长很多倍,并为此发出警报和其他通知,IO 时间长以及各种错误,这些错误似乎是由于与主机 SAN/NAS 镜像和备份的冲突。
总结一下我已经检查过的内容:
这是运行额外计划外时间的 SQL 代理作业,而不仅仅是在同一作业中运行两次的维护计划。
这似乎不是此节点的 VM 克隆,其中 SQL 代理针对真实 SQL Server 运行此作业的副本。我得出这个结论是因为我们的 SQL 代理日志中显示了执行。(如果这不是确定的,请告诉我如何检查)
这不是 Job 只是运行了很长时间的情况。常规作业在每天的预期预定时间(晚上 7 点)运行并完成。
服务器和 SQL Server 实例在上个月都没有重新启动。
有问题的 SQL Server 作业只有一个计划,即设置为每天晚上 7 点。
维护计划只有一个子计划,它显示与作业完全相同的计划。
非常感谢任何帮助。
在 Aaron 的建议下,我添加了以下 Execute SQL 作为子计划中的第一个任务:
IF (DATEPART(HOUR, GETDATE()) > 2) AND (DATEPART(HOUR, GETDATE()) < 6)
RAISERROR('Job Running at the Wrong Time!', 16, 1) WITH LOG
嗯,谜团解开了。
我之前曾在另一个站点 (SqlServerCentral.com) 上发布过此内容,然后在几个小时没有得到回复后发布到这里。当我在这里尝试 Aaron 的建议时,Josh 在那里发布了以下内容:
虽然我之前浏览过约伯记的历史,但我并没有专门寻找那条信息。你瞧,计划外的有以下几点:
所以一定有人标记了这个工作以在警报之后运行(可能是错误的工作)。
当然,现在我觉得以前没有检查过这个很傻。但是我现在在这里发布这个,以便将来其他人可以从我的疏忽中受益。
我的建议:
在作业步骤中进行检查,以确保仅在晚上 7 点到晚上 8 点之间的某个时间开始作业时执行维护计划逻辑:
这并不能消除来自任何恶意进程干扰的噪音,但它确实可以防止损坏。
添加一个日志表,例如:
查找作业的名称/job_id,并通过在最开始(这也将捕获失败)或在逻辑之前添加它进行修改(它应该只捕获成功的启动):
msdb.dbo.sp_start_job
sp_post_msx_operation
您还可以在表格中添加一个触发器,该触发器会在
JobAudit
插入某些内容时向您发送电子邮件(这样您就不必手动监视表格)。