DBCC CHECKDB: Kompletny przewodnik po MS SQL Server Stan bazy danych (2025)

Uszkodzenie bazy danych jest powszechne SQL Server koszmar administratora. Gdy krytyczne dane biznesowe stają się niedostępne lub niepewne, cost może być dewastujące. Ten kompleksowy przewodnik obejmuje wszystko, co musisz wiedzieć o używaniu DBCC CHECKDB do utrzymania kondycji bazy danych i zapobiegania jej uszkodzeniu, a także zaawansowane rozwiązania odzyskiwania na wypadek, gdy standardowe narzędzia nie wystarczają.

1. Ważność SQL Server Stan bazy danych

1.1 Jakie uszkodzenie bazy danych Costs Firmy

Dzisiaj most firmy przechowują swoje krytyczne dane w bazach danych. Gdy dochodzi do uszkodzenia bazy danych, konsekwencje są katastrofalne:

• Straty finansowe średnio 2.3 mln USD rocznie z powodu utraty danych, przy czym głównymi przyczynami są awarie sprzętu i uszkodzenia (EMC Corporation)
• Wskaźniki zamykania firm pokazują, że 50% małych firm, które doświadczyły utraty danych z powodu awarii sprzętu, upada w ciągu dwóch lat, podczas gdy 94% firm, które doświadczyły katastrofalnej utraty danych, w ogóle nie przetrwa
• Częstotliwość uszkodzenia danych dotyczy 20% aplikacji o znaczeniu krytycznym rocznie, powodując zakłócenia w ciągłości działania firmy (badania Gartnera)
• Uszkodzenie sprzętu odpowiada za 67% wszystkich przypadków utraty danych z powodu awarii dysku twardego i awarii systemu, przy czym 40% utraty danych jest bezpośrednio związane z awariami sprzętu
• Uszkodzenie oprogramowania costs wahają się od tysięcy do milionów dolarów w zależności od powagi i zakresu, przy czym 82% firm doświadczyło nieplanowanych przerw, w których główną przyczyną była korupcja

1.2 Dlaczego regularne kontrole zdrowia są tak ważne

Ludzie potrzebują regularnych badań kontrolnych, aby wcześnie wykryć potencjalne choroby. Podobnie bazy danych również potrzebują regularnych badań kontrolnych:

1. Wykrywaj potencjalne przypadki korupcji na wczesnym etapie i reaguj na nie bezzwłocznie, zapobiegając w ten sposób poważnym i powszechnym problemom, które mogłyby mieć katastrofalne skutki dla firmy.
2. Upewnij się, że baza danych działa z optymalną wydajnością.
3. Cost skuteczność proaktywnych kontroli stanu bazy danych jest znacznie niższa niż skuteczność reaktywnego odzyskiwania danych po wystąpieniu awarii bazy danych.

1.3 Wprowadzenie do poleceń integralności bazy danych

SQL Server zapewnia kilka wbudowanych poleceń służących do utrzymania kondycji bazy danych, DBCC CHECKDB służąc jako most dostępne kompleksowe narzędzie do sprawdzania integralności. Te polecenia współpracują ze sobą, aby zweryfikować różne aspekty struktury bazy danych, od pojedynczych tabel po spójność całej bazy danych, tworząc kompletną strategię konserwacji, która zapewnia bezpieczeństwo i dostępność danych.

2. Co to jest DBCC CHECKDB

DBCC CHECKDB is SQL ServerPodstawowe narzędzie służące do weryfikacji integralności bazy danych i identyfikacji problemów związanych z uszkodzeniem.

• Jest to polecenie T-SQL, a nie narzędzie GUI.
• Można go wykonać za pomocą typowych metod, takich jak: SQL Server Studio zarządzania (SSMS), SQL Server Agent, SQLCMD, itp.

2.1 Co CHECKDB faktycznie sprawdza w Twojej bazie danych

Po uruchomieniu polecenia DBCC CHECKDB przeprowadzane są liczne warstwy walidacji w całej strukturze bazy danych:

