Naprawa bazy danych to próba usunięcia uszkodzeń strukturalnych poleceniem DBCC CHECKDB z odpowiednią opcją naprawy.
Na czym polega naprawa bazy danych w SQL Server
Naprawa bazy danych w Microsoft SQL Server jest działaniem wykonywanym po wykryciu niespójności struktur przechowywanych w plikach bazy. Podstawowym narzędziem diagnostycznym jest polecenie DBCC CHECKDB. Sprawdza ono między innymi spójność logiczną i fizyczną stron danych, poprawność powiązań między tabelami i indeksami, strukturę metadanych oraz zgodność informacji zapisanych w pliku danych z wewnętrznymi regułami silnika SQL Server. Samo wykrycie komunikatu o błędzie wejścia-wyjścia nie oznacza jeszcze uszkodzenia logicznego bazy, dlatego wynik kontroli trzeba interpretować razem z informacjami z dziennika SQL Server i systemu operacyjnego.
Do sprawdzenia można użyć polecenia DBCC CHECKDB (NazwaBazy) WITH NO_INFOMSGS, które ogranicza wyświetlanie komunikatów informacyjnych. W praktyce ważne są numery błędów, poziom ważności oraz końcowe zalecenie dotyczące możliwej opcji naprawy. SQL Server może wskazać między innymi REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST albo REPAIR_REBUILD. Te opcje nie są równoważne: każda z nich oznacza inny zakres ingerencji w struktury bazy i może prowadzić do innych skutków dla danych.
Rozpoznanie rodzaju niespójności przed ingerencją
Najważniejszym etapem jest ustalenie, czy problem dotyczy pojedynczego indeksu, struktury tabeli, metadanych, stron danych, alokacji czy pliku bazy. Nie każda niespójność wymaga użycia polecenia naprawczego. Jeżeli problem ogranicza się do indeksu, często wystarcza jego odbudowanie poleceniem ALTER INDEX albo odtworzenie indeksu na podstawie poprawnych danych tabeli. Opcja REPAIR_REBUILD może naprawiać problemy, które nie wiążą się z utratą danych, lecz jej zastosowanie powinno wynikać bezpośrednio z raportu DBCC CHECKDB.
Przed każdą próbą naprawy należy wykonać kopię zapasową, o ile stan bazy i dostępne zasoby na to pozwalają. W przypadku uszkodzenia logicznego najbezpieczniejszą metodą odzyskania spójnego stanu jest przywrócenie bazy z poprawnego backupu pełnego, a następnie zastosowanie kopii różnicowej i dzienników transakcyjnych, jeżeli taki model ochrony był skonfigurowany. Przywrócenie kopii zachowuje oryginalną strukturę danych z momentu wykonania backupu. Naprawa struktury na miejscu może natomiast zmienić albo usunąć elementy, których SQL Server nie potrafi jednoznacznie odtworzyć.
Opcje DBCC i ryzyko utraty informacji
REPAIR_FAST jest historyczną opcją przeznaczoną do drobnych i szybkich korekt, natomiast REPAIR_REBUILD dotyczy wybranych problemów możliwych do usunięcia przez odbudowę struktur indeksowych. Największe ryzyko wiąże się z REPAIR_ALLOW_DATA_LOSS. Nazwa tej opcji nie jest ostrzeżeniem formalnym bez znaczenia: SQL Server może usunąć uszkodzone rekordy, strony, wpisy alokacji albo elementy struktury, aby doprowadzić bazę do stanu uznawanego przez silnik za spójny. Baza może wtedy zostać uruchomiona, ale część informacji może nie być już dostępna.
Przykładowe polecenie DBCC CHECKDB (NazwaBazy, REPAIR_ALLOW_DATA_LOSS) nie powinno być traktowane jako standardowa procedura po każdym błędzie. Przed użyciem trzeba zatrzymać procesy zapisujące dane, ustalić możliwy zakres utraty informacji i zapisać pełny wynik kontroli. Po naprawie należy ponownie uruchomić DBCC CHECKDB bez opcji naprawy, sprawdzić liczbę i zawartość kluczowych tabel, zweryfikować więzy integralności oraz przeanalizować błędy zgłaszane przez aplikację. Sam komunikat o zakończeniu polecenia bez błędu nie potwierdza, że wszystkie dane biznesowe zostały zachowane.
Odtworzenie spójności i kontrola po naprawie
Po usunięciu niespójności warto porównać stan bazy z ostatnią poprawną kopią zapasową lub innym wiarygodnym źródłem danych. Kontrola powinna obejmować nie tylko możliwość otwarcia bazy, lecz także działanie zapytań odczytujących dane, zapis nowych rekordów, działanie kluczy głównych, więzów obcych, widoków, procedur składowanych i indeksów. Jeżeli naprawa usunęła uszkodzone fragmenty, aplikacja może nadal działać technicznie, ale zwracać niepełne wyniki albo odrzucać operacje odnoszące się do brakujących rekordów.
Wynik DBCC CHECKDB należy zachować wraz z datą wykonania, nazwą bazy, wersją SQL Server, informacjami o plikach danych i dziennika oraz opisem podjętych działań. Gdy przyczyną problemu są błędy sprzętowe, wadliwy nośnik, kontroler, pamięć masowa albo powtarzające się błędy wejścia-wyjścia, sama naprawa logiczna nie usuwa źródła awarii. Konieczne jest wtedy sprawdzenie dzienników systemowych, stanu dysków, komunikatów sterowników i poprawności kopii zapasowych. W przeciwnym razie uszkodzenie może pojawić się ponownie, nawet jeśli bieżąca kontrola zakończy się bez komunikatów o niespójności.
