DBCC CHECKDB (Transact-SQL)

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Sprawdza integralność logiczną i fizyczną wszystkich obiektów w określonej bazie danych, wykonując następujące operacje:

• Uruchamia DBCC CHECKALLOC w bazie danych.

• Uruchamia DBCC CHECKTABLE na każdej tabeli i widoku w bazie danych.

• Uruchamia DBCC CHECKCATALOG w bazie danych.

• Sprawdza poprawność zawartości każdego indeksowanego widoku w bazie danych.

• Sprawdza spójność na poziomie łącza między metadanymi tabeli a katalogami i plikami systemu plików podczas przechowywania danych typu varbinary(max) w systemie plików przy użyciu FILESTREAM.

• Weryfikuje dane usługi Service Broker w bazie danych.

Oznacza to, że polecenia DBCC CHECKALLOC, DBCC CHECKTABLElub DBCC CHECKCATALOG nie muszą być uruchamiane oddzielnie od DBCC CHECKDB. Aby uzyskać bardziej szczegółowe informacje na temat kontroli, które te polecenia wykonują, zobacz opisy tych poleceń.

DBCC CHECKDB jest obsługiwana w bazach danych zawierających tabele zoptymalizowane pod kątem pamięci, ale walidacja odbywa się tylko w tabelach opartych na dyskach. Jednak w ramach tworzenia kopii zapasowych i odzyskiwania bazy danych weryfikacja CHECKSUM jest wykonywana dla plików w grupach plików zoptymalizowanych pod kątem pamięci.

Ponieważ opcje naprawy dbCC nie są dostępne dla tabel zoptymalizowanych pod kątem pamięci, należy regularnie tworzyć kopie zapasowe baz danych i testować kopie zapasowe. Jeśli wystąpią problemy z integralnością danych w tabeli zoptymalizowanej dla pamięci, należy przywrócić z ostatniej kopii zapasowej o znanej dobrej jakości.

Transact-SQL konwencje składni

Składnia

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Argumenty

database_name | database_id | 0

Nazwa lub identyfikator bazy danych, dla której ma zostać uruchomiona kontrola integralności. Jeśli nie określono wartości lub jeśli określono wartość 0, używana jest bieżąca baza danych. Nazwy baz danych muszą być zgodne z regułami dotyczącymi identyfikatorów .

NOINDEX

Określa, że intensywne kontrole indeksów nieklastrowanych dla tabel użytkowników nie są wykonywane. Ten wybór zmniejsza całkowity czas wykonywania. NOINDEX nie ma wpływu na tabele systemowe, ponieważ kontrole integralności są zawsze wykonywane w indeksach tabel systemowych.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Określa, że DBCC CHECKDB naprawia znalezione błędy. Użyj opcji REPAIR_* tylko w ostateczności. Określona baza danych musi być w trybie pojedynczego użytkownika, aby użyć jednej z następujących opcji naprawy.

• REPAIR_ALLOW_DATA_LOSS

  Próbuje naprawić wszystkie zgłoszone błędy. Te naprawy mogą spowodować utratę danych.

  Ostrzeżenie

  Opcja REPAIR_ALLOW_DATA_LOSS może spowodować utratę większej ilości danych niż w przypadku przywrócenia z ostatniej znanej dobrej kopii zapasowej. Zobacz ostrzeżenie o utracie danych z REPAIR_ALLOW_DATA_LOSS

  Firma Microsoft zawsze zaleca przywrócenie z ostatniej sprawdzonej kopii zapasowej jako podstawowej metody odzyskania danych po błędach zgłoszonych przez DBCC CHECKDB. Opcja REPAIR_ALLOW_DATA_LOSS nie jest alternatywą dla przywracania ze znanej dobrej kopii zapasowej. Jest to opcja ostatniej szansy, zalecana do użycia tylko wtedy, gdy przywracanie z kopii zapasowej nie jest możliwe.

  Niektóre błędy, które można naprawić tylko przy użyciu opcji REPAIR_ALLOW_DATA_LOSS, mogą obejmować dealokację wiersza, strony lub serii stron, aby usunąć błędy. Wszystkie odprzydzielone dane nie są już dostępne ani możliwe do odzyskania dla użytkownika, a dokładna zawartość odprzydzielonych danych nie może być określona. W związku z tym integralność referencyjna może nie być dokładna po cofnięciu przydziału wierszy lub stron, ponieważ ograniczenia klucza obcego nie są sprawdzane ani utrzymywane w ramach tej operacji naprawy. Użytkownik musi sprawdzić integralność referencyjną bazy danych (przy użyciu DBCC CHECKCONSTRAINTS) po użyciu opcji REPAIR_ALLOW_DATA_LOSS.

  Przed wykonaniem naprawy należy utworzyć fizyczne kopie plików należących do tej bazy danych. Obejmuje to podstawowy plik danych (.mdf), wszystkie pomocnicze pliki danych (.ndf), wszystkie pliki dziennika transakcji (.ldf) i inne kontenery, które tworzą bazę danych, w tym katalogi pełnotekstowe, foldery strumienia plików, zoptymalizowane pod kątem pamięci dane itd.

  Przed wykonaniem naprawy rozważ zmianę stanu bazy danych na tryb EMERGENCY i próbę wyodrębnienia jak największej ilości informacji z tabel krytycznych i zapisania tych danych.