• Weryfikacja sum kontrolnych stron w celu wykrycia uszkodzeń fizycznych i problemów związanych ze sprzętem
• Walidacja spójności indeksu aby zapewnić prawidłowe pobieranie danych i wydajność zapytań
• Sprawdzanie struktury alokacji aby potwierdzić dokładne wykorzystanie przestrzeni i przydział stron
• Badanie integralności referencyjnej między powiązanymi tabelami i relacjami kluczy obcych
• Walidacja spójności tabeli systemowej w celu zapewnienia SQL Serverwewnętrzne metadane pozostają niezawodne
• Weryfikacja powiązania stron danych aby potwierdzić prawidłową integralność łańcucha stron
• Spójność schematu bazy danych w celu sprawdzenia definicji obiektów i zależności

Te kompleksowe kontrole obejmują zarówno dane użytkowników, jak i struktury systemowe, zapewniając pełną widoczność stanu bazy danych.

3. Uruchamianie DBCC CHECKDB: krok po kroku

Wymagania wstępne 3.1

Poniżej znajduje się lista kontrolna, którą należy wykonać przed wykonaniem jakiejkolwiek operacji DBCC CHECKDB:

• Pełna kopia zapasowa bazy danych – Przed uruchomieniem kontroli integralności utwórz pełną kopię zapasową, która będzie stanowić zabezpieczenie na wypadek wykrycia uszkodzenia lub konieczności przeprowadzenia operacji naprawczych.
• Właściwe uprawnienia – Do wykonywania poleceń DBCC CHECKDB wymagane są uprawnienia sysadmin lub db_owner
• Wystarczające zasoby systemowe:
  • Pamięć: 25% rozmiaru bazy danych
  • Przestrzeń Tempdb: 10-15% rozmiaru bazy danych
  • CPU: 50-70% dostępności podczas konserwacji
  • I/O: spodziewaj się intensywnych operacji odczytu
• Dostępność bazy danych – Sprawdź, czy baza danych jest dostępna i czy nie znajduje się w stanie ograniczonym, ponieważ CHECKDB wymaga dostępu do odczytu wszystkich stron bazy danych

3.2 Podstawowe polecenia

Most Podstawowe polecenie DBCC CHECKDB obejmuje trzy popularne warianty:

(1) Sprawdź bieżącą bazę danych (bez parametrów):

DBCC CHECKDB

(2) Sprawdź bazę danych według nazwy:

DBCC CHECKDB ('YourDatabaseName')

(3) Sprawdź bazę danych według ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

To podstawowe polecenie wykonuje pełną kontrolę integralności określonej bazy danych, badając wszystkie tabele, indeksy i struktury systemowe. W przypadku baz danych o standardowych nazwach niezawierających spacji można pominąć cudzysłowy. Polecenie będzie wykonywane do zakończenia, wyświetlając komunikaty o postępie i wyniki końcowe. Ta podstawowa składnia działa doskonale w przypadku mniejszych baz danych lub gdy masz wystarczająco dużo czasu na konserwację.

Poniżej znajduje się zrzut ekranu uruchamiania DBCC CHECKDB w SQL Server Studio Zarządzania (SSMS):

3.3 Opcje kompletne

Poniżej znajdują się kompletne opcje dla DBCC CHECKDB:

