Awaria SQL Server

Awaria SQL Server to zdarzenie uniemożliwiające prawidłowe działanie tego systemu zarządzania bazami danych.

Na czym polega awaria SQL Server

Awaria SQL Server oznacza stan, w którym instancja Microsoft SQL Server, konkretna baza danych albo mechanizm obsługujący połączenia nie wykonuje prawidłowo swoich zadań. Objawem może być całkowity brak dostępu do serwera, niemożność uruchomienia usługi SQL Server, odrzucanie połączeń przez aplikacje, błędy odczytu i zapisu danych, bardzo długie wykonywanie zapytań albo przejście bazy do stanu suspect, recovery pending lub emergency. Awaria nie zawsze oznacza uszkodzenie plików bazy. Przyczyną może być także brak miejsca na woluminie, niedostępność systemu plików, blokady transakcji, wyczerpanie pamięci, błędna konfiguracja usługi lub problem z zależnością sieciową.

SQL Server przechowuje bazę przede wszystkim w plikach danych z rozszerzeniem .mdf i .ndf oraz w pliku dziennika transakcji .ldf. Podczas normalnej pracy zmiany są zapisywane w dzienniku przed zatwierdzeniem transakcji, co pozwala silnikowi odtworzyć spójność bazy po nieoczekiwanym zatrzymaniu. Jeżeli plik dziennika osiągnie limit rozmiaru, zabraknie miejsca na dysku lub dziennik zostanie uszkodzony, operacje modyfikujące dane mogą przestać działać, mimo że sama usługa SQL Server nadal będzie uruchomiona. Z tego powodu diagnoza powinna rozróżniać awarię procesu silnika, awarię konkretnej bazy oraz problem aplikacji korzystającej z bazy.

Objawy widoczne w usłudze, bazie i połączeniu

Pierwszym źródłem informacji jest SQL Server Error Log oraz Podgląd zdarzeń systemu Windows. W logu SQL Server mogą pojawić się komunikaty o nieudanym odzyskiwaniu bazy, błędach wejścia-wyjścia, braku uprawnień do pliku, niemożności otwarcia pliku bazy, przekroczeniu limitu dziennika lub zakończeniu procesu z powodu błędu. Do odczytu logu z poziomu połączenia administracyjnego można użyć procedury sp_readerrorlog. Jeżeli instancja nie przyjmuje połączeń, należy najpierw sprawdzić stan odpowiedniej usługi systemowej, nazwę instancji, konto usługi oraz podstawową dostępność hosta.

Błąd połączenia nie musi oznaczać uszkodzenia danych. Klient może próbować połączyć się z niewłaściwą instancją, używać nieprawidłowego portu albo wymagać protokołu, który nie jest włączony w konfiguracji SQL Server. W przypadku instancji domyślnej często używany jest port TCP 1433, ale numer portu może być zmieniony. Instancje nazwane mogą korzystać z portów dynamicznych, a usługa SQL Server Browser pomaga klientom ustalić port dla instancji nazwanej. Rozróżnienie błędu sieciowego od błędu uwierzytelniania i błędu stanu bazy wymaga analizy dokładnego kodu komunikatu, parametrów połączenia oraz logu serwera.

Bezpieczna kolejność czynności diagnostycznych

Najpierw należy zabezpieczyć stan zastany: odnotować czas wystąpienia problemu, komunikaty, ostatnie zmiany konfiguracyjne oraz dostępne kopie zapasowe. Nie powinno się rozpoczynać od usuwania plików .mdf lub .ldf, odłączania bazy ani uruchamiania poleceń naprawczych bez ustalenia przyczyny. Należy sprawdzić wolne miejsce na woluminach zawierających pliki danych, dzienniki i kopie zapasowe, a także dostępność ścieżek zapisanych w metadanych bazy. Warto zweryfikować stan baz w widoku sys.databases, zwracając uwagę między innymi na kolumnę state_desc, która pokazuje stan taki jak ONLINE, RECOVERING, RECOVERY_PENDING, SUSPECT lub EMERGENCY.

Integralność logiczną i fizyczną sprawdza się poleceniem DBCC CHECKDB, uruchamianym po ocenie wpływu operacji na obciążenie serwera. Wynik należy zachować, ponieważ informuje, czy wykryto niespójności stron, struktur indeksów lub metadanych. Opcje naprawcze, w szczególności REPAIR_ALLOW_DATA_LOSS, nie są zwykłą metodą odzyskiwania: mogą usunąć uszkodzone dane lub obiekty, aby przywrócić spójność strukturalną. Preferowanym sposobem odtworzenia uszkodzonej bazy jest przywrócenie poprawnej kopii pełnej oraz wymaganych kopii różnicowych i dziennika transakcji, o ile taki łańcuch kopii istnieje i jest dostępny.

Odtworzenie działania i kontrola po awarii

Po usunięciu bezpośredniej przyczyny trzeba sprawdzić nie tylko możliwość zalogowania się do instancji, lecz także pełny przepływ pracy aplikacji. Kontroli wymagają stan bazy, dostępność użytkowników i ról, wykonywanie odczytów oraz zapisów, działanie zadań SQL Server Agent, poprawność harmonogramów kopii zapasowych i dostępność przestrzeni dla kolejnych plików dziennika. Jeżeli awaria wynikała z przepełnienia logu, należy ustalić przyczynę jego wzrostu, na przykład długo trwającą transakcję albo brak kopii dziennika w modelu odzyskiwania FULL. Samo zmniejszenie pliku poleceniem DBCC SHRINKFILE nie rozwiązuje przyczyny i nie powinno zastępować prawidłowego planu pojemności.

Po zakończeniu diagnostyki należy wykonać kontrolowaną kopię zapasową oraz zweryfikować jej odtwarzalność na przeznaczonym do tego środowisku. Warto również przeanalizować zależności między serwerem SQL Server, aplikacją, usługą systemową i pamięcią masową, ponieważ ponowny start usługi może chwilowo ukryć problem. Dokumentacja powinna zawierać nazwę instancji, lokalizacje plików, model odzyskiwania baz, harmonogram kopii, ostatnie komunikaty z Error Log oraz czynności wykonane podczas przywracania. Takie dane pozwalają odróżnić jednorazowe zatrzymanie procesu od powtarzalnej awarii wymagającej korekty konfiguracji, infrastruktury dyskowej albo procedur tworzenia i testowania kopii zapasowych.