Чи працює @os_run_priority в sp_add_jobstep в SQL Server 2008 R2?

13

Є чи @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)

sql-server sql-server-2008-r2 jobs

— benik9
джерело

Я б підозрював, що це лише повідомлення про використовуваний @os_run_priority, а не дає можливість впливати на пріоритет. Якщо так, текст просто допомагає зрозуміти, який пріоритет був використаний.

— RLF

11

Це частина визначення етапу завдання, і ви навіть можете бачити, що він має значення, які використовуються або визначаються в інших областях.

Після перегляду вихідного коду (я працюю в Microsoft і маю доступ), хоча значення дійсно передається як частина інформації про крок завдання, що надсилається до кожної підсистеми, я не зміг знайти місце, яке фактично встановило б це значення як частину виконання етапу завдання. Однак є потоки, які виконуються в різних рівнях пріоритетності як частина агента SQL Server, і ці потоки можуть або не можуть допомогти з функціональним кроком завдання або підсистемами, які виконують певну роль.

Хоча я не робив вичерпної перевірки, було б безпечним вважати, що це значення - як описано - "зарезервоване". Тільки тому, що він, здається, не використовується, не означає, що він не може бути в будь-якій іншій точці, оскільки сантехніка існує.

— Шон Галларді
джерело

4

Хоча це значення зберігається як частина кроку завдання, я не можу знайти жодних доказів того, що значення використовується.

Якщо я встановив значення, додавши параметр , @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'так, щоб він зависав, поки я переглядав запущені процеси, щоб побачити, чи змінився пріоритет.

Я перевірив процеси за допомогою Провідника процесів . Наскільки я можу сказати, що значення (і я спробував 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, і не бачив ознак використання цього властивості.

— Соломон Руцький
джерело

1

Він передається в структурі завдань кожній підсистемі, і кожна підсистема несе відповідальність за вибір того, що з цим робити. Не вдалося знайти підсистему, яка реалізувала такий код у патчах 2008R2 w / terminal.

— Шон Галларді

@SeanGallardy Том оновив вашу відповідь відсутнім твором, який усуває будь-які проблеми :-). Я не знав, що ти маєш доступ до джерела, і часто досить багато людей констатують речі дуже впевнено / наполегливо, як ніби є прямі, спостережувані знання, і все ж це просто найкраща здогадка. Я схвалив вашу відповідь, але я продовжуватиму свою відповідь, оскільки вона містить додаткову інформацію про пріоритети, а також про те, як досліджувати подібні проблеми.

— Соломон Руцький