• REPAIR_FAST

  Utrzymuje składnię tylko dla wstecznej kompatybilności. Nie są wykonywane żadne akcje naprawy.

• REPAIR_REBUILD

  Wykonuje naprawy, które nie mają możliwości utraty danych. Ta opcja może obejmować szybkie naprawy, takie jak naprawianie brakujących wierszy w indeksach nieklastrowanych oraz czasochłonne naprawy, takie jak ponowne kompilowanie indeksu.

  Ten argument nie naprawia błędów dotyczących danych FILESTREAM.

Ważny

Ponieważ DBCC CHECKDB z dowolną z opcji REPAIR_* są całkowicie rejestrowane i możliwe do odzyskania, firma Microsoft zawsze zaleca użytkownikowi użycie DBCC CHECKDB z dowolnymi opcjami REPAIR_* w ramach transakcji (wykonaj BEGIN TRANSACTION przed uruchomieniem polecenia), aby użytkownik mógł potwierdzić, że chce zaakceptować wyniki operacji. Następnie użytkownik może wykonać COMMIT TRANSACTION, aby zatwierdzić całą pracę wykonaną przez operację naprawy. Jeśli użytkownik nie chce akceptować wyników operacji, może wykonać ROLLBACK TRANSACTION, aby cofnąć skutki operacji naprawy.

Aby naprawić błędy, zalecamy przywrócenie z kopii zapasowej. Operacje naprawy nie uwzględniają żadnych ograniczeń, które mogą istnieć w tabelach lub między nimi. Jeśli określona tabela jest objęta co najmniej jednym ograniczeniem, zalecamy uruchomienie DBCC CHECKCONSTRAINTS po operacji naprawy. Jeśli musisz użyć REPAIR_*, uruchom DBCC CHECKDB bez opcji naprawy, aby określić, który poziom naprawy zastosować. Jeśli używasz poziomu REPAIR_ALLOW_DATA_LOSS, zalecamy wykonanie kopii zapasowej bazy danych przed uruchomieniem DBCC CHECKDB za pomocą tej opcji.

ALL_ERRORMSGS

Wyświetla wszystkie zgłoszone błędy na obiekt. Wszystkie komunikaty o błędach są domyślnie wyświetlane. Określenie lub pominięcie tej opcji nie ma wpływu. Komunikaty o błędach są sortowane według identyfikatora obiektu, z wyjątkiem komunikatów wygenerowanych z bazy danych tempdb.

ROZSZERZONE_LOGICZNE_SPRAWDZENIA

Jeśli poziom zgodności wynosi 100, wprowadzony w programie SQL Server 2008 (10.0.x), ta opcja wykonuje testy spójności logicznej dla widoku indeksowanego, indeksów XML i indeksów przestrzennych, w których są obecne.

Aby uzyskać więcej informacji, zobacz Przeprowadzanie kontroli spójności logicznej na indeksach w dalszej części tego artykułu.

NO_INFOMSGS

Pomija wszystkie komunikaty informacyjne.

TABLOCK

Powoduje, że DBCC CHECKDB uzyskuje blokady zamiast korzystania z wewnętrznej migawki bazy danych. Obejmuje to krótkoterminową blokadę wyłączną (X) w bazie danych. TABLOCK powoduje, że DBCC CHECKDB działa szybciej w bazie danych przy dużym obciążeniu, ale zmniejsza współbieżność dostępną na bazie danych podczas działania DBCC CHECKDB.

Ważny

TABLOCK ogranicza kontrole, które są wykonywane; DBCC CHECKCATALOG nie jest uruchamiana w bazie danych, a dane usługi Service Broker nie są weryfikowane.

TYLKO SZACOWANIE

Przedstawia szacowaną ilość tempdb miejsca wymaganego do uruchomienia DBCC CHECKDB ze wszystkimi innymi określonymi opcjami. Rzeczywiste sprawdzanie bazy danych nie jest wykonywane.

PHYSICAL_ONLY

Ogranicza sprawdzanie do integralności fizycznej struktury strony oraz nagłówków rekordów i spójności alokacji bazy danych. Ta kontrola została zaprojektowana w celu zapewnienia niewielkiej kontroli spójności fizycznej bazy danych, ale może również wykrywać rozdarte strony, błędy sumy kontrolnej i typowe awarie sprzętowe, które mogą naruszyć bezpieczeństwo danych użytkownika.

