sp_add_jobstepの@os_run_priorityは実際にSQL Server 2008 R2で機能しますか？
します@os_run_prioritysp_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列に正しく表示されます。
T-SQLステップとオペレーティングシステム（CmdExec）ステップの2つのステップでジョブを作成しました。 「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エージェントがローカルシステムアカウントとして実行されている場合、そのような権限がない可能性があります。ただし、SQL Serverエージェントのサービスアカウントとして自分のWindowsログインを使用してテストを行い（SQL Server 2016のみ）、このプロパティが使用されていることを示していませんでした。