Czy @os_run_priority w sp_add_jobstep faktycznie działa w SQL Server 2008 R2?

Czy @os_run_priorityw sp_add_jobsteprzeczywiście działa w SQL Server 2008 R2?

Jest to określane jako „zastrzeżone” lub „nieudokumentowane”. Widzę to jednak w sp_add_jobstepdefinicji:

@os_run_priority INT = 0, -- -15 = Idle, -1 = Below Normal, 0 = Normal, 1 = Above Normal, 15 = Time Critical)

Jest to część definicji kroku zadania i możesz nawet zobaczyć, że wartości zostały użyte lub zdefiniowane w innych obszarach.

Po zapoznaniu się z kodem źródłowym (pracuję w firmie Microsoft i mam dostęp), podczas gdy wartość jest rzeczywiście przekazywana jako część informacji o kroku zadania wysyłanych do każdego podsystemu, nie mogłem znaleźć miejsca, które faktycznie ustawia wartość jako część wykonania kroku zadania. Istnieją jednak wątki, które działają na różnych poziomach priorytetów jako część SQL Server Agent i te wątki mogą, ale nie muszą, pomagać w funkcjonowaniu kroku zadania lub podsystemach, które pełnią określoną rolę.

Chociaż nie przeprowadziłem wyczerpującego sprawdzenia, najlepiej byłoby założyć, że ta wartość jest - jak opisano - „zarezerwowana”. To, że nie wydaje się być używane, nie oznacza, że ​​nie może być w żadnym innym momencie, ponieważ istnieje hydraulika.

Chociaż ta wartość jest zapisywana jako część etapu zadania, nie mogę znaleźć dowodów na to, że wartość jest używana.

Jeśli ustawię wartość, dodając parametr , @os_run_priority = Xdo EXEC msdb.dbo.sp_update_jobstep, to pokazuje się poprawnie w os_run_prioritykolumnie msdb.dbo.sysjobsteps.

Utworzyłem zadanie z 2 krokami: jednym krokiem T-SQL i jednym krokiem systemu operacyjnego (CmdExec). Zakładam, że bardziej prawdopodobne jest, że opcja taka jak „priorytet uruchomienia os” wpłynie na krok CmdExec, ale dobrze jest przetestować oba.

Każdy krok robił WAITFOR DELAY '00:00:30.000'tak, aby zawieszał się, gdy patrzyłem na uruchomione procesy, aby sprawdzić, czy priorytet się zmienił.

Sprawdziłem procesy za pomocą Process Explorera . O ile mogę powiedzieć, wartości (i próbowałem 1, 15i -1) nie mają żadnego wpływu. Próbowałem używać zarówno programu SQL Server 2012, jak i 2016 w systemie Windows 10.

Próbowałem także na SQL Server 2008 R2 z systemem Windows XP. Znów nie widziałem, aby ta właściwość miała jakikolwiek wpływ na proces SQLAGENT lub SQLCMD (którego używałam w kroku CmdExec, aby oddzwonić do SQL Server, aby to zrobić WAITFOR DELAY).

Oczywiście należy zauważyć, że sam proces wymaga pewnych uprawnień, aby zmienić poziom priorytetu wątku. Gdy agent programu SQL Server działa jako lokalne konto systemowe, może nie mieć takich uprawnień. Jednak przetestowałem (tylko SQL Server 2016), używając własnego logowania do systemu Windows jako konta usługi dla agenta SQL Server, i nie zauważyłem, że ta właściwość jest używana.