Pełne uruchomienie DBCC CHECKDB może trwać znacznie dłużej niż wcześniejsze wersje. To zachowanie występuje, ponieważ:

• Testy logiczne są bardziej kompleksowe.
• Niektóre struktury, które mają być sprawdzane, są bardziej złożone.
• Wprowadzono wiele nowych kontroli w celu uwzględnienia nowych funkcji.

W związku z tym użycie opcji PHYSICAL_ONLY może spowodować znacznie krótszy czas wykonywania dla DBCC CHECKDB w dużych bazach danych i jest zalecane do częstego używania w systemach produkcyjnych. Nadal zalecamy okresowe wykonywanie pełnego przebiegu DBCC CHECKDB. Częstotliwość tych przebiegów zależy od czynników specyficznych dla poszczególnych firm i środowisk produkcyjnych.

Ten argument zawsze implikuje NO_INFOMSGS i nie jest dozwolony z żadną z dostępnych opcji naprawy.

Ostrzeżenie

Określenie PHYSICAL_ONLY powoduje, że DBCC CHECKDB pomija wszystkie kontrole danych FILESTREAM.

CZYSTOŚĆ DANYCH

Powoduje, że DBCC CHECKDB sprawdza bazę danych pod kątem wartości kolumn, które są nieprawidłowe lub poza zakresem. Na przykład DBCC CHECKDB wykrywa kolumny z wartościami daty i godziny, które są większe lub mniejsze niż dopuszczalny zakres dla typu danych datetime; lub kolumn typu danych liczbowych dziesiętnych lub przybliżonych z wartościami skalowania lub precyzji, które nie są prawidłowe.

Kontrole integralności wartości kolumny są domyślnie włączone i nie wymagają opcji DATA_PURITY. W przypadku baz danych uaktualnionych z wcześniejszych wersji programu SQL Server sprawdzanie wartości kolumny nie jest domyślnie włączone, dopóki DBCC CHECKDB WITH DATA_PURITY nie zostanie uruchomiony w bazie danych bez błędów. Następnie DBCC CHECKDB domyślnie sprawdza integralność wartości kolumny. Aby uzyskać więcej informacji na temat wpływu CHECKDB przez uaktualnienie bazy danych z wcześniejszych wersji programu SQL Server, zobacz sekcję Uwagi w dalszej części tego artykułu.

Ostrzeżenie

Jeśli określono PHYSICAL_ONLY, kontrole integralności kolumn nie są wykonywane.

Nie można naprawić błędów walidacji zgłaszanych przez tę opcję przy użyciu opcji naprawy DBCC. Aby uzyskać informacje na temat ręcznego poprawiania tych błędów, zobacz MSSQLSERVER_2570.

MAXDOP

Dotyczy: SQL Server 2014 (12.x) Service Pack 2 i późniejsze wersje

Zastępuje opcję konfiguracji max degree of parallelism opcją sp_configure dla instrukcji. MAXDOP może przekroczyć wartość skonfigurowaną przy użyciu sp_configure. Jeśli MAXDOP przekroczy wartość skonfigurowaną za pomocą zarządcy zasobów, aparat bazy danych programu SQL Server używa wartości MAXDOP zarządcy zasobów opisanej w ALTER WORKLOAD GROUP. Wszystkie reguły semantyczne używane z opcją konfiguracji max degree of parallelism mają zastosowanie podczas korzystania z wskazówki MAXDOP zapytania. Aby uzyskać więcej informacji, zobacz Konfiguracja serwera: maksymalny stopień równoległości.

Ostrzeżenie

Jeśli MAXDOP jest ustawiona na zero, program SQL Server wybierze max degree of parallelism do użycia.

Uwagi

DBCC CHECKDB nie sprawdza indeksów wyłączonych. Aby uzyskać więcej informacji o wyłączonych indeksach, zobacz Wyłącz indeksy i ograniczenia.

Jeśli typ zdefiniowany przez użytkownika jest oznaczony jako uporządkowany względem bajtów, musi istnieć tylko jedna jego serializacja. Brak spójnej serializacji bajtowo uporządkowanych typów zdefiniowanych przez użytkownika powoduje błąd 2537 podczas uruchamiania DBCC CHECKDB. Aby uzyskać więcej informacji, zobacz Tworzenie typów User-Defined — wymagania.

Ponieważ bazy danych zasobów można modyfikować tylko w trybie pojedynczego użytkownika, nie można bezpośrednio uruchomić polecenia . Jednak, gdy jest wykonywana względem bazy danych master, wewnętrznie w bazie danych zasobów również jest uruchamiana druga . Oznacza to, że DBCC CHECKDB może zwrócić dodatkowe wyniki. Polecenie zwraca dodatkowe zestawy wyników, gdy nie są ustawione żadne opcje lub gdy jest ustawiona opcja PHYSICAL_ONLY lub ESTIMATEONLY.

