Rozwiązywanie problemów z błędami spójności bazy danych zgłaszanymi przez polecenie DBCC CHECKDB

W tym artykule wyjaśniono, jak rozwiązywać problemy dotyczące błędów zgłaszanych przez polecenie DBCC CHECKDB.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 2015748

Objawy

Po wykonaniu polecenia DBCC CHECKDB (lub innych podobnych poleceń, takich jak DBCC CHECKTABLE), komunikat podobny do poniższego jest zapisywany w dzienniku błędów programu SQL Server:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Ten komunikat pokazuje, ile błędów spójności bazy danych zostało znalezionych i ile zostało naprawionych, jeśli została użyta opcja naprawy. Ten komunikat jest również zapisywany w dzienniku zdarzeń aplikacji systemu Windows jako komunikat na poziomie informacji o identyfikatorze EventID=8957. Nawet jeśli błędy są zgłaszane, ten komunikat jest komunikatem informacyjnym.

Informacja w komunikacie rozpoczynającym się od „wewnętrzna migawka bazy danych...” pojawia się tylko wtedy, gdy DBCC CHECKDB uruchomiono w trybie online, w którym baza danych nie jest w trybie SINGLE_USER. Jest to spowodowane tym, że dla online DBCC CHECKDBwewnętrzna migawka bazy danych służy do prezentowania spójnego zestawu danych do sprawdzenia.

W tym artykule nie omówiono sposobu rozwiązywania problemów z poszczególnymi określonymi błędami zgłoszonymi przez DBCC CHECKDB, lecz raczej ogólnego podejścia w przypadku zgłaszania błędów. Wszelkie odwołania do CHECKDB w tym artykule odnoszą się również do DBCC CHECKTABLE i DBCC CHECKFILEGROUP, o ile nie określono inaczej.

Przyczyna

Polecenie DBCC CHECKDB sprawdza spójność fizyczną i logiczną stron bazy danych, wierszy, stron alokacji, relacje indeksów, integralność referencyjną tabeli systemu i inne kontrole struktury. Jeśli którekolwiek z tych testów nie powiedzie się (w zależności od wybranych opcji), zostaną zgłoszone błędy.

Przyczyną tych problemów może być uszkodzenie systemu plików, problemy z bazowym sprzętem, problemy ze sterownikiem, uszkodzone strony w pamięci lub pamięci podręcznej magazynu lub problemy z programem SQL Server. Aby uzyskać informacje na temat identyfikowania głównej przyczyny zgłoszonych błędów, zobacz Zbadaj przyczynę źródłową.

