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。

1つのT-SQLステップと1つのオペレーティングシステム（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エージェントがローカルシステムアカウントとして実行されている場合、そのような権限がない場合があります。ただし、自分のWindowsログインをSQL Serverエージェントのサービスアカウントとして使用してテスト（SQL Server 2016のみ）を行ったところ、このプロパティが使用されているという兆候は見られませんでした。