Procedury naprawcze Microsoft

Procedury naprawcze Microsoft to oficjalne wytyczne producenta dotyczące rozwiązywania typowych awarii SQL Server.

Zakres procedur naprawczych Microsoft dla SQL Server

Procedury naprawcze Microsoft dla SQL Server opisują sposób rozpoznawania i usuwania problemów związanych z silnikiem relacyjnej bazy danych, usługą SQL Server, bazami użytkownika oraz elementami systemu Windows, od których zależy działanie instancji. Nie są pojedynczą komendą ani uniwersalnym skryptem. Dobiera się je do objawu, komunikatu błędu, wersji SQL Server, trybu uwierzytelniania, konfiguracji instancji oraz stanu konkretnej bazy danych.

Oficjalne zalecenia zwykle wymagają rozpoczęcia od zebrania dowodów: logu błędów SQL Server, dziennika zdarzeń systemu Windows, informacji o stanie usługi, komunikatów z aplikacji oraz wyników zapytań diagnostycznych. Istotne jest rozróżnienie awarii samego silnika od problemu z połączeniem, uprawnieniami, miejscem na dysku, plikami baz danych, kopią zapasową albo zależnością systemową. Naprawa wykonana bez takiego rozpoznania może ukryć przyczynę lub doprowadzić do utraty danych.

Log błędów, usługa i pierwsze rozpoznanie

Jednym z podstawowych źródeł informacji jest SQL Server Error Log. Zawiera on między innymi komunikaty o uruchamianiu i zatrzymywaniu instancji, błędach otwierania plików baz danych, problemach z pamięcią, nieudanych próbach logowania oraz błędach zapisu. Log można przeglądać w SQL Server Management Studio w węźle Management, a także odczytywać procedurą systemową sp_readerrorlog. Przy analizie trzeba uwzględnić czas wystąpienia zdarzenia, nazwę bazy, numer komunikatu i pełny tekst błędu, ponieważ pojedynczy wpis często jest skutkiem wcześniejszego problemu.

Jeżeli usługa SQL Server nie uruchamia się, sprawdza się konto usługi, parametry startowe, dostęp do katalogów zawierających pliki danych i logów transakcyjnych oraz dostępność wolnego miejsca. W SQL Server Configuration Manager można zweryfikować nazwę usługi i konfigurację uruchamiania. Przydatne są także parametry startowe instancji, ponieważ błędna ścieżka do pliku master, model lub msdb może uniemożliwić prawidłowy start. Uruchomienie z parametrem minimalnej konfiguracji albo w trybie pojedynczego użytkownika jest procedurą awaryjną i powinno być stosowane wyłącznie zgodnie z dokumentacją oraz po zabezpieczeniu kopii danych.

Spójność bazy i odtwarzanie z kopii

Do sprawdzania logicznej i fizycznej spójności bazy SQL Server służy DBCC CHECKDB. Polecenie analizuje między innymi struktury stron, alokację, indeksy i relacje między elementami bazy. Wynik należy zachować w całości, ponieważ zalecane dalsze działanie zależy od rodzaju wykrytego uszkodzenia. Najbezpieczniejszą metodą odzyskania spójnej bazy jest odtworzenie jej z prawidłowego łańcucha kopii zapasowych, obejmującego odpowiednią kopię pełną oraz, zależnie od modelu odzyskiwania, kopie różnicowe i dziennika transakcji.

Opcje naprawcze DBCC CHECKDB z klauzulą REPAIR_ALLOW_DATA_LOSS nie są zwykłym sposobem konserwacji. Mogą usunąć uszkodzone struktury lub dane potrzebne do przywrócenia spójności, dlatego Microsoft wskazuje je jako rozwiązanie ostateczne, stosowane po wykonaniu kopii plików i po rozważeniu odtworzenia z backupu. Przed każdą operacją należy ustalić, czy problem dotyczy fizycznego uszkodzenia nośnika, błędów systemu plików, wadliwej pamięci, przerwanego zapisu czy wyłącznie niespójności logicznej. Sama naprawa struktur bazy nie usuwa przyczyny sprzętowej.

Kontrola po naprawie SQL Server

Po wykonaniu procedury naprawczej trzeba potwierdzić, że instancja działa w sposób powtarzalny. Weryfikuje się stan usługi, dostęp do baz, możliwość wykonania zapytań, logowanie wymaganych kont, działanie zadań SQL Server Agent oraz poprawność operacji tworzenia i odtwarzania kopii zapasowych. Należy również ponownie przejrzeć SQL Server Error Log i dziennik zdarzeń Windows, aby sprawdzić, czy po restarcie nie pojawiają się te same komunikaty.

Kontrola nie powinna ograniczać się do pomyślnego uruchomienia aplikacji. Warto porównać liczbę i stan baz przed oraz po operacji, sprawdzić wyniki DBCC CHECKDB, zweryfikować dostępność plików danych i logów oraz potwierdzić, że połączenia kierują do właściwej instancji. Jeżeli problem był związany z brakiem miejsca, uprawnieniami lub nośnikiem, trzeba potwierdzić usunięcie tej przyczyny, a nie tylko ponowne uruchomienie usługi. Dokumentacja wykonanych czynności ułatwia późniejsze odtworzenie środowiska i ocenę, czy awaria była jednorazowa, czy wskazuje na trwałą usterkę.