Rozwiązanie

  1. Przed kontynuowaniem przywracania kopii zapasowej lub naprawiania bazy danych rozwiąż wszelkie problemy źródłowe związane ze sprzętem w systemie. Zastosuj wszystkie aktualizacje sterownika, oprogramowania układowego, systemu BIOS i systemu operacyjnego, które są istotne dla ścieżki we/wy. Współpracuj z administratorem pełnej ścieżki we/wy (komputera lokalnego, sterowników urządzeń, kart sieciowych pamięci masowej, sieci SAN, magazynu zaplecza i pamięci podręcznej) oraz pamięci (RAM), aby odizolować i rozwiązać wszelkie problemy. Przykłady obejmują aktualizowanie sterowników urządzeń i sprawdzanie konfiguracji całej ścieżki we/wy. Aby uzyskać szczegółowe informacje na temat sposobu badania głównej przyczyny, zobacz Zbadaj główną przyczynę.

  2. Jeśli DBCC CHECKDB zgłasza trwałe błędy niespójności, najlepszym rozwiązaniem byłoby przywrócenie danych ze znanej dobrej kopii zapasowej. Aby uzyskać więcej informacji, zobacz Przywracanie i odzyskiwanie.

  3. Zastosuj najnowszą aktualizację zbiorczą programu SQL Server lub dodatek Service Pack, aby uniknąć napotkania znanych problemów. Zapoznaj się z dokumentacją aktualizacji zbiorczej lub dodatku Service Pack, aby uzyskać informacje o znanych problemach związanych z uszkodzeniem bazy danych (błędami spójności), które zostały rozwiązane, i zastosuj wszelkie odpowiednie poprawki. Jedna centralna lokalizacja, w której można wyszukać wszystkie poprawki dla określonej wersji, są dostępne w szczegółowych listach poprawek dla programu SQL Server 2022, 2019, 2017.

  4. Jeśli błędy DBCC CHECKDB występują sporadycznie, to znaczy, jeśli pojawiają się w jednym przebiegu i znikają w następnym, możesz mieć do czynienia z problemami z pamięcią podręczną dysku (sterownik urządzenia lub inny problem ze ścieżką we/wy). Współpracuj z opiekunami ścieżki we/wy, aby odizolować i rozwiązać wszelkie problemy. Przykłady obejmują aktualizowanie sterowników urządzeń, sprawdzanie konfiguracji całej ścieżki we/wy oraz aktualizowanie oprogramowania układowego i systemu BIOS urządzeń na ścieżce we/wy i systemu.

  5. Jeśli nie można przywrócić z kopii zapasowej, CHECKDB ma funkcję naprawy błędów, której można użyć. Istnieją dwa poziomy naprawy:

    • REPAIR_REBUILD — wykonuje naprawy, podczas których nie ma możliwości utraty danych.
    • REPAIR_ALLOW_DATA_LOSS — wykonuje naprawy, które mają możliwość utraty danych.

    Aby uzyskać więcej informacji, zobacz dokumentację DBCC CHECKDB.

    Należy zachować ostrożność podczas wybierania opcji naprawy z dopuszczeniem utraty danych, ponieważ może ona pozostawić bazę danych w stanie logicznie niespójnym. Wynik DBCC CHECKDB zawiera zalecenie dotyczące minimalnego poziomu naprawy do użycia. Częstą praktyką jest wielokrotne uruchamianie CHECKDB z REPAIR_ALLOW_DATA_LOSS, dopóki nie zostaną zgłoszone żadne więcej błędów. Dzieje się tak dlatego, że gdy naprawa usuwa zestaw błędów, mogą zostać wykryte inne uszkodzone powiązania. Jednak nowe błędy mogą pojawić się, jeśli przyczyna bazowa nie została usunięta. W związku z tym, jeśli problemy na poziomie systemu, takie jak sprzęt lub system plików powodują uszkodzenie danych, należy najpierw rozwiązać te problemy przed przywróceniem kopii zapasowej lub wykonaniem naprawy. Inżynierowie pomocy technicznej firmy Microsoft nie mogą pomóc w fizycznym odzyskiwaniu uszkodzonych danych, jeśli naprawa nie naprawi błędów spójności lub jeśli kopia zapasowa bazy danych jest uszkodzona.

    Po uruchomieniu polecenia DBCC CHECKDB wyświetlana jest rekomendacja wskazująca minimalną opcję naprawy wymaganą do naprawy wszystkich błędów. Te komunikaty przypominają następujące dane wyjściowe:

    W bazie danych "mydb" znaleziono 0 błędów alokacji i 15 błędów spójności.
    REPAIR_ALLOW_DATA_LOSS to minimalny poziom naprawy dla błędów znalezionych przez DBCC CHECKDB (mydb).

    Zalecenie dotyczące naprawy to minimalny poziom naprawy, aby spróbować usunąć wszystkie błędy zgłaszane przez CHECKDB. Minimalny poziom naprawy nie oznacza, że ta opcja naprawy naprawia wszystkie błędy. Niektórych błędów po prostu nie można naprawić. Może być również konieczne uruchomienie procesu naprawy więcej niż raz. Nie wszystkie zgłoszone błędy wymagają użycia tego poziomu naprawy. Oznacza to, że nie wszystkie naprawy wykonane przez CHECKDB z użyciem REPAIR_ALLOW_DATA_LOSS skutkują utratą danych. Aby ustalić, czy naprawa błędu powoduje utratę danych, należy uruchomić naprawę. Jedną z technik, które pomagają zawęzić zakres naprawy dla każdej tabeli, jest użycie DBCC CHECKTABLE dla każdej tabeli zgłaszającej błąd. To pokazuje minimalny poziom naprawy dla danej tabeli.

    Ostrzeżenie

    Należy przeprowadzić ręczną walidację danych po CHECKDB zakończeniu naprawy, eksportu lub importu danych. Aby uzyskać więcej informacji, zobacz argumenty DBCC CHECKDB. Dane mogą nie być logicznie spójne po naprawie. Na przykład naprawa (szczególnie opcja REPAIR_ALLOW_DATA_LOSS) może spowodować usunięcie całych stron danych zawierających niespójne dane. W takich przypadkach tabela z relacją klucza obcego z inną tabelą może zawierać wiersze, które nie mają odpowiednich wierszy klucza podstawowego w tabeli nadrzędnej.

  6. Spróbuj wygenerować skrypt schematu bazy danych. Użyj skryptu, aby utworzyć nową bazę danych, a następnie użyć narzędzia, takiego jak BCP lub SSIS Export/Import Wizard , aby wyeksportować jak najwięcej danych z uszkodzonej bazy danych do nowej bazy danych. Eksportowanie danych z uszkodzonej tabeli prawdopodobnie nie powiedzie się. W takich przypadkach pomiń tę tabelę, przejdź do następnej i zapisz to, co możesz.

  7. Zapoznaj się z następującymi artykułami pod kątem określonych błędów wygenerowanych przez DBCC CHECKDB i wykonaj podane kroki (jeśli istnieją). Oto kilka przykładów:

