作为测试,我创建了一个包含两个步骤的作业。第一步将新的作业步骤添加为步骤2,添加的步骤将等待10秒,然后退出作业报告成功。下一步会产生一个错误,但是在添加新步骤之后,就永远不要运行它。
查看作业历史记录,实际发生的情况是成功地将新作业步骤添加为步骤2,步骤2的名称是所添加步骤的名称,但是步骤2会在此生成步骤3应该出现的错误重点,即使第3步永远都不要运行。
本质上,它就像第2步不存在一样运行。在作业历史记录中,步骤2被称为正确的步骤名称,但是运行的代码实际上是步骤3。
答案 0 :(得分:1)
我认为工作的实际运作方式令人困惑。
当您调用作业时,它将在您调用时完全运行。如果您在运行时对作业进行了更改,则在下次运行该作业之前,将不会执行这些更改(您可以通过添加sp_delete_job步骤以尽早删除该作业来轻松验证这一点,您可以看到该作业即使已被删除,仍将继续执行下一步。
因此,当您最初调用作业时,它将完全执行您拥有的内容:
这就是为什么您无法通过添加新步骤来绕过原始第二步的原因。就SQL Server而言,此执行不存在新步骤。
对于名称混淆-直到完成该过程,才记录作业历史记录,并且使用INT step_id(而不是该步骤的唯一标识符)记录信息,这就是为什么在查看该名称时会看到新的步骤名称的原因即使已执行的基础逻辑来自您的原始步骤2,也保留了历史记录。可能应将其踢到MS,以切换到使用UID以避免这些情况。
答案 1 :(得分:1)
在其他人遇到与我类似的情况下,回答我自己的问题。
其他用户建议抛出一个错误,该错误肯定可以解决,但是在我的数据库中,记录并检查了计划作业的所有错误。我想停止工作的原因是因为我想避免在假期运行工作,因此抛出错误将导致不必要的审查。
对我有用的是创建一个存储过程,该过程检查是否是假期。如果不是假期,工作将照常进行。如果是假期,该作业将使用msdb.dbo.sp_stop_job停止该作业,而不会出现错误。其中一些作业每月运行一次,因此我还使用了sp_add_schedule和sp_attach_schedule创建并附加了第二天的一次运行。
答案 2 :(得分:0)
[msdb]。[dbo]。[sysjobsteps]表可能是您的朋友。尤其是检查on_success_action和on_fail_action列。我会确保在您添加的步骤之前的步骤对其on_success_action具有3 = onSuccessRunNextStep。
这可能有用
DECLARE @MaxJobStep_id INT
DECLARE @Job_id NVARCHAR(500)
SELECT @Job_id= job_id FROM sysjobs
WHERE name IN ('InsertJobNameHere')
SELECT @MaxJobStep_id = MAX(Step_id)
FROM sysjobsteps
WHERE job_id = @Job_id
EXEC sp_update_jobstep
@job_name = 'InsertJobNameHere'
, @step_id = @MaxJobStep_id
, @on_success_action = 3
, @on_fail_action = 3