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

13

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)
sql-server sql-server-2008-r2 jobs benik9
źródło
Podejrzewam, że jest to po prostu raportowanie użytego @os_run_priority, zamiast dawania szansy na wpływ na priorytet. Jeśli tak, tekst pomaga ci ustalić, jaki priorytet został użyty.
RLF,

Odpowiedzi:

11

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.

Sean Gallardy
źródło
4

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.

Solomon Rutzky
źródło
1
Jest przekazywany w strukturze zadania do każdego podsystemu i każdy podsystem jest odpowiedzialny za wybranie, co z tym zrobi. Nie mogłem znaleźć podsystemu, który zaimplementowałby taki kod w poprawkach z terminalem 2008R2.
Sean Gallardy,
@SeanGallardy Tom zaktualizował twoją odpowiedź brakującym elementem, który wyjaśnia wszelkie obawy :-). Nie wiedziałem, że masz dostęp do źródła, i często wystarczająca liczba osób mówi rzeczy bardzo pewnie / zdecydowanie, tak jakby istniała bezpośrednia, zaobserwowana wiedza, a jednak jest to tylko najlepsze przypuszczenie. Poparłem twoją odpowiedź, ale zachowam moją odpowiedź, ponieważ zawiera ona dodatkowe informacje o priorytetach, a także o tym, jak badać podobne problemy.
Solomon Rutzky