Zbadaj główną przyczynę błędów spójności bazy danych

Aby zidentyfikować główną przyczynę błędów spójności bazy danych, rozważ następujące metody:

  • Sprawdź dziennik zdarzeń systemu Windows pod kątem błędów systemowych, sterowników lub dysku i skontaktuj się z producentem sprzętu, aby je rozwiązać.
  • Uruchom wszelkie testy diagnostyczne dostarczane przez producentów sprzętu dla komputera i/lub systemu dysków. Większość systemów zapewnia wbudowaną diagnostykę systemu BIOS/UEFI dla pamięci masowej (dysków twardych), pamięci, procesorów CPU, płyt systemowych, macierzy RAID i wielu innych składników.
  • Współpracuj z dostawcą sprzętu lub producentem urządzenia, aby upewnić się, że:
  • Rozważ użycie narzędzia takiego jak SQLIOSim na dysku, na którym znajdują się bazy danych, w których zgłoszono błędy spójności. SQLIOSim to narzędzie niezależne od silnika SQL Server w celu przetestowania integralności operacji we/wy dla systemu dysków. Funkcja SQLIOSim jest dostarczana z programem SQL Server i nie wymaga oddzielnego pobierania. Można go znaleźć w folderze \MSSQL\Binn .
  • Zapoznaj się z dokumentacją aktualizacji zbiorczej lub dodatku Service Pack, aby uzyskać informacje o znanych problemach dotyczących uszkodzenia bazy danych (błędów spójności), które naprawiono, i zastosuj wszelkie odpowiednie poprawki. Jedna centralna lokalizacja, w której można wyszukać wszystkie poprawki dla określonej wersji — zobacz szczegółowe listy poprawek programu SQL Server 2022, 2019, 2017.
  • Sprawdź wszelkie inne błędy zgłaszane przez program SQL Server, takie jak naruszenia dostępu lub błędy asercji. Operacje na uszkodzonych bazach danych często powodują wyjątki naruszenia dostępu lub błędy asercji.
  • Upewnij się, że bazy danych korzystają z opcji PAGE_VERIFY CHECKSUM. Jeśli zgłaszane są błędy sumy kontrolnej, oznacza to, że błędy spójności wystąpiły po zapisaniu stron na dysk przez program SQL Server. W związku z tym podsystem we/wy należy dokładnie sprawdzić. Aby uzyskać więcej informacji na temat błędów sumy kontrolnej, zobacz How to Troubleshoot Msg 824 in SQL Server (Jak rozwiązywać problemy z msg 824 w programie SQL Server).
  • Poszukaj błędów komunikatu 832 w dzienniku BŁĘDÓW. Te błędy mogą wskazywać, że strony mogą ulec uszkodzeniu w pamięci podręcznej, zanim zostaną zapisane na dysku. Aby uzyskać więcej informacji, zobacz How to Troubleshoot Msg 832 in SQL Server.
  • W innym systemie spróbuj przywrócić kopię zapasową bazy danych, o której wiesz, że jest „czysta” (bez błędów z CHECKDB), a następnie przywróć kopie zapasowe dziennika transakcji, które obejmują czas wygenerowania błędu. Jeśli możesz "odtworzyć" ten problem, przywracając "czystą" kopię zapasową bazy danych i kopię zapasową dziennika transakcji, skontaktuj się z pomocą techniczną firmy Microsoft, aby uzyskać pomoc.
  • Błędy czystości danych mogą wynikać z tego, że aplikacja wstawia lub aktualizuje nieprawidłowe dane w tabelach programu SQL Server. Aby uzyskać więcej informacji na temat rozwiązywania problemów z błędami Data Purity, zobacz Rozwiązywanie problemów z błędem DBCC 2570 w programie SQL Server 2005.
  • Sprawdź integralność systemu plików przy użyciu polecenia chkdsk. Nie uruchamiaj polecenia chkdsk , gdy program SQL Server jest uruchomiony. Może zgłaszać przejściowe błędy plików, jeśli program SQL Server zapisuje do sprawdzanych plików. Ponadto przełączniki, takie jak /r lub /f, mogą przenosić bajty plików do innej lokalizacji na dysku, a takie przenoszenie może prowadzić do uszkodzenia danych, jeśli program SQL Server również zapisuje do tych plików lub odczytuje z nich. Dlatego przed uruchomieniem chkdsk polecenia pamiętaj, aby zatrzymać program SQL Server. Ponadto należy zachować ostrożność przy użyciu opcji naprawy, takich jak /r i /f. Przed uruchomieniem naprawy upewnij się, że masz kopię zapasową baz danych, ponieważ te opcje mogą uszkodzić pliki, jeśli chkdsk wykryje błędy dysku.

