Restart usług

Restart usług SQL Server przerywa aktywne połączenia i wymaga ponownego uruchomienia procesu odzyskiwania baz.

Na czym polega restart usług SQL Server

Restart usługi SQL Server polega na zatrzymaniu procesu silnika bazy danych i jego ponownym uruchomieniu przez system Windows. Dotyczy to konkretnej instancji, na przykład domyślnej instancji MSSQLSERVER albo nazwanej instancji uruchamianej jako MSSQL$NazwaInstancji. W trakcie zatrzymywania silnik kończy przyjmowanie nowych żądań, a aktywne połączenia z aplikacji, narzędzi administracyjnych i usług zależnych zostają przerwane. Restart usługi SQL Server nie jest tym samym co ponowne uruchomienie całego komputera, ponieważ operacja obejmuje wybraną usługę oraz jej procesy zależne.

W środowisku SQL Server często występuje także usługa SQL Server Agent, odpowiedzialna między innymi za wykonywanie zadań zaplanowanych, alertów i operatorów. Jej restart nie uruchamia ponownie silnika bazy danych. Z kolei usługa SQL Server Browser pomaga klientom odnajdywać nazwane instancje przez protokół UDP 1434, ale również nie zastępuje usługi właściwego silnika. Przed wykonaniem operacji trzeba więc ustalić, która usługa faktycznie obsługuje daną bazę i czy aplikacja korzysta z instancji domyślnej, nazwanej lub połączenia przez określony port TCP.

Połączenia, transakcje i proces odzyskiwania baz

Zatrzymanie silnika SQL Server powoduje utratę bieżących sesji klientów. Jeżeli aplikacja nie zamknęła połączenia prawidłowo, użytkownik może zobaczyć błąd połączenia, timeout albo komunikat wskazujący na niedostępność serwera. Otwarte transakcje nie są kontynuowane po restarcie. SQL Server wykorzystuje dziennik transakcji do określenia, które operacje zostały zatwierdzone, a które wymagały wycofania. Dlatego po ponownym uruchomieniu bazy może rozpocząć się automatyczne odzyskiwanie, obejmujące fazę analizy, ponowienia operacji zapisanych w dzienniku oraz wycofania transakcji niezatwierdzonych.

Czas odzyskiwania zależy między innymi od rozmiaru pracy zapisanej w dzienniku, wydajności pamięci masowej, liczby aktywnych transakcji i stanu baz w chwili zatrzymania. W tym okresie baza może być niedostępna albo dostęp do niej może być ograniczony, zależnie od fazy odzyskiwania i konkretnego stanu bazy. Wymuszenie zatrzymania procesu, odcięcie zasilania lub zakończenie procesu bez kontrolowanego zamknięcia zwiększa prawdopodobieństwo dłuższego odzyskiwania. Kontrolowane zatrzymanie usługi pozwala silnikowi uporządkować pracę przed zamknięciem, ale nie eliminuje skutków przerwania połączeń ani błędów aplikacji.

Sprawdzenie przyczyny przed ponownym uruchomieniem

Sam restart nie usuwa przyczyny problemu, jeżeli źródłem jest błąd dysku, uszkodzenie plików baz danych, brak miejsca, przeciążenie pamięci, blokada transakcyjna albo nieprawidłowa konfiguracja połączenia. Przed operacją warto odczytać bieżące komunikaty z dziennika błędów SQL Server oraz zdarzenia systemowe Windows. Dziennik silnika można przeglądać w SQL Server Management Studio, a także za pomocą procedury sp_readerrorlog, uruchomionej w odpowiednim kontekście administracyjnym. Należy zwrócić uwagę na komunikaty dotyczące plików MDF, NDF i LDF, błędów wejścia-wyjścia, braku miejsca oraz nieudanego odzyskiwania bazy.

Ważne jest również ustalenie zależności aplikacyjnych. Program korzystający z SQL Server może uruchamiać własną pulę połączeń i po restarcie wymagać ponownego nawiązania sesji. Jeżeli aplikacja nie obsługuje chwilowej niedostępności, po uruchomieniu usługi może nadal zgłaszać błędy aż do ponownego uruchomienia jej własnego procesu. Przydatne jest sprawdzenie nazwy instancji, konta usługi, trybu uruchamiania oraz konfiguracji protokołów w SQL Server Configuration Manager. W przypadku połączeń sieciowych trzeba dodatkowo zweryfikować, czy zapora i konfiguracja TCP/IP pozwalają klientowi dotrzeć do właściwego portu.

Bezpieczna kolejność i weryfikacja działania

Restart powinien być poprzedzony poinformowaniem użytkowników aplikacji o przerwie, zamknięciem procesów wykonujących operacje na bazie oraz sprawdzeniem, czy nie trwa ważne zadanie konserwacyjne. Po zatrzymaniu usługi należy potwierdzić jej ponowne uruchomienie i obserwować stan baz w SQL Server Management Studio lub w dzienniku błędów. Szczególnej uwagi wymaga stan RECOVERING, RECOVERY_PENDING albo SUSPECT, ponieważ oznacza on problem wykraczający poza zwykłą niedostępność usługi. Nie należy rozpoczynać naprawy bazy poleceniami ingerującymi w strukturę danych bez wcześniejszego ustalenia przyczyny i zabezpieczenia kopii.

Po zakończeniu odzyskiwania trzeba sprawdzić logowanie z aplikacji, dostęp do wymaganych baz, działanie zaplanowanych zadań oraz podstawowe operacje odczytu i zapisu. Warto też potwierdzić, że uruchomiona została właściwa instancja, a nie inna usługa SQL Server obecna na tym samym komputerze. Jeżeli restart był reakcją na powtarzający się błąd, należy porównać komunikaty sprzed i po operacji oraz ustalić, czy problem powraca. Przy pracy z komputerem stacjonarnym lub laptopem diagnostyka powinna obejmować także stan dysku, pamięci, systemu Windows i aplikacji korzystającej z lokalnej bazy, ponieważ restart procesu może jedynie czasowo przywrócić działanie bez usunięcia uszkodzenia źródłowego.