Rola processadmin

Rola processadmin pozwala kończyć procesy uruchomione na instancji SQL Server.

Uprawnienie do przerywania cudzych sesji

To stała rola na poziomie serwera, a nie pojedynczej bazy — jej członkowie mają prawo wykonać polecenie KILL wobec sesji innych użytkowników instancji. W nowszych wersjach silnika rola jest odwzorowana na uprawnienie ALTER ANY CONNECTION, co oznacza, że dokładnie ten sam efekt można osiągnąć bez dodawania nikogo do roli, nadając wprost to jedno uprawnienie. Członkostwo sprawdza się funkcją IS_SRVROLEMEMBER albo zapytaniem do sys.server_role_members złączonego z sys.server_principals.

Warto zauważyć, do czego rola nie uprawnia: nie daje wglądu w treść zapytań innych sesji ani nie pozwala czytać danych z żadnej bazy. Podgląd listy sesji wymaga osobnego uprawnienia VIEW SERVER STATE, bez którego administrator widzi wyłącznie własne połączenia i nie ma jak ustalić, co miałby zakończyć.

Co się dzieje po zakończeniu procesu

Przerwanie sesji nie jest natychmiastowe ani darmowe. Jeżeli sesja miała otwartą transakcję, silnik musi ją wycofać, a wycofanie potrafi trwać dłużej niż samo wykonanie. Sesja przechodzi wtedy w stan wycofywania i widnieje w wynikach zapytania o postęp operacji z procentem ukończenia. Próba ponownego zakończenia takiej sesji nic nie przyspieszy. Osobna sytuacja to transakcje rozproszone i sesje zablokowane przez oczekiwanie na zasób zewnętrzny — tam zabicie procesu nie zwalnia blokady od razu. Dlatego rutynowe rozwiązywanie zakleszczeń przez zabijanie sesji jest leczeniem objawu: przyczyną zwykle są brakujący indeks, zbyt szeroka blokada albo raport uruchamiany na bazie produkcyjnej w godzinach szczytu.

Ryzyka nadawania tej roli w firmie

Częsty scenariusz: aplikacja handlowa wiesza się użytkownikom, więc ktoś z działu IT dostaje uprawnienie, żeby móc odblokowywać zablokowane dokumenty. Po roku okazuje się, że zabijanie sesji stało się codzienną procedurą, a operatorzy tracą niezapisane dokumenty za każdym razem, gdy ich połączenie zostanie zamknięte. Drugi problem to nadanie roli koncie aplikacji zamiast koncie człowieka — wtedy program w reakcji na własny błąd potrafi zamykać sesje innych stanowisk. Trzeci to brak śladu: bez włączonej inspekcji nie da się później ustalić, kto i kiedy przerwał sesję, która akurat księgowała dokument.

Diagnostyka blokad w systemach handlowych

Gdy program sprzedażowy zamiera przy zapisie dokumentu, sprawdzamy realną przyczynę zamiast zamykać połączenia: analizujemy oczekiwania sesji, ustalamy blokującą transakcję i jej zapytanie, weryfikujemy plany wykonania i indeksy oraz sprawdzamy, czy w tle nie działa kopia zapasowa lub przebudowa indeksu w godzinach pracy. Przy okazji porządkujemy uprawnienia serwerowe, żeby nikt nie miał więcej, niż potrzebuje. Obsługujemy firmy przez całą dobę, siedem dni w tygodniu.