Niedawno natknąłem się na problem z wywołaniem procedury sp_job_start w bazie MS SQL. Dzięki niej możemy wykonać dowolnego joba, niezależnie od harmonogramu. Aby wywołać tą procedurę, użytkownik został dodany do następujących grup:
- SQLAgentUserRole
- SQLAgentReaderRole
- SQLAgentOperatorRole
Jednak nie zawsze to wystarcza i błąd dalej występuje (tak było w moim przypadku). Okazuje się, że nie wszystkie grupy miały uprawnienia do wykonywania procedury sp_job_start w bazie MSDB. Która konkretnie grupa potrzebuje tych uprawnień można sprawdzić za pomocą skryptu:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
USE MSDB GO SELECT PR.NAME, DP.PERMISSION_NAME, DP.STATE_DESC FROM MSDB.SYS.DATABASE_PERMISSIONS DP JOIN MSDB.SYS.OBJECTS O ON DP.MAJOR_ID = O.OBJECT_ID JOIN MSDB.SYS.DATABASE_PRINCIPALS PR ON DP.GRANTEE_PRINCIPAL_ID = PR.PRINCIPAL_ID WHERE O.NAME = 'SP_START_JOB' |
Mój wynik był następujący:
Jak widać grupa TargetServersRole ma zablokowany dostęp do tej procedury – DENY w kolumnie STATE_DESC. W celu dodania uprawnień należy wykonać poniższa komendę:
|
1 2 3 |
USE MSDB GO GRANT EXECUTE ON SP_START_JOB TO TargetServersRole |
Po tym “zabiegu” wszystko zaczęło działać. Ktoś mógłby zapytać, po co właściwie uruchamiać joby jakimś innym użytkownikiem, przecież ich zadaniem jest uruchamianie się zgodnie z ustawionym harmonogramem?
Robi się to w celu bezpieczeństwa. Przykładowo jeżeli pracujemy na dwóch bazach danych A i B (na osobnych serwerach) i chcemy użytkownikiem z bazy A wywoływać procedury w bazie B, które wymagają dostępu do wielu składowych (tabel, procedur, widoków, funkcji itp..). Takie rozwiązanie powoduje, że dodajemy uprawnienia wykonywania tylko i wyłącznie dla danego joba i nie musimy się martwić o resztę.
Mam nadzieję, że to rozwiązanie okaże się pomocne i oszczędzi Wam trochę czasu w jego szukaniu.