sp_add_jobstep中的@os_run_priority实际上在SQL Server 2008 R2中工作吗？

是否@os_run_priority在sp_add_jobstep实际工作中，在SQL Server 2008 R2？

它被描述为“保留”或“未记录”。但是，我在sp_add_jobstep定义中看到了它：

@os_run_priority INT = 0, -- -15 = Idle, -1 = Below Normal, 0 = Normal, 1 = Above Normal, 15 = Time Critical)

这是作业步骤定义的一部分，您甚至可能会看到它在其他区域中使用或定义了值。

在查看了源代码（我在Microsoft工作并且可以访问）后，尽管确实将值作为发送到每个子系统的作业步骤信息的一部分进行了传递，但我找不到实际将值设置为一部分的位置工作步骤执行。但是，作为SQL Server代理的一部分，确实有以不同优先级运行的线程，这些线程可能会或可能不会有助于工作步骤功能或填补特定角色的子系统。

尽管我没有进行详尽的检查，但最好将这个值假定为-如所描述-“保留”。仅仅因为它似乎没有被使用并不意味着它不能在管道存在的任何其他位置使用。

虽然此值已保存为工作步骤的一部分，但我找不到使用该值的证据。

如果设置通过将参数的值, @os_run_priority = X到EXEC msdb.dbo.sp_update_jobstep，那么它正确地示出了在os_run_priority列msdb.dbo.sysjobsteps。

我创建了一个包含2个步骤的作业：一个T-SQL步骤和一个操作系统（CmdExec）步骤。我认为诸如“ os run priority”之类的选项很有可能会影响CmdExec步骤，但是最好同时测试这两个步骤。

每个步骤都执行了一个操作，WAITFOR DELAY '00:00:30.000'以便当我查看正在运行的进程以查看优先级是否已更改时，它会徘徊。

我使用Process Explorer检查了进程。据我所知，这些值（和我试过1，15和-1）没有任何效果。我尝试在Windows 10上同时使用SQL Server 2012和2016。

我也尝试在Windows XP上运行的SQL Server 2008 R2上。我再也没有看到该属性对SQLAGENT进程或SQLCMD进程有任何影响的指示（我在CmdExec步骤中使用它来回调SQL Server来执行此操作WAITFOR DELAY）。

当然，应该注意，进程本身需要某些权限才能更改线程的优先级。当SQL Server代理作为本地系统帐户运行时，它可能没有这种权限。但是，我使用自己的Windows登录名作为SQL Server代理的服务帐户进行了测试（仅适用于SQL Server 2016），并且没有发现任何使用此属性的迹象。