Udostępnij za pośrednictwem

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 z błędami zgłaszane przez DBCC CHECKDB polecenie .

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 2015748

Symptomy

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 na poziomie informacji.

Informacje w komunikacie rozpoczynającym się od "wewnętrznej migawki bazy danych..." Pojawia się tylko wtedy, gdy DBCC CHECKDB została uruchomiona w trybie online, w którym baza danych nie jest w trybie SINGLE_USER . Jest to spowodowane tym, że w przypadku trybu 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 program, ale raczej ogólnym podejściem w przypadku zgłaszania błędów. Wszelkie odwołania do CHECKDB tego artykułu dotyczą DBCC CHECKTABLE również polecenia DBCC CHECKFILEGROUP , chyba że określono.

Przyczyna

Polecenie DBCC CHECKDB sprawdza spójność fizyczną i logiczną stron bazy danych, wierszy, stron alokacji, relacje indeksu, 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, podstawowe problemy z systemem sprzętowym, 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 Badanie głównej przyczyny.

Rozwiązanie

  1. Przed kontynuowaniem przywracania kopii zapasowej lub naprawiania bazy danych rozwiąż wszelkie podstawowe problemy 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. Skontaktuj się z administratorem pełnej ścieżki we/wy (komputera lokalnego, sterowników urządzeń, kart sieciowych magazynu, 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 Badanie głównej przyczyny.

  2. Jeśli DBCC CHECKDB zgłasza błędy stałej spó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 upewnić się, że nie występują żadne znane problemy. Zapoznaj się z dokumentacją aktualizacji zbiorczej lub dodatku Service Pack, aby uzyskać informacje o znanych problemach, które zostały rozwiązane związane z uszkodzeniem bazy danych (błędami spójności) i zastosuj wszelkie odpowiednie poprawki. Jedna centralna lokalizacja, w której można wyszukać wszystkie poprawki dla określonej wersji, jeśli listy Szczegółowe poprawki programu SQL Server 2022, 2019, 2017.

  4. DBCC CHECKDB Jeśli błędy występują sporadycznie, oznacza to, że występują one w jednym przebiegu i znikają w następnym, mogą wystąpić problemy z pamięcią podręczną dysku (sterownik urządzenia lub inny problem ze ścieżką we/wy). Skontaktuj się 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 na urządzeniach ścieżki we/wy i systemie.

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

    • REPAIR_REBUILD — wykonuje naprawy, które nie mają 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 podejmowania wyboru w celu naprawy z zezwoleniem na utratę danych, ponieważ może ona pozostawić bazę danych w stanie logicznie niespójnym. Dane DBCC CHECKDB wyjściowe zawierają zalecenie dotyczące minimalnego poziomu naprawy do użycia. Częstą praktyką jest wielokrotne uruchamianie CHECKDBREPAIR_ALLOW_DATA_LOSS z czasem, dopóki nie zostaną zgłoszone żadne więcej błędów. Dzieje się tak dlatego, że po naprawieniu zestawu 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 rozwiązać te problemy najpierw przed przywróceniem kopii zapasowej lub 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 DBCC CHECKDBpolecenia zaleca się wskazanie minimalnej opcji naprawy wymaganej do naprawy wszystkich błędów. Te komunikaty przypominają następujące dane wyjściowe:

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

    Zalecenie dotyczące naprawy to minimalny poziom naprawy, aby spróbować usunąć wszystkie błędy z programu 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ą usunięcia użycia tego poziomu naprawy. Oznacza to, że nie wszystkie naprawy w CHECKDB wyniku REPAIR_ALLOW_DATA_LOSS utraty danych. Aby ustalić, czy rozwiązanie błędu powoduje utratę danych, należy uruchomić naprawę. Jedną z technik, które pomagają zawęzić poziom naprawy dla każdej tabeli, jest użycie DBCC CHECKTABLE w przypadku każdej tabeli zgłaszającej błąd. Spowoduje to wyświetlenie minimalnego poziomu naprawy dla danej tabeli.

    Ostrzeżenie

    Należy przeprowadzić ręczną walidację danych po CHECKDB zakończeniu naprawy lub eksportowania lub importowania danych. Aby uzyskać więcej informacji, zobacz DBCC CHECKDB argumenty. Dane mogą nie być logicznie spójne po naprawie. Na przykład naprawa (szczególnie REPAIR_ALLOW_DATA_LOSS opcja) 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 utworzyć 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, aby zapoznać się z określonymi błędami wygenerowanymi przez DBCC CHECKDB program i wykonaj podane kroki (jeśli istnieją). Oto kilka przykładów:

Badanie głównej przyczyny 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 dotyczących poziomu systemu, sterownika lub dysku i skontaktuj się z producentem sprzętu, aby je rozwiązać.
  • Uruchom dowolną diagnostykę dostarczaną przez producentów sprzętu dla komputera i/lub systemu dysków. Większość systemów zapewnia wbudowaną diagnostykę systemu BIOS/UEFI dla magazynu (dysków twardych), pamięci, procesorów CPU, płyt systemowych, macierzy RAID i wielu innych składników.
  • Skontaktuj się z dostawcą sprzętu lub producentem urządzenia, aby upewnić się, że:
    • Urządzenia sprzętowe i konfiguracja potwierdzają wymagania dotyczące danych wejściowych/wyjściowych aparatu bazy danych programu Microsoft SQL Server.
    • Sterowniki urządzeń i inne składniki pomocnicze oprogramowania wszystkich urządzeń w ścieżce we/wy są zaktualizowane.
  • Rozważ użycie narzędzia takiego jak SQLIOSim na dysku, na którym znajdują się bazy danych, które zgłosiły błędy spójności. SQLIOSim to narzędzie niezależne od aparatu programu 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, które zostały rozwiązane związane z uszkodzeniem bazy danych (błędami spójności) i zastosuj wszelkie odpowiednie poprawki. Jedna centralna lokalizacja, w której można wyszukać wszystkie poprawki dla określonej wersji, jeśli listy Szczegółowe poprawki programu SQL Server 2022, 2019, 2017.
  • Sprawdź wszelkie inne błędy zgłaszane przez program SQL Server, takie jak naruszenia dostępu lub asercji. Działanie względem uszkodzonych baz danych często powoduje wyjątki naruszenia dostępu lub błędy asertywne.
  • Upewnij się, że bazy danych korzystają z PAGE_VERIFY CHECKSUM opcji . Jeśli zgłaszane są błędy sumy kontrolnej, oznacza to, że błędy spójności wystąpiły po zapisaniu stron na dysku 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ą być uszkodzone, gdy znajdują się w pamięci podręcznej przed zapisem na dysku. Aby uzyskać więcej informacji, zobacz How to Troubleshoot Msg 832 in SQL Server (Jak rozwiązywać problemy z programem Msg 832 w programie SQL Server).
  • W innym systemie spróbuj przywrócić kopię zapasową bazy danych, która jest "czysta" (bez błędów z CHECKDBprogramu ), a następnie kopie zapasowe dziennika transakcji, które obejmują czas generowania błędu. Jeśli możesz "utworzyć ponownie" ten problem, przywracając "czystą" kopię zapasową bazy danych i tworzenie kopii zapasowej dziennika transakcji, skontaktuj się z pomocą techniczną firmy Microsoft, aby uzyskać pomoc.
  • Błędy czystości danych mogą być problemem z wstawianiem lub aktualizowaniem nieprawidłowych danych w tabelach programu SQL Server. Aby uzyskać więcej informacji na temat rozwiązywania problemów z błędami czystości danych, 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 w sprawdzanych plikach. 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, jeśli program SQL Server również zapisuje lub odczytuje z tych plików. 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 błędy dysku zostaną znalezione przez program chkdsk.

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 nnn nnn> narzędzia SQLDump<.txt. Ten plik może być przydatny w celach historycznych, ponieważ zawiera listę błędów znalezionych CHECKDB w formacie XML.

Aby dowiedzieć się, kiedy ostatni raz DBCC CHECKDB został uruchomiony bez wykrytych błędów dla bazy danych (ostatnia znana czysta 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, jak również):

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