sp_add_jobstep 中的@os_run_priority 是否真的在SQL Server 2008 R2 中工作？
@os_run_priority在sp_add_jobstepSQL 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），但沒有看到使用此屬性的跡象。