Awaria usługi SQL Server

Awaria usługi SQL Server to zdarzenie uniemożliwiające dalsze działanie głównego procesu obsługującego zapytania bazodanowe.

Na czym polega awaria usługi SQL Server

Awaria usługi SQL Server oznacza stan, w którym proces silnika bazy danych nie uruchamia się, zatrzymuje się podczas pracy albo nie przyjmuje połączeń mimo pozornie działającej usługi systemu Windows. W typowej instalacji głównym procesem instancji jest sqlservr.exe. To on obsługuje żądania klientów, wykonuje zapytania Transact-SQL, zarządza pamięcią, buforami stron danych, blokadami oraz zapisem zmian w plikach baz danych. Zatrzymanie tego procesu może więc uniemożliwić dostęp do wszystkich baz należących do danej instancji.

SQL Server może działać jako instancja domyślna albo jako instancja nazwana. Usługa instancji domyślnej jest zwykle identyfikowana w systemie Windows jako MSSQLSERVER, natomiast usługa instancji nazwanej ma postać MSSQL$NazwaInstancji. Odrębne role pełnią usługi SQL Server Agent, SQL Server Browser oraz usługi pomocnicze. Zatrzymanie Agenta nie jest równoznaczne z zatrzymaniem silnika bazy danych, a działanie usługi Browser nie oznacza, że właściwa instancja SQL Server poprawnie wystartowała.

Objawem awarii może być komunikat klienta o braku możliwości ustanowienia połączenia, błąd przekroczenia limitu czasu, odmowa połączenia lub informacja, że serwer nie istnieje albo jest niedostępny. Taki komunikat nie wskazuje jeszcze przyczyny. Problem może występować lokalnie w procesie SQL Server, w systemie plików, w konfiguracji instancji, w uprawnieniach konta usługi albo na poziomie komunikacji sieciowej.

Ślady przyczyny w dziennikach i konfiguracji instancji

Pierwszym źródłem informacji jest dziennik błędów SQL Server, ponieważ podczas uruchamiania silnik zapisuje tam między innymi używane pliki baz systemowych, parametry startowe, numer portu, problemy z dostępem do katalogów oraz błędy inicjalizacji. Szczególne znaczenie mają wpisy dotyczące bazy master, ponieważ jest ona niezbędna do uruchomienia instancji. Uszkodzenie pliku danych lub dziennika tej bazy, błędna ścieżka w parametrze startowym albo brak dostępu do katalogu mogą zatrzymać start całego silnika.

W systemie Windows należy porównać dziennik SQL Server z Podglądem zdarzeń, zwłaszcza z gałęziami związanymi z aplikacją i usługami systemowymi. SQL Server może zgłosić błąd otwarcia pliku, brak uprawnień konta usługi, nieprawidłowy parametr uruchomieniowy albo problem z alokacją zasobów. Podgląd zdarzeń może natomiast wskazać awarię procesu, błąd sterownika dysku, reset urządzenia magazynującego lub nieoczekiwane zatrzymanie usługi. Korelacja czasu wpisów jest ważniejsza niż pojedynczy komunikat wyświetlony przez aplikację kliencką.

Konfigurację instancji powinno się sprawdzać narzędziem SQL Server Configuration Manager, ponieważ korzysta ono z ustawień usług i protokołów właściwych dla SQL Server. Weryfikacji wymagają nazwa instancji, konto używane przez usługę, stan protokołu TCP/IP oraz przypisanie portu. Przy instancji domyślnej często analizuje się port TCP 1433, ale nie wolno zakładać, że każda instalacja używa właśnie tego portu. Instancja nazwana może korzystać z portu dynamicznego, a wtedy konieczne jest ustalenie rzeczywistego numeru portu w konfiguracji i dzienniku błędów.

Rozróżnienie awarii silnika od problemu połączenia

Jeżeli usługa instancji SQL Server jest zatrzymana, należy najpierw ustalić, czy zatrzymanie było skutkiem błędu podczas startu, ręcznego działania administratora, awarii systemu Windows czy automatycznego mechanizmu odzyskiwania. Sama próba ponownego uruchomienia może przywrócić działanie po chwilowym zakłóceniu, ale nie usuwa przyczyny. Wielokrotne restarty bez odczytania dzienników mogą dodatkowo utrudnić powiązanie komunikatu z pierwszym nieudanym uruchomieniem.

Gdy usługa działa, diagnostyka powinna rozdzielać problem procesu od problemu komunikacji. Połączenie lokalne i połączenie z innego komputera mogą dawać różne wyniki. Należy sprawdzić, czy klient używa prawidłowej nazwy serwera i instancji, czy rozpoznawany jest właściwy port oraz czy protokół TCP/IP jest aktywny dla tej instancji. Działająca usługa SQL Server nie gwarantuje dostępności zdalnej, ponieważ po drodze mogą wystąpić błędy konfiguracji protokołu, zapory systemowej albo parametrów połączenia.

Ważne jest także odróżnienie niedostępności całej instancji od niedostępności pojedynczej bazy. Silnik może działać, podczas gdy konkretna baza pozostaje w stanie RECOVERY_PENDING, RECOVERING, SUSPECT lub OFFLINE. W takiej sytuacji komunikat aplikacji może wyglądać podobnie do awarii usługi, lecz zakres problemu jest inny. Analiza powinna obejmować stan bazy, ostatnie operacje odzyskiwania oraz komunikaty dotyczące plików danych i dziennika transakcji. Nie należy odłączać, usuwać ani nadpisywać plików .mdf, .ndf i .ldf bez ustalenia ich roli oraz przygotowania kopii.

Bezpieczne postępowanie po zatrzymaniu SQL Server

Postępowanie naprawcze powinno rozpocząć się od zebrania nazwy instancji, czasu awarii, ostatnich zmian konfiguracyjnych oraz pełnych wpisów z dziennika błędów. Następnie sprawdza się dostępność katalogów wskazanych w parametrach uruchomieniowych, wolne miejsce na woluminach i możliwość odczytu oraz zapisu przez konto usługi. Należy również zweryfikować, czy pliki baz systemowych i użytkowych istnieją pod oczekiwanymi ścieżkami oraz czy nośnik nie raportuje błędów wejścia-wyjścia.

Jeżeli problem dotyczy konta usługi, zmiana hasła lub uprawnień powinna być wykonana w sposób zachowujący poprawną konfigurację SQL Server. Uprawnienie do logowania w systemie Windows nie jest tym samym co dostęp do katalogu z plikami baz danych. Konto usługi musi mieć wymagane prawa do lokalizacji używanych przez instancję, a zakres tych praw powinien odpowiadać rzeczywistej konfiguracji. Po zmianie ustawień trzeba ponownie sprawdzić dziennik startowy, aby potwierdzić, czy błąd ustąpił.

W przypadku podejrzenia uszkodzenia bazy systemowej, błędu dysku lub niezgodności plików konieczne jest zachowanie oryginalnych danych i ustalenie możliwości odtworzenia z prawidłowej kopii zapasowej. Naprawa plików bez rozpoznania przyczyny może pogorszyć stan bazy albo utrudnić późniejsze odzyskanie danych. Diagnostyka powinna zakończyć się potwierdzeniem uruchomienia właściwej instancji, dostępności wymaganych baz oraz poprawnego połączenia z aplikacją, a nie tylko zmianą stanu usługi Windows na „Uruchomiono”.