Więcej informacji

Aby uzyskać szczegółowe informacje na temat składni DBCC CHECKDB i informacji lub opcji dotyczących sposobu uruchamiania polecenia, zobacz DBCC CHECKDB (Transact-SQL).

Jeśli jakiekolwiek błędy zostaną znalezione przy użyciu polecenia CHECKDB, inne komunikaty podobne do następującego komunikatu są zgłaszane w dzienniku BŁĘDÓW na potrzeby raportowania błędów:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Informacje o błędach zostały przesłane do raportowania błędów programu Watson.

Pliki używane do raportowania błędów obejmują plik SQLDump<nnn>.txt. Ten plik może być przydatny do celów historycznych, ponieważ zawiera listę błędów znalezionych w CHECKDB w formacie XML.

Aby dowiedzieć się, kiedy ostatni raz DBCC CHECKDB został uruchomiony bez wykrytych błędów dla bazy danych (ostatni znany czysty przebieg CHECKDB), sprawdź dziennik BŁĘDÓW programu SQL Server. Poszukaj komunikatu podobnego do poniższego dla bazy danych użytkownika lub systemu. Ten komunikat jest zapisywany jako komunikat na poziomie informacji w dzienniku zdarzeń aplikacji systemu Windows z identyfikatorem EventID = 17573:

Date/Time spid7s CHECKDB dla bazy danych "master" zakończyła się bez błędów o Date/Time22:11:11.417 (czas lokalny). Jest to tylko komunikat informacyjny; nie jest wymagana żadna akcja użytkownika

  • Ostatnia aktualizacja o