Kategoria	Option	Opis	Przykład DBCC CHECKDB
Opcje naprawy	REPAIR_REBUILD	Naprawy bez utraty danych (np. odbudowa indeksu)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Brak napraw. Tylko wsteczna kompatybilność.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Naprawia wszystkie błędy (mogą spowodować utratę danych)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kontrola zakresu	NOINDEX	Pomija sprawdzanie indeksów nieklastrowanych	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Sprawdza tylko integralność pamięci fizycznej (strony/rekordy)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Sprawdzanie logicznych błędów wartości kolumn (np. nieprawidłowych dat)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Głębokie kontrole logiczne (widoki indeksowane, indeksy XML/przestrzenne)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kontrola wyjścia	ALL_ERRORMSGS	Pokazuje wszystkie błędy (domyślnie: 200 na obiekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Ukrywa wiadomości informacyjne	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Wydajność	TABLOCK	Używa blokad tabel (zmniejsza użycie TempDB, ale blokuje zapisy)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Nadpisuje ustawienia paralelizmu	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Użyteczność	ESTIMATEONLY	Szacuje potrzebną przestrzeń TempDB. (bez faktycznego sprawdzenia)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Zrozumienie wyników

DBCC CHECKDB wygeneruje różne wyniki w zależności od tego, czy jego wykonanie zakończy się pomyślnie, czy nie. Wyjaśnijmy je szczegółowo.

4.1 Wykonanie CHECKDB zakończyło się pomyślnie

Jeśli wykonanie polecenia DBCC CHECKDB zakończy się pomyślnie, zostaną wyświetlone różne typy wyników, w zależności od stanu bazy danych.

4.1.1 Nie znaleziono problemów

Jeśli DBCC CHECKDB nie znajdzie żadnych problemów, zobaczysz dane wyjściowe podobne do następujących:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Wynik ten oznacza, że ​​baza danych zachowuje idealną integralność we wszystkich sprawdzanych strukturach.

4.1.2 Znaleziono błędy uszkodzenia

Za każdym razem, gdy DBCC CHECKDB wykryje błąd uszkodzenia, wyświetli komunikat o błędzie o następującej strukturze:
Przewodnik po poziomach ważności:

• Poziom 16-19: Błędy, które użytkownik może naprawić, często drobne uszkodzenia
• Poziom 20-24: Błędy systemowe, poważne uszkodzenia wymagające natychmiastowej uwagi
• Poziom 25: Błędy krytyczne, baza danych może być niedostępna

Typowe błędy obejmują:

• Błędy sumy kontrolnej strony (komunikat 824)
• Błędy alokacji (komunikat 8928)
• Problemy ze spójnością indeksu (wiadomość 8964)

Zrozumienie struktury wiadomości pozwala ustalić priorytety działań reagowania i określić odpowiednie strategie odzyskiwania.

4.1.3 Typowe komunikaty informacyjne i ostrzegawcze

Nie wszystkie dane wyjściowe DBCC CHECKDB wskazują na poważne problemy. Może również wyprowadzać pewne komunikaty informacyjne i ostrzegawcze, w tym:

• Oświadczenia dotyczące naprawy – Wiadomości sugerujące polecenia naprawy w celu rozwiązania drobnych problemów
• Ostrzeżenia dotyczące alokacji – Ostrzeżenia dotyczące przydziału miejsca, które nie mają wpływu na dostęp do danych
• Zalecenia dotyczące wydajności – Sugestie dotyczące utrzymania i optymalizacji indeksu
• Powiadomienia informacyjne – Ogólne komunikaty o stanie, które nie wymagają natychmiastowego działania

Komunikaty te zawierają cenne wskazówki dotyczące konserwacji, a także pozwalają na rozróżnienie poważnych uszkodzeń wymagających natychmiastowej reakcji oraz mniej istotnych problemów, które można rozwiązać w trakcie regularnych przeglądów technicznych.

Przykładowy komunikat ostrzegawczy:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 Przerwanie wykonywania CHECKDB

Jeżeli CHECKDB przerwie działanie z różnych przyczyn, wyświetli komunikat o błędzie i doda dziennik błędów z poniższym kodem stanu:

Miasto	Opis
0	Został zgłoszony błąd numer 8930. Wskazuje to na uszkodzenie metadanych, które zakończyło polecenie DBCC.
1	Podniesiono błąd numer 8967. Wystąpił wewnętrzny błąd DBCC.
2	Wystąpił błąd podczas naprawy bazy danych w trybie awaryjnym.
3	Oznacza to uszkodzenie metadanych, które spowodowało zakończenie polecenia DBCC.
4	Wykryto naruszenie zasad lub dostępu.
5	Wystąpił nieznany błąd, który zakończył polecenie DBCC.

Przykładowy komunikat o błędzie:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

or

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Przykładowy dziennik błędów:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

W takim przypadku możesz wypróbować alternatywne opcje zaawansowane, takie jak: DataNumen SQL Recovery aby naprawić uszkodzenie w bazie danych.

5. Naprawianie błędów korupcyjnych

5.1 Kopia zapasowa i przywracanie: najbezpieczniejsze rozwiązanie

Gdy DBCC CHECKDB zidentyfikuje błędy uszkodzenia, przywrócenie danych z czystej kopii zapasowej jest najbezpieczniejszym i najbezpieczniejszym rozwiązaniem.ost niezawodne rozwiązanie. To podejście gwarantuje integralność danych, eliminując jednocześnie przyczyny uszkodzeń. Przed przywróceniem sprawdź integralność kopii zapasowej za pomocą PRZYWRÓĆ TYLKO WERYFIKUJ polecenia i rozważ opcje odzyskiwania w określonym punkcie w czasie, aby zminimalizować utratę danych. Udokumentuj szczegóły uszkodzenia w celu analizy przyczyn źródłowych, ponieważ problemy sprzętowe lub błędy oprogramowania mogą wymagać dodatkowej uwagi, aby zapobiec ich ponownemu wystąpieniu.

5.2 Rozwiązania problemów z korupcją na poziomie strony

W przypadku odizolowanego uszkodzenia strony, które wpływa na niewielkie fragmenty danych, SQL Server Enterprise Edition oferuje możliwości przywracania stron, które naprawiają określone uszkodzone strony bez pełnego przywracania bazy danych. Ta zaawansowana technika wymaga pełnego modelu odzyskiwania i bieżących kopii zapasowych dziennika.

Proces przywracania strony krok po kroku:

1. Zidentyfikuj uszkodzoną stronę z komunikatu o błędzie CHECKDB (np. strona 1:256)
2. Wykonaj kopię zapasową bieżącego dziennika aby przechwycić ostatnie transakcje:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Przywróć uszkodzoną stronę z most ostatnia pełna kopia zapasowa:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Zastosuj różnicową kopię zapasową (Jeśli możliwe):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Zastosuj wszystkie kopie zapasowe dziennika po kolei, włączając ten właśnie utworzony:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Wykonaj ostateczną kopię zapasową dziennika i przywróć aby zaktualizować stronę:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternatywa dla danych niekrytycznych: Jeśli uszkodzenie dotyczy danych niekrytycznych, możesz wyeksportować nienaruszone wiersze do nowych tabel przed odbudową uszkodzonych struktur:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Szybkie poprawki uszkodzenia indeksu

Uszkodzenie indeksu często dobrze reaguje na operacje odbudowy, które odtwarzają struktury indeksów bez wpływu na podstawowe dane tabeli:

ALTER INDEX ALL ON YourTable REBUILD

To podejście sprawdza się szczególnie dobrze w przypadku uszkodzeń indeksu nieklastrowego, gdyż odbudowa polega na ponownym wygenerowaniu stron indeksu na podstawie danych z tabeli źródłowej, co skutecznie eliminuje uszkodzenia, a jednocześnie zachowuje wszystkie oryginalne informacje.

6. Użyj REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS

Jeżeli wszystkie poprzednie metody zawiodą lub okażą się niemożliwe, możesz użyć opcji REPAIR_REBUILD i REPAIR_ALLOW_DATA_LOSS w celu naprawy bazy danych.

6.1 REPAIR_REBUILD (bezpieczniejsza opcja):

• Używać do: Uszkodzenie indeksu i drobne błędy alokacji
• Bezpieczeństwo danych: Próby naprawienia uszkodzeń bez usuwania danych
• Poziom ryzyka: Niski – nie przewiduje się utraty danych
• Typowe scenariusze: Uszkodzenie indeksu nieklastrowanego, drobne problemy z metadanymi
• Przykład polecenia: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (ostateczność):

• Używać do: Poważne uszkodzenie w przypadku niedostępności kopii zapasowych
• Bezpieczeństwo danych: Można usunąć uszkodzone dane w celu przywrócenia funkcjonalności bazy danych
• Poziom ryzyka: Wysoki – możliwa trwała utrata danych
• Typowe scenariusze: Uszkodzenie strony, uszkodzenie tabeli systemowej, błędy łańcucha alokacji
• Przykład polecenia: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Najlepsze praktyki dla tych opcji:

• Zawsze testuj w miarę możliwości naprawiaj operacje na kopiach baz danych
• Zawsze rób kopie zapasowe przed uruchomieniem tych opcji
• Udokumentuj wszystkie zmiany w celach zgodności i rozwiązywania problemów
• Ustaw bazę danych w trybie pojedynczego użytkownika przed przeprowadzeniem operacji naprawczych

Zwykle powinniśmy spróbować NAPRAWA_ODBUDOWA opcja pierwsza. Jeśli się nie powiedzie, spróbuj REPAIR_ALLOW_DATA_LOSS .

6.4 Wyniki REPAIR_ALLOW_DATA_LOSS

6.4.1 Naprawa zakończona sukcesem w przypadku utraty danych

Czasami REPAIR_ALLOW_DATA_LOSS opcja się powiedzie, ale niektóre dane sąost po naprawie.

Poniżej znajdziesz przykładowe wiadomości:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Dzieje się tak, ponieważ DBCC CHECKDB naprawia bazę danych, porzucając niektóre uszkodzone rekordy, ale w rzeczywistości most z nich nadal można odzyskać za pośrednictwem DataNumen SQL Recovery.

Przykładowe pliki:

SQL Server wersja	Uszkodzony plik MDF	Plik MDF naprawiony przez DataNumen SQL Recovery
SQL Server 2014	Błąd10_1.mdf (Wiadomość 8909, po której następuje Wiadomość 8939) (600 rekordów lost z opcją REPAIR_ALLOW_DATA_LOSS)	Błąd10_1_fixed.mdf (Brak rekordu lost)
SQL Server 2014	Błąd10_2.mdf (Wiadomość 8909, po której następuje Wiadomość 8939) (6000 rekordów (50%) lost z opcją REPAIR_ALLOW_DATA_LOSS)	Błąd10_2_fixed.mdf (Tylko 100 rekordów lost)
SQL Server 2014	Error7.mdf (100 rekordów lost z opcją REPAIR_ALLOW_DATA_LOSS)	Błąd7_fixed.mdf (Tylko jeden rekord lost)

6.4.2 Naprawa nie powiodła się – rozważ profesjonalne rozwiązanie

If REPAIR_ALLOW_DATA_LOSS w przypadku niepowodzenia wyświetlony zostanie jeden lub wiele komunikatów o błędzie.

Poniżej znajduje się kilka przykładów:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

W takich sytuacjach należy skorzystać z profesjonalnego rozwiązania, takiego jak: DataNumen SQL Recovery aby naprawić bazę danych.

Pliki przykładowe

SQL Server wersja	Uszkodzony plik MDF	Plik MDF naprawiony przez DataNumen SQL Recovery
SQL Server 2014	Błąd1_3.mdf (Pojedyncza wiadomość 824)	Błąd1_3_fixed.mdf
SQL Server 2014	Błąd1_1.mdf (Ciągłe błędy Msg 824)	Błąd1_1_naprawiony.mdf
SQL Server 2014	Błąd1_2.mdf ((Wiadomość 824, po której następuje Wiadomość 7909)	Błąd1_2_fixed.mdf
SQL Server 2014	Błąd4_1.mdf (Wiadomość 8992, po której następuje Wiadomość 3852)	Błąd4_1_fixed.mdf
SQL Server 2014	Błąd4_2.mdf (Wiadomość 8992, po której następuje Wiadomość 3852)	Błąd4_2_fixed.mdf
SQL Server 2014	Błąd5.mdf (Wiadomość 8945)	Błąd5_fixed.mdf
SQL Server 2014	Błąd6.mdf (Wiadomość 2510)	Błąd6_fixed.mdf
SQL Server 2014	Błąd2.mdf (Wiadomość 2575)	Błąd2_fixed.mdf
SQL Server 2014	Błąd11.mdf (Wiadomość 8905)	Błąd11_fixed.mdf
SQL Server 2014	Błąd3.mdf (Wiadomość 5028)	Błąd3_fixed.mdf
SQL Server 2014	Error8.mdf (Wiadomość 5125)	Error8_naprawiony.mdf
SQL Server 2014	Błąd9.mdf (Wiadomość 3313)	Błąd9_fixed.mdf

7. Najlepsze praktyki

7.1 Harmonogram regularnych operacji CHECKDB

Wdrażaj cotygodniowe wykonywanie DBCC CHECKDB dla krytycznych baz danych produkcyjnych, z codziennymi kontrolami dla systemów o dużej liczbie transakcji. Zaplanuj operacje w okresach niskiego wykorzystania, aby zminimalizować wpływ na wydajność, i rozważ rotację między pełnymi kontrolami a opcjami PHYSICAL_ONLY w oparciu o rozmiar bazy danych i okna konserwacyjne. Automatyczne planowanie poprzez SQL Server Agent zapewnia spójne wykonywanie zadań, oferując jednocześnie scentralizowane funkcje monitorowania i wysyłania alertów.

7.2 Zarządzanie wpływem na wydajność

Operacje DBCC CHECKDB zużywają znaczne zasoby systemowe, co potencjalnie wpływa na równoczesną aktywność użytkownika. Monitoruj wykorzystanie procesora, zużycie pamięci i dyskowe operacje wejścia/wyjścia podczas kontroli, aby zrozumieć wzorce wpływu na wydajność. Rozważ użycie opcji NOINDEX do rutynowych kontroli, rezerwując pełną walidację na miesięczne okna konserwacji. Wdrażaj rozszerzenia limitu czasu zapytania i strategie komunikacji z użytkownikiem, aby zarządzać oczekiwaniami podczas okresów kontroli integralności.

7.3 Planowanie okna konserwacyjnego

Koordynuj harmonogramowanie DBCC CHECKDB z innymi działaniami konserwacyjnymi, takimi jak operacje tworzenia kopii zapasowych, przebudowywanie indeksów i aktualizacje statystyk. Unikaj nakładania się operacji intensywnie wykorzystujących zasoby, które mogą powodować pogorszenie wydajności lub problemy z przekroczeniem limitu czasu. Planuj okna konserwacyjne na podstawie prognoz wzrostu rozmiaru bazy danych, zapewniając odpowiedni czas na pełną weryfikację integralności w miarę wzrostu wolumenów danych.

7.4 Automatyczne monitorowanie i alarmowanie

Konfigurowanie SQL Server Agent wysyła alerty, aby natychmiast powiadomić administratorów, gdy DBCC CHECKDB zidentyfikuje uszkodzenie. Wdrażaj rozwiązania do analizy dziennika, które wyodrębniają i kategoryzują wyniki kontroli integralności, umożliwiając analizę trendów i proaktywną identyfikację problemów. Twórz procedury eskalacji, które definiują ramy czasowe odpowiedzi i personel odpowiedzialny za różne poziomy powagi uszkodzenia.

8. DBCC CHECKTABLE: Lekka alternatywa

8.1 Kiedy używać CHECKTABLE zamiast CHECKDB

DBCC CHECKTABLE zapewnia ukierunkowane sprawdzanie integralności poszczególnych tabel, co czyni je idealnym rozwiązaniem targeted rozwiązywanie problemów i konserwacja określonych obiektów bazy danych. Użyj CHECKTABLE podczas badania problemów z wydajnością określonych tabel, walidacji krytycznych tabel biznesowych pomiędzy pełnymi kontrolami bazy danych lub gdy ograniczenia czasowe uniemożliwiają pełną walidację bazy danych. To podejście okazuje się szczególnie cenne w dużych bazach danych, w których pełne operacje CHECKDB przekraczają dostępne okna konserwacji.

8.2 Składnia i przykłady polecenia DBCC CHECKTABLE

Podstawowe polecenie CHECKTABLE tarpobiera określone tabele:

DBCC CHECKTABLE('YourTable')

Podobnie jak CHECKDB, CHECKTABLE obsługuje różne opcje, w tym NOINDEX do optymalizacji wydajności i parametry naprawy do rozwiązywania uszkodzeń. Możesz również określić nazwy schematów do precyzyjnej identyfikacji tabeli:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

To zdjęcie tarPodejście get pozwala na szczegółową weryfikację integralności przy jednoczesnym zachowaniu wydajności systemu w godzinach pracy.

8.3 Korzyści wydajnościowe dla dużych baz danych

Operacje CHECKTABLE kończą się znacznie szybciej niż pełne kontrole bazy danych, umożliwiając częstszą weryfikację integralności krytycznych tabel. To podejście umożliwia codzienną walidację istotnych tabel biznesowych, jednocześnie rezerwując kompleksowe operacje CHECKDB na tygodniowe lub miesięczne harmonogramy. Zmniejszone zużycie zasobów sprawia, że ​​CHECKTABLE nadaje się do wykonywania w środowisku produkcyjnym przy minimalnym wpływie na użytkownika.

9. Kiedy CHECKDB zawiedzie

Polecenie DBCC CHECKDB nie powiedzie się w różnych scenariuszach, w tym:

• Wykonanie DBCC CHECKDB kończy się nieprawidłowo
• Wykonanie polecenia DBCC CHECKDB kończy się pomyślnie, ale opcje naprawy nie udało się naprawić bazy danych.

W takich sytuacjach potrzebujemy bardziej profesjonalnego narzędzia, które pomoże nam naprawić uszkodzenia w bazie danych.

9.1 Wprowadzenie do DataNumen SQL Recovery

DataNumen SQL Recovery zapewnia bardziej zaawansowane możliwości:

• Najlepszy wskaźnik odzysku w przemyśle.
• Odzyskaj poważnie uszkodzone pliki bazy danych.
• Odzyskaj wszystkie obiekty bazy danych, w tym tabele, indeksy, widoki, wyzwalacze, reguły i ustawienia domyślne.
• Odzyskiwanie procedur składowanych, funkcji skalarnych, wbudowanych funkcji z wartościami przechowywanymi w tabeli i wieloinstrukcyjnych funkcji z wartościami przechowywanymi w tabeli.
• Odzyskaj trwale usunięte rekordy.
• Odszyfruj zaszyfrowane obiekty w SQL Server bazy danych.
• Napraw pliki MDF w partiach.
• Kompleksowe opcje naprawy.
• Zaawansowane rejestrowanie i raportowanie.
• Wsparcie dla wszystkich SQL Server wersje.
• Dostępność wsparcia technicznego
• Regularne aktualizacje i ulepszenia

9.2 Porównanie współczynnika sukcesu

Wskaźniki powodzenia odzyskiwania zdrowia różnią się znacząco:

• DBCC CHECKDB i CHECKTABLE: 1.27% średni wskaźnik odzysku
• DataNumen: 92.6% wskaźnik odzysku

Poniżej znajduje się kompletne porównanie konkurencyjne:

9.3 Odzyskiwanie po poważnej korupcji

Zaawansowane możliwości w ciężkich przypadkach:

• Odzyskiwanie z fizycznie uszkodzonych nośników
• Odzyskiwanie danych z sformatowanych dysków lub uszkodzonych systemów
• Odzyskiwanie z obrazów dysków, plików kopii zapasowych, plików dysków maszyn wirtualnych, tempararpliki y itp.

9.4 Kiedy warto rozważyć profesjonalne rozwiązania

• Brak ostatnio dostępnej kopii zapasowej
• DBCC CHECKDB nie powiodło się
• Scenariusze poważnych korupcji
• Radzenie sobie z krytycznymi danymi biznesowymi
• Kiedy czas ma kluczowe znaczenie
• Kiedy maksymalna regeneracja jest niezbędna

10. Często zadawane pytania

11. Wniosek

11.1 Podsumowanie kluczowych punktów

11.1.1 Podsumowanie podstawowych poleceń DBCC CHECKDB

Opanuj podstawową składnię DBCC CHECKDB w celu kompleksowego sprawdzania baz danych, wykorzystaj opcje NOINDEX i PHYSICAL_ONLY w celu optymalizacji wydajności i zrozum CHECKTABLE tarweryfikacja tabeli geted. Te podstawowe polecenia stanowią podstawę proaktywnej konserwacji bazy danych, umożliwiając wczesne wykrywanie uszkodzeń i systematyczne monitorowanie integralności.

11.1.2 Przypomnienie o najważniejszych najlepszych praktykach

Zawsze utrzymuj aktualne kopie zapasowe przed uruchomieniem kontroli integralności, planuj regularne operacje CHECKDB w oparciu o krytyczność bazy danych i wdrażaj zautomatyzowane monitorowanie w celu natychmiastowych alertów o uszkodzeniu. Pamiętaj, że zapobieganie poprzez regularne monitorowanie przewyższa podejścia reaktywne, a profesjonalne rozwiązania odzyskiwania zapewniają cenne opcje tworzenia kopii zapasowych, gdy standardowe narzędzia okazują się niewystarczające.

11.2 Kiedy używać DBCC CHECKDB a kiedy zaawansowanych rozwiązań

Użyj DBCC CHECKDB do rutynowego monitorowania integralności i rozwiązywania drobnych uszkodzeń, jednocześnie rezerwując profesjonalne narzędzia odzyskiwania dla poważnych scenariuszy uszkodzeń wykraczających poza wbudowane możliwości naprawy. Struktura decyzyjna powinna uwzględniać dostępność kopii zapasowych, krytyczność danych, ograniczenia czasowe i powagę uszkodzenia. Udani administratorzy baz danych łączą regularne monitorowanie CHECKDB z kompleksowymi strategiami tworzenia kopii zapasowych i świadomością zaawansowanych opcji odzyskiwania, gdy standardowe podejścia okazują się niewystarczające.

12. Referencje

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL)”. SQL Server Dokumenty. Korporacja Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. „Rozwiązywanie problemów ze spójnością bazy danych zgłoszonych przez DBCC CHECKDB.” SQL Server Dokumenty. Korporacja Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors