Polecenie DBCC CHECKDB ('sklepAGD') wykonane w MS SQL Server bez żadnej opcji naprawy
DBCC CHECKDB sprawdza całą bazę: strukturę stron danych, indeksy, powiązania między obiektami i poprawność zapisanych wartości. Wywołane z samą nazwą bazy działa wyłącznie diagnostycznie. Wypisuje raport, a na końcu informację, ile znalazło błędów spójności, i nie zmienia żadnych danych.
Naprawę trzeba zamówić jawnie drugim argumentem: REPAIR_REBUILD przebudowuje uszkodzone indeksy bez utraty danych, a REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone strony. Opcje naprawy wymagają przełączenia bazy w tryb jednego użytkownika. Administratorzy uruchamiają samo sprawdzenie regularnie, np. raz w tygodniu, żeby wcześnie wykryć uszkodzenia dysku.
Wynik bez błędów kończy się komunikatem o zerowej liczbie błędów alokacji i spójności.
Każda z błędnych odpowiedzi przypisuje poleceniu zadanie, którego bez dodatkowych opcji nie wykonuje albo nie wykonuje nigdy. Automatyczna naprawa indeksów zachodzi dopiero z opcją REPAIR_REBUILD. Bez niej DBCC CHECKDB jedynie informuje, że indeks jest uszkodzony.
Usuwanie uszkodzonych rekordów może nastąpić tylko z opcją REPAIR_ALLOW_DATA_LOSS, której nazwa ostrzega przed utratą danych. Zwykłe sprawdzenie niczego nie kasuje.
Kopię bezpieczeństwa w MS SQL Server tworzy osobne polecenie BACKUP DATABASE sklepAGD TO DISK = 'D:\kopie\sklep.bak', a przywraca RESTORE DATABASE. DBCC CHECKDB z kopiami nie ma nic wspólnego, choć dobrze jest sprawdzić spójność bazy przed jej archiwizacją.
Przed naprawą z możliwą utratą danych zawsze wykonuje się kopię bazy.
Zapamiętaj: CHECKDB samo z siebie tylko sprawdza, a każda naprawa wymaga słowa REPAIR w poleceniu.