Zatrzymanie usługi SQL Server

Zatrzymanie usługi SQL Server przerywa aktywne połączenia i kończy działanie wszystkich baz na instancji.

Co oznacza zatrzymanie instancji SQL Server

Zatrzymanie usługi SQL Server powoduje zakończenie pracy konkretnej instancji aparatu bazodanowego. W przypadku instancji domyślnej usługa systemu Windows nosi zwykle nazwę MSSQLSERVER, natomiast dla instancji nazwanej stosuje się nazwę MSSQL$NazwaInstancji. Po zatrzymaniu instancja przestaje przyjmować nowe połączenia przez TDS, czyli protokół używany przez klientów SQL Server, a istniejące sesje zostają rozłączone. Dotyczy to aplikacji, narzędzi administracyjnych, zadań automatycznych oraz innych usług korzystających z tej instancji.

Samo zatrzymanie usługi nie oznacza usunięcia baz danych ani skasowania plików .mdf, .ndf i .ldf. Bazy pozostają zapisane na dysku, ale do czasu ponownego uruchomienia instancji nie można wykonywać na nich zapytań ani operacji administracyjnych. Zatrzymanie może jednak przerwać transakcje, które nie zostały zatwierdzone. Przy kontrolowanym zamknięciu SQL Server wykonuje czynności potrzebne do zachowania spójności, a po ponownym uruchomieniu analizuje dzienniki transakcji i w razie potrzeby przeprowadza odzyskiwanie baz.

Kontrolowane zamknięcie a wymuszone przerwanie

Standardowe zatrzymanie usługi powinno być traktowane jako operacja administracyjna wymagająca wcześniejszego sprawdzenia zależności. W systemie Windows można użyć polecenia net stop MSSQLSERVER dla instancji domyślnej albo polecenia PowerShell Stop-Service -Name MSSQLSERVER. Dla instancji nazwanej należy wskazać właściwą nazwę usługi, na przykład MSSQL$APLIKACJA. Przed wykonaniem operacji warto sprawdzić, czy z instancji korzystają aplikacje produkcyjne, zadania SQL Server Agent, usługi raportowe lub mechanizmy replikacji.

Kontrolowane zatrzymanie daje silnikowi możliwość zamknięcia plików, zapisania wymaganych informacji i zakończenia pracy w uporządkowany sposób. Wymuszenie procesu, zakończenie usługi przez menedżera zadań albo odcięcie zasilania ma inny skutek: SQL Server może nie zdążyć zakończyć operacji wejścia i wyjścia. Nie musi to oznaczać uszkodzenia bazy, ponieważ mechanizm odzyskiwania korzysta z dziennika transakcji, ale ponowne uruchomienie może trwać dłużej. Szczególnym poleceniem jest SHUTDOWN WITH NOWAIT wykonywane w języku T-SQL; kończy ono pracę serwera bez oczekiwania na zakończenie aktywnych instrukcji, dlatego powinno być używane wyłącznie w sytuacjach uzasadnionych administracyjnie.

Wpływ na sesje, zadania i odzyskiwanie baz

Po zatrzymaniu SQL Server klienci otrzymują błędy połączenia albo komunikaty o utracie sesji. Niezatwierdzone zmiany w ramach transakcji nie powinny zostać uznane za zatwierdzone; po restarcie silnik odtworzy zatwierdzone operacje zapisane w dzienniku i wycofa transakcje, których zakończenie nie zostało potwierdzone. Ten etap nosi nazwę recovery i zwykle obejmuje analizę, ponowienie oraz wycofanie odpowiednich zmian. Czas odzyskiwania zależy między innymi od ilości pracy pozostawionej w dzienniku, aktywności transakcji i szybkości podsystemu dyskowego.

Zatrzymanie aparatu SQL Server wpływa również na komponenty zależne. SQL Server Agent nie może wykonywać zadań, takich jak kopie zapasowe, konserwacja indeksów, alerty czy importy danych, gdy aparat, z którym współpracuje, jest niedostępny. Po ponownym uruchomieniu należy sprawdzić stan usługi SQL Server Agent, harmonogramy zadań oraz dziennik błędów SQL Server. W przypadku instancji nazwanej trzeba dodatkowo uwzględnić SQL Server Browser, jeżeli klienci odnajdują instancję po nazwie i korzystają z dynamicznego portu. Sam Browser nie uruchamia aparatu bazodanowego i jego działanie nie zastępuje usługi właściwej instancji.

Bezpieczna weryfikacja po ponownym uruchomieniu

Po uruchomieniu usługi należy potwierdzić, że instancja rzeczywiście przyjmuje połączenia i udostępnia oczekiwane bazy. Podstawową kontrolę można wykonać w SQL Server Management Studio, sqlcmd albo innym kliencie zgodnym z SQL Server. Warto sprawdzić widok sys.databases, zwracając uwagę na kolumnę state_desc. Oczekiwanym stanem dla prawidłowo dostępnej bazy jest ONLINE; stany takie jak RECOVERING, RECOVERY_PENDING, RESTORING lub SUSPECT wymagają dalszej analizy i nie powinny być ignorowane.

Diagnostyka powinna obejmować także SQL Server Error Log, Podgląd zdarzeń systemu Windows oraz test połączenia z aplikacji, która korzysta z danej instancji. Nie należy rozpoczynać naprawy od przypadkowego uruchamiania poleceń DBCC CHECKDB, zmiany statusu bazy ani usuwania plików dziennika. Najpierw trzeba ustalić, czy problem dotyczy samego uruchomienia usługi, uprawnień konta usługi, braku miejsca na dysku, niedostępnych plików baz, konfiguracji portu czy błędów odzyskiwania. Takie rozróżnienie pozwala ocenić, czy zatrzymanie było zaplanowaną czynnością administracyjną, czy objawem poważniejszej awarii środowiska SQL Server.