Работает ли @os_run_priority в sp_add_jobstep в 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). Я предполагаю, что более вероятно, что такой параметр, как «приоритет запуска ОС», повлияет на шаг CmdExec, но хорошо проверить оба варианта.

Каждый шаг делал WAITFOR DELAY '00:00:30.000'так, чтобы он зависал, пока я смотрел на запущенные процессы, чтобы увидеть, изменился ли приоритет.

Я проверил процессы с помощью Process Explorer . Насколько я могу сказать, что значения (и я попробовал 1, 15и -1) не имеют никакого эффекта. Я попытался использовать SQL Server 2012 и 2016 на Windows 10.

Я также пробовал на SQL Server 2008 R2, работающем на Windows XP. Я снова не увидел никаких признаков того, что это свойство оказывает какое-либо влияние на процесс SQLAGENT или процесс SQLCMD (который я использовал на шаге CmdExec для обратного вызова SQL Server, чтобы сделать это WAITFOR DELAY).

Конечно, следует отметить, что самому процессу необходимы определенные разрешения для изменения уровня приоритета потока. Когда агент SQL Server работает как учетная запись локальной системы, он может не иметь таких прав. Однако я провел тестирование (только для SQL Server 2016), используя свою собственную учетную запись Windows в качестве учетной записи службы для агента SQL Server, и не увидел никаких признаков использования этого свойства.