Naprawa indeksów po EMERGENCY

Naprawa indeksów po trybie EMERGENCY to odbudowa struktur wyszukiwania po ratunkowym uruchomieniu uszkodzonej bazy.

EMERGENCY w SQL Server i jego skutki dla struktur indeksowych

Tryb EMERGENCY w Microsoft SQL Server jest stanem awaryjnym ustawianym dla bazy danych, która nie może zostać normalnie otwarta. Polecenie ALTER DATABASE [nazwa_bazy] SET EMERGENCY zmienia stan bazy na awaryjny i pozwala administratorowi uzyskać ograniczony dostęp diagnostyczny. Nie jest to naprawa danych ani automatyczna odbudowa indeksów. Tryb ten służy przede wszystkim do przeprowadzenia czynności ratunkowych, oceny spójności oraz zebrania informacji o stanie plików danych i dziennika transakcji.

Po awaryjnym uruchomieniu baza może zawierać niespójne strony danych, uszkodzone wpisy w indeksach, rozbieżności między indeksem klastrowanym a stronami tabeli albo problemy z metadanymi. Indeks jest strukturą pomocniczą, ale w SQL Server indeks klastrowany wyznacza fizyczną organizację danych tabeli. Dlatego nie można zakładać, że każdą usterkę naprawi zwykłe polecenie przebudowy indeksu. Najpierw trzeba ustalić, czy problem dotyczy wyłącznie struktury indeksowej, czy również danych bazowych.

Kontrola spójności przed odbudową indeksów

Podstawowym narzędziem oceny stanu bazy jest DBCC CHECKDB. Dla wstępnej kontroli warstwy fizycznej można użyć DBCC CHECKDB (N'nazwa_bazy') WITH PHYSICAL_ONLY. Opcja ta ogranicza zakres sprawdzania do kontroli fizycznej stron, rekordów i nagłówków, dlatego jest przydatna przy dużych bazach lub podejrzeniu problemów z nośnikiem. Nie zastępuje jednak pełnej kontroli logicznej. Pełne DBCC CHECKDB (N'nazwa_bazy') WITH NO_INFOMSGS analizuje także relacje między tabelami, indeksami, alokacją oraz strukturami systemowymi.

Wynik kontroli należy zachować przed wykonaniem zmian. Szczególne znaczenie mają komunikaty wskazujące na uszkodzenie określonego obiektu, numeru indeksu, identyfikatora obiektu, strony lub alokacji. Jeżeli SQL Server zgłasza niespójność indeksu nieklastrowanego, możliwym działaniem naprawczym jest usunięcie i ponowne utworzenie tego indeksu albo jego przebudowa. Jeżeli komunikat dotyczy indeksu klastrowanego, tabeli, stron danych lub alokacji, operacja jest bardziej ryzykowna, ponieważ struktura indeksu jest bezpośrednio związana z przechowywaniem rekordów.

Odbudowa indeksów i granice bezpiecznej naprawy

Po potwierdzeniu, że dane i alokacja są spójne, odbudowę konkretnego indeksu można wykonać poleceniem ALTER INDEX [nazwa_indeksu] ON [schemat].[tabela] REBUILD. Dla wszystkich indeksów tabeli stosuje się wariant ALTER INDEX ALL ON [schemat].[tabela] REBUILD. Odbudowa tworzy strukturę indeksu ponownie na podstawie danych tabeli, usuwa fragmentację i może naprawić logiczne problemy ograniczone do indeksu. Wymaga jednak odpowiedniej ilości wolnego miejsca, czasu oraz dostępu do bazy w zakresie zależnym od rodzaju operacji i konfiguracji SQL Server.

Nie należy uruchamiać odbudowy wszystkich indeksów bez wskazania obiektów i bez analizy komunikatów DBCC CHECKDB. Przebudowa nie naprawi uszkodzonych stron danych, błędów alokacji ani problemów z plikiem dziennika transakcji. Nie powinna też zastępować odtworzenia prawidłowej kopii zapasowej. Opcja REPAIR_ALLOW_DATA_LOSS w poleceniu DBCC CHECKDB jest środkiem ostatecznym, ponieważ SQL Server może usunąć uszkodzone struktury lub strony, aby przywrócić spójność formalną bazy. Przed jej rozważeniem należy wykonać kopię plików i ocenić możliwość odtworzenia pełnej, różnicowej oraz dziennikowej kopii zapasowej.

Weryfikacja po zakończeniu prac

Po odbudowie indeksów należy ponownie wykonać pełne DBCC CHECKDB i porównać wynik z raportem początkowym. Brak komunikatów o błędach nie oznacza jeszcze, że aplikacja odzyskała pełną funkcjonalność. Trzeba sprawdzić możliwość odczytu tabel, działanie kluczy głównych i indeksów unikatowych, poprawność zapytań korzystających z uszkodzonych wcześniej obiektów oraz stan transakcji pozostawionych przed awaryjnym zatrzymaniem. W przypadku tabel objętych kluczami obcymi warto dodatkowo zweryfikować spójność logiczną danych na poziomie aplikacji.

Naprawa indeksów po EMERGENCY jest więc etapem kontrolowanego odtwarzania działania bazy, a nie pojedynczą czynnością administracyjną. Analiza powinna obejmować stan plików MDF i NDF, dostępność pliku LDF, komunikaty SQL Server, kopie zapasowe oraz skutki każdej operacji naprawczej. W środowisku lokalnym diagnostyka i odbudowa struktur może wymagać pracy na kopii bazy, aby zachować możliwość porównania danych i ograniczyć ryzyko dalszej utraty rekordów.