W programie SQL Server 2005 (9.x) z dodatkiem Service Pack 2 lub nowszym, uruchomienie DBCC CHECKDB nie powoduje już wyczyszczenia pamięci podręcznej planu dla instancji programu SQL Server. Przed Service Packiem 2 dla SQL Server 2005 (9.x), wykonanie DBCC CHECKDB powoduje wyczyszczenie pamięci podręcznej planu. Wyczyszczenie pamięci podręcznej planu powoduje ponowne skompilowanie wszystkich późniejszych planów wykonywania i może spowodować nagły, tymczasowy spadek wydajności zapytań.

Przeprowadzanie kontroli spójności logicznej na indeksach

Sprawdzanie spójności logicznej indeksów różni się w zależności od poziomu zgodności bazy danych w następujący sposób:

• Jeśli poziom zgodności wynosi co najmniej 100 (wprowadzony w programie SQL Server 2008 (10.0.x)):

• O ile nie określono NOINDEX, DBCC CHECKDB wykonuje zarówno testy spójności fizycznej, jak i logicznej dla pojedynczej tabeli oraz we wszystkich indeksach nieklastrowanych. Jednak w przypadku indeksów XML, indeksów przestrzennych i widoków indeksowanych są domyślnie wykonywane tylko testy spójności fizycznej.

• Jeśli określono WITH EXTENDED_LOGICAL_CHECKS, dokonywana jest weryfikacja logiczna w widoku indeksowanym, indeksach XML i indeksach przestrzennych, jeśli są obecne. Domyślnie testy spójności fizycznej są wykonywane przed sprawdzaniem spójności logicznej. Jeśli NOINDEX jest również określona, są wykonywane tylko testy logiczne.

Kontrole spójności logicznej porównują wewnętrzną tabelę indeksów obiektu indeksu z tabelą użytkownika, na które wskazuje. Aby zidentyfikować odstające wiersze, jest konstruowane zapytanie wewnętrzne w celu wykonania pełnego przecięcia tabel wewnętrznej i użytkownika. Uruchomienie tego zapytania może mieć znaczący wpływ na wydajność, a jego postęp nie może być śledzony. Dlatego zalecamy określenie WITH EXTENDED_LOGICAL_CHECKS tylko wtedy, gdy podejrzewasz problemy z indeksem, które nie mają związku z uszkodzeniem fizycznym, lub jeśli sumy kontrolne na poziomie strony zostały wyłączone i podejrzewasz uszkodzenie sprzętu na poziomie kolumny.

• Jeśli indeks jest indeksem filtrowanym, DBCC CHECKDB przeprowadza sprawdzanie spójności w celu sprawdzenia, czy wpisy indeksu spełniają predykat filtru.

• Jeśli poziom zgodności wynosi 90 lub mniej, chyba że określono NOINDEX, DBCC CHECKDB wykonuje zarówno testy spójności fizycznej, jak i logicznej dla pojedynczej tabeli lub widoku indeksowanego oraz na wszystkich indeksach nieklastrowanych i XML. Indeksy przestrzenne nie są obsługiwane.

• W programie SQL Server 2016 (13.x) i nowszych wersjach dodatkowe kontrole dotyczące utrwalonych kolumn obliczeniowych, kolumn UDT i filtrowanych indeksów nie są uruchamiane domyślnie, aby uniknąć kosztownych ocen wyrażeń. Ta zmiana znacznie skraca długość trwania CHECKDB w przypadku baz danych zawierających te obiekty. Jednak sprawdzanie spójności fizycznej tych obiektów jest zawsze wykonywane. Tylko wtedy, gdy EXTENDED_LOGICAL_CHECKS opcja jest określona, są wykonywane oceny wyrażeń, oprócz testów logicznych, które są już obecne w ramach opcji EXTENDED_LOGICAL_CHECKS (widok indeksowany, indeksy XML i indeksy przestrzenne).

Informacje na temat poziomu zgodności bazy danych

• Wyświetl lub zmień poziom zgodności bazy danych

Wewnętrzna migawka bazy danych

DBCC CHECKDB używa wewnętrznej migawki bazy danych na potrzeby spójności transakcyjnej wymaganej do wykonania tych testów. Zapobiega to blokowaniu i problemom ze współbieżnością podczas wykonywania tych poleceń. Aby uzyskać więcej informacji, zobacz sekcję "Zobacz rozmiar rzadkiego pliku migawki bazy danych" oraz sekcję "Użycie wewnętrznej migawki bazy danych DBCC" w DBCC. Jeśli nie można utworzyć migawki lub określono TABLOCK, DBCC CHECKDB uzyskuje blokady w celu uzyskania wymaganej spójności. W takim przypadku wymagana jest wyłączna blokada bazy danych do przeprowadzania kontroli alokacji, a blokady udostępnionej tabeli są wymagane do przeprowadzania kontroli tabeli.

