Polecenie DBCC CHECKDB ('sklepAGD', REPAIR_REBUILD) w MS SQL Server
Opracowane na podstawie zadania CKE, styczeń 2016 (arkusz E.14-X-16.01): W arkuszu była opcja Repair_fast. Od SQL Server 2005 REPAIR_FAST niczego nie naprawia (zostawiono ją tylko dla zgodności), dlatego zamieniono ją na REPAIR_REBUILD.
Poprawna jest odpowiedź, że polecenie sprawdzi spójność bazy danych i naprawi uszkodzone indeksy. DBCC CHECKDB kontroluje logiczną i fizyczną integralność wszystkich obiektów wskazanej bazy - tu bazy sklepAGD. Opcja REPAIR_REBUILD wykonuje naprawy bez ryzyka utraty danych, np. uzupełnia brakujące wpisy w indeksach nieklastrowanych albo przebudowuje uszkodzony indeks.
Do zapamiętania: opcje naprawy wymagają trybu jednego użytkownika (ALTER DATABASE sklepAGD SET SINGLE_USER). Najostrzejsza opcja REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone dane, więc stosuje się ją w ostateczności, a najpierw próbuje się odtworzyć bazę z kopii. Opcja REPAIR_FAST z dawnych wersji dziś niczego nie naprawia - została tylko dla zgodności składni.
Kluczem do tego pytania jest zakres polecenia. DBCC CHECKDB zawsze dotyczy całej bazy danych, której nazwę podano w nawiasie, więc odpowiedzi mówiące o „określonej tabeli” opisują inne polecenie - DBCC CHECKTABLE, które sprawdza pojedynczą tabelę lub widok indeksowany. Wariant z naprawą uszkodzonych rekordów jest dodatkowo błędny co do rodzaju naprawy: REPAIR_REBUILD wykonuje tylko naprawy bez utraty danych, przede wszystkim w indeksach.
Odpowiedź z kopią bezpieczeństwa myli kontrolę spójności z wykonywaniem kopii. DBCC niczego nie archiwizuje - kopię zapasową tworzy się poleceniem BACKUP DATABASE, a odtwarza RESTORE DATABASE. W praktyce kolejność bywa taka: najpierw kontrola spójności, potem kopia, żeby nie zarchiwizować uszkodzonej bazy - ale to dwa osobne polecenia. Warto zapamiętać trzy skróty z rodziny DBCC: CHECKDB (cała baza), CHECKTABLE (jedna tabela), CHECKALLOC (przydział stron na dysku).