DBCC CHECKDB zawodzi podczas działania przeciwko bazie danych master, jeśli nie można utworzyć wewnętrznej migawki bazy danych.

Uruchamianie DBCC CHECKDB względem tempdb nie wykonuje żadnych kontroli alokacji ani wykazu i musi uzyskać udostępnione blokady tabeli w celu przeprowadzania kontroli tabeli. Wynika to z faktu, że ze względu na wydajność migawki bazy danych nie są dostępne w tempdb. Oznacza to, że nie można uzyskać wymaganej spójności transakcyjnej.

Jak DBCC CHECKDB tworzy wewnętrzną migawkową bazę danych od wersji SQL Server 2014

1. DBCC CHECKDB tworzy wewnętrzną bazę danych migawek.

2. Wewnętrzna baza danych migawek jest tworzona przy użyciu plików fizycznych. Na przykład w przypadku bazy danych z database_id = 10 z trzema plikami E:\Data\my_DB.mdf, E:\Data\my_DB.ndfi E:\Data\my_DB.ldfwewnętrzna baza danych migawek jest tworzona przy użyciu plików E:\Data\my_DB.mdf_MSSQL_DBCC11 i E:\Data\my_DB.ndf_MSSQL_DBCC11. Wartość database_id migawki to database_id + 1. Należy również pamiętać, że nowe pliki są tworzone w tym samym folderze przy użyciu konwencji nazewnictwa <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Dla dziennika transakcji nie jest tworzony żaden rozrzedny plik.

3. Nowe pliki są oznaczone jako rzadkie pliki na poziomie systemu plików. Rozmiar na dysku używany przez nowe pliki zwiększa się na podstawie ilości danych aktualizowanych w źródłowej bazie danych podczas wykonywania polecenia DBCC CHECKDB. Rozmiar nowych plików jest tym samym plikiem co plik .mdf lub .ndf.

4. Nowe pliki są usuwane na końcu przetwarzania DBCC CHECKDB. Te rozproszone pliki, które są tworzone przez DBCC CHECKDB, mają ustawiony atrybut „Usuń przy zamknięciu”.

Ostrzeżenie

Jeśli system operacyjny napotka nieoczekiwane zamknięcie, gdy polecenie DBCC CHECKDB jest w toku, te pliki nie są czyszczone. Zajmują one miejsce i mogą ewentualnie powodować błędy w przyszłych DBCC CHECKDB wykonaniach. W takim przypadku można usunąć te nowe pliki po potwierdzeniu, że obecnie nie jest wykonywane polecenie DBCC CHECKDB.

Nowe pliki są widoczne przy użyciu zwykłych narzędzi plików, takich jak Eksplorator Windows.

Notatka

Przed wprowadzeniem SQL Server 2014 (12.x) zamiast tego używano nazwanych strumieni plików do tworzenia wewnętrznych plików migawek. Nazwane strumienie plików używały formatu <nazwa_pliku.rozszerzenie>:MSSQL_DBCC<database_id_of_snapshot>. Nazwane strumienie plików nie są widoczne przy użyciu zwykłych narzędzi plików, takich jak Eksplorator Windows. W związku z tym w programie SQL Server 2012 (11.x) i starszych wersjach mogą wystąpić komunikaty o błędach 7926 i 5030 podczas uruchamiania polecenia DBCC CHECKDB dla plików baz danych znajdujących się na woluminie ReFS-formatowany. Dzieje się tak dlatego, że strumienie plików nie mogą być tworzone w odpornym systemie plików (RefS).

Sprawdzanie i naprawianie danych FILESTREAM

Po włączeniu funkcji FILESTREAM dla bazy danych i tabeli można opcjonalnie przechowywać varbinary(max) binarnych dużych obiektów (BLOB) w systemie plików. W przypadku korzystania z DBCC CHECKDB w bazie danych, która przechowuje BLOB-y w systemie plików, funkcja DBCC sprawdza spójność na poziomie powiązań między systemem plików a bazą danych.

Jeśli na przykład tabela zawiera kolumnę varbinary(max), która używa atrybutu FILESTREAM, DBCC CHECKDB sprawdza, czy istnieje mapowanie jeden do jednego między katalogami systemu plików i plikami i wierszami tabeli, kolumnami i wartościami kolumn. DBCC CHECKDB może naprawić uszkodzenie, jeśli określisz opcję REPAIR_ALLOW_DATA_LOSS. Aby naprawić uszkodzenie FILESTREAM, DBCC usuwa wszystkie wiersze tabeli, które nie mają danych systemu plików.

Najlepsze rozwiązania

Zalecamy użycie opcji PHYSICAL_ONLY w przypadku częstego użytkowania na systemach produkcyjnych. Użycie PHYSICAL_ONLY może znacznie skrócić czas wykonywania dla DBCC CHECKDB w dużych bazach danych. Zalecamy również okresowe uruchamianie DBCC CHECKDB bez opcji. Częstotliwość wykonywania tych przebiegów zależy od danego przedsiębiorstwa i jego środowiska produkcyjnego.

W usłudze Azure SQL Managed Instance dostępna przestrzeń dyskowa musi pomieścić cały wewnętrzny plik zrzutu bazy danych utworzony przez DBCC CHECKDB, niezależnie od tego, ile jest rzeczywiście używane. Może to prowadzić do sytuacji, w której wykonywanie DBCC CHECKDB w bardzo dużej, ale rozrzedowanej bazie danych (rozmiar danych jest znacznie mniejszy niż rozmiar pliku bazy danych) kończy się niepowodzeniem z powodu braku miejsca w wystąpieniu zarządzanym SQL. Jeśli DBCC CHECKDB zużywa wszystkie dostępne miejsce do magazynowania podczas wykonywania, zostanie wyświetlony następujący komunikat o błędzie:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Równoległe sprawdzanie obiektów

Domyślnie DBCC CHECKDB wykonuje równoległe sprawdzanie obiektów. Stopień równoległości jest automatycznie określany przez procesor zapytań. Maksymalny stopień równoległości jest skonfigurowany tak samo jak zapytania równoległe. Aby ograniczyć maksymalną liczbę procesorów dostępnych do sprawdzania DBCC, użyj sp_configure. Więcej informacji znajdziesz w Server configuration: max degree of parallelism. Sprawdzanie równoległe można wyłączyć przy użyciu flagi śledzenia 2528. Aby uzyskać więcej informacji, zobacz Trace Flags.

Notatka

Ta funkcja nie jest dostępna w każdej wersji programu SQL Server. Aby uzyskać więcej informacji, zobacz równoległe sprawdzanie spójności w sekcji zarządzania RDBMS wersji i obsługiwanych funkcji programu SQL Server 2022.

Omówienie komunikatów o błędach DBCC

Po zakończeniu DBCC CHECKDB polecenia zostanie zapisany komunikat w dzienniku błędów programu SQL Server. Jeśli polecenie DBCC zostanie wykonane pomyślnie, komunikat wskazuje powodzenie i czas uruchomienia polecenia. Jeśli polecenie DBCC zatrzymuje się przed zakończeniem sprawdzania z powodu błędu, komunikat wskazuje, że polecenie zostało zakończone, wartość stanu i czas uruchomienia polecenia. W poniższej tabeli wymieniono i opisano wartości stanu, które można uwzględnić w komunikacie.

Stan	Opis
0	Zgłoszono błąd 8930. Oznacza to uszkodzenie metadanych, które zakończyły działanie polecenia DBCC.
1	Zgłoszono 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 zakończyły działanie polecenia DBCC.
4	Wykryto naruszenie potwierdzenia lub dostępu.
5	Wystąpił nieznany błąd, który zakończył polecenie DBCC.

Program SQL Server rejestruje datę i godzinę uruchomienia sprawdzania spójności dla bazy danych bez błędów (lub "czyste" sprawdzanie spójności). Jest to nazywane last known clean check. Po pierwszym uruchomieniu bazy danych ta data jest zapisywana w dzienniku zdarzeń (EventID-17573) i dzienniku błędów w następującym formacie:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Raportowanie błędów

Zrzut stosu (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) jest tworzony w katalogu programu SQL Server LOG za każdym razem, gdy DBCC CHECKDB wykryje uszkodzenie. Gdy funkcje Użycie funkcji zbierania danych i raportowania błędów są włączone dla wystąpienia programu SQL Server, plik jest automatycznie przekazywany do firmy Microsoft. Zebrane dane służą do ulepszania funkcjonalności programu SQL Server. Plik zrzutu zawiera wyniki polecenia DBCC CHECKDB i dodatkowe dane wyjściowe diagnostyczne. Dostęp jest ograniczony do konta usługi programu SQL Server i członków roli administratora systemu. Domyślnie rola administratora systemu zawiera wszystkich członków grupy BUILTIN\Administrators systemu Windows i grupy administratora lokalnego. Polecenie DBCC nie ulega awarii, jeśli proces zbierania danych zakończy się niepowodzeniem.

Usuwanie błędów

Jeśli jakiekolwiek błędy są zgłaszane przez DBCC CHECKDB, zalecamy przywrócenie bazy danych z kopii zapasowej bazy danych, zamiast uruchamiania DBCC CHECKDB z jedną z opcji REPAIR_*. Jeśli żadna kopia zapasowa nie istnieje, uruchomienie naprawy poprawia zgłoszone błędy. Opcja naprawy do użycia jest określona na końcu listy zgłoszonych błędów. Jednak skorygowanie błędów przy użyciu opcji REPAIR_ALLOW_DATA_LOSS może wymagać usunięcia niektórych stron, a w związku z tym niektórych danych.

W pewnych okolicznościach wartości mogą być wprowadzane do bazy danych, które nie są prawidłowe lub znajdują się poza zakresem w zależności od typu danych kolumny. DBCC CHECKDB może wykrywać wartości kolumn, które nie są prawidłowe dla wszystkich typów danych kolumn. W związku z tym uruchomienie DBCC CHECKDB z opcją DATA_PURITY w bazach danych, które zostały uaktualnione z wcześniejszych wersji programu SQL Server, może ujawnić istniejące błędy wartości kolumny. Ponieważ program SQL Server nie może automatycznie naprawić tych błędów, wartość kolumny musi zostać zaktualizowana ręcznie. Jeśli CHECKDB wykryje taki błąd, CHECKDB zwróci ostrzeżenie, numer błędu 2570 oraz informacje w celu zidentyfikowania odpowiedniego wiersza i ręcznego skorygowania błędu.

Naprawę można wykonać w ramach transakcji użytkownika, aby umożliwić użytkownikowi wycofanie wprowadzonych zmian. Jeśli naprawy zostaną wycofane, baza danych nadal zawiera błędy i musi zostać przywrócona z kopii zapasowej. Po zakończeniu napraw wykonaj kopię zapasową bazy danych.

Usuwanie błędów w trybie awaryjnym bazy danych

Jeśli baza danych została ustawiona na tryb awaryjny przy użyciu instrukcji ALTER DATABASE, DBCC CHECKDB może wykonać specjalne naprawy w bazie danych, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS. Te naprawy mogą umożliwić przywrócenie zazwyczaj niemożliwych do odzyskania baz danych do stanu fizycznej spójności i ponownego ich uruchomienia. Te naprawy powinny być używane w ostateczności i tylko wtedy, gdy nie można przywrócić bazy danych z kopii zapasowej. Gdy baza danych jest ustawiona na tryb awaryjny, jest oznaczona jako READ_ONLY, rejestrowanie jest wyłączone, a dostęp jest ograniczony do członków stałej roli serwera sysadmin.

Notatka

Nie można uruchomić polecenia DBCC CHECKDB w trybie awaryjnym wewnątrz transakcji użytkownika i wycofać transakcji po wykonaniu.

Gdy baza danych jest w trybie awaryjnym i DBCC CHECKDB z klauzulą REPAIR_ALLOW_DATA_LOSS jest uruchamiana, są wykonywane następujące akcje:

• DBCC CHECKDB wykorzystuje strony, które zostały oznaczone jako niedostępne z powodu błędów wejścia/wyjścia lub sumy kontrolnej, tak jakby te błędy nie wystąpiły. W ten sposób zwiększa się prawdopodobieństwo odzyskiwania danych z bazy danych.

• DBCC CHECKDB próbuje odzyskać bazę danych przy użyciu zwykłych technik odzyskiwania opartych na dziennikach.

• Jeśli odzyskiwanie bazy danych nie powiedzie się z powodu uszkodzenia dziennika transakcji, dziennik transakcji zostanie ponownie skompilowany. Ponowne kompilowanie dziennika transakcji może spowodować utratę spójności transakcyjnej.

Ostrzeżenie

Opcja REPAIR_ALLOW_DATA_LOSS może spowodować utratę większej ilości danych niż w przypadku przywrócenia z ostatniej znanej dobrej kopii zapasowej. Zapoznaj się z ostrzeżeniem o utracie danych przy użyciu REPAIR_ALLOW_DATA_LOSS

Jeśli polecenie DBCC CHECKDB powiedzie się, baza danych jest w stanie fizycznie spójnym, a stan bazy danych jest ustawiony na ONLINE. Jednak baza danych może zawierać co najmniej jedną niespójność transakcyjną. Zalecamy uruchomienie DBCC CHECKCONSTRAINTS, aby zidentyfikować wszelkie wady logiki biznesowej i natychmiast utworzyć kopię zapasową bazy danych.

Jeśli polecenie DBCC CHECKDB zakończy się niepowodzeniem, nie można naprawić bazy danych.

Ostrzeżenie o utracie danych przy użyciu REPAIR_ALLOW_DATA_LOSS

Opcja REPAIR_ALLOW_DATA_LOSS jest obsługiwaną funkcją programu SQL Server. Jednak nie zawsze może być najlepszą opcją do doprowadzenia bazy danych do stanu fizycznie spójnego. W przypadku powodzenia opcja REPAIR_ALLOW_DATA_LOSS może spowodować utratę danych.

W rzeczywistości może to spowodować utratę większej ilości danych, niż gdyby użytkownik przywrócił bazę danych z ostatniej znanej dobrej kopii zapasowej. Firma Microsoft zawsze zaleca przywracanie systemu z ostatniej znanej dobrej kopii zapasowej jako podstawowej metody odzyskiwania danych po błędach zgłoszonych przez DBCC CHECKDB.

Opcja REPAIR_ALLOW_DATA_LOSS nie jest alternatywą dla przywracania ze znanej dobrej kopii zapasowej. Jest to opcja awaryjna zalecana do użycia tylko wtedy, gdy przywracanie z kopii zapasowej jest niemożliwe.

Po odbudowie dziennika nie ma pełnej gwarancji na zgodność z ACID.

Po odbudowaniu dziennika wykonanie DBCC CHECKDB jest automatyczne i zarówno naprawia, jak i raportuje problemy ze spójnością fizyczną.

Spójność danych logicznych oraz wymuszone przez logikę biznesową ograniczenia muszą być weryfikowane ręcznie.

Rozmiar dziennika transakcji jest pozostawiony do domyślnego rozmiaru i musi zostać ręcznie dostosowany do jego ostatniego rozmiaru.

Uruchom polecenie DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS w replikowanych bazach danych

Uruchomienie polecenia DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS może mieć wpływ na bazy danych użytkowników (bazy danych publikacji i subskrypcji) oraz bazę danych dystrybucji używaną przez replikację. Bazy danych publikacji i subskrypcji obejmują opublikowane tabele i tabele metadanych dotyczących replikacji. Należy pamiętać o następujących potencjalnych problemach w tych bazach danych:

• Opublikowane tabele. Akcje wykonywane przez proces CHECKDB naprawy uszkodzonych danych użytkownika mogą nie być replikowane:

• Replikacja scalania używa wyzwalaczy do śledzenia zmian w opublikowanych tabelach. Jeśli wiersze są wstawiane, aktualizowane lub usuwane przez proces CHECKDB, wyzwalacze nie są wyzwalane; dlatego zmiana nie jest replikowana.

• Replikacja transakcyjna używa dziennika transakcji do śledzenia zmian w opublikowanych tabelach. Następnie agent czytnika dzienników przenosi te zmiany do bazy danych dystrybucji. Niektóre naprawy DBCC, chociaż zarejestrowane, nie mogą być replikowane przez Agenta Log Reader. Jeśli na przykład alokacja strony danych zostanie cofnięta przez proces CHECKDB, agent czytnika dzienników nie tłumaczy tej dezalokacji na instrukcję DELETE; w związku z tym zmiana nie jest replikowana.

• Tabele metadanych replikacji. Akcje wykonywane przez proces CHECKDB w celu naprawy uszkodzonych tabel metadanych replikacji wymagają usunięcia i ponownego skonfigurowania replikacji.

Jeśli musisz uruchomić polecenie DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS w bazie danych użytkownika lub bazie danych dystrybucji:

1. Wstrzymaj system: Zatrzymaj aktywność w bazie danych oraz we wszystkich innych bazach danych w topologii replikacji, a następnie spróbuj zsynchronizować wszystkie węzły. Aby uzyskać więcej informacji, zobacz Quiesce a Replication Topology (Replication Transact-SQL Programming).

2. Wykonaj DBCC CHECKDB.

3. Jeśli raport DBCC CHECKDB zawiera naprawy wszystkich tabel w bazie danych dystrybucji lub wszystkich tabel metadanych replikacji w bazie danych użytkownika, usuń i ponownie skonfiguruj replikację. Aby uzyskać więcej informacji, zobacz Wyłączanie publikacji i dystrybucji.

4. Jeśli raport DBCC CHECKDB zawiera naprawy wszystkich replikowanych tabel, przeprowadź walidację danych, aby ustalić, czy istnieją różnice między danymi w bazie danych publikacji i subskrypcji.

Zestaw wyników

DBCC CHECKDB zwraca następujący zestaw wyników. Wartości mogą się różnić z wyjątkiem sytuacji, w których określono opcje ESTIMATEONLY, PHYSICAL_ONLYlub NO_INFOMSGS:

DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB zwraca następujący zestaw wyników (komunikat) po określeniu NO_INFOMSGS:

The command(s) completed successfully.

DBCC CHECKDB zwraca następujący zestaw wyników po określeniu PHYSICAL_ONLY:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB zwraca następujący zestaw wyników po określeniu ESTIMATEONLY.

Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Uprawnienia

Wymaga członkostwa w sysadmin stałej roli serwera lub stałej roli bazy danych db_owner.

Przykłady

A. Sprawdź zarówno bieżącą, jak i inną bazę danych

Poniższy przykład wykonuje DBCC CHECKDB dla bieżącej bazy danych oraz dla bazy danych AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO

-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Sprawdź bieżącą bazę danych, pomijając komunikaty informacyjne

Poniższy przykład sprawdza bieżącą bazę danych i pomija wszystkie komunikaty informacyjne.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Powiązana zawartość

• DBCC (Transact-SQL)
• Wyświetl rozmiar rzadkiego pliku migawki bazy danych (Transact-SQL)
• sp_helpdb (Transact-SQL)
• tabele systemu (Transact-SQL)