DBCC CHECKDB (Transact-SQL)

• 12/14/2017
• 22 minuty na przeczytanie
• • p
  • M

  .

  • m
  • M
  • P
  • +3

Dotyczy: SQL Server (wszystkie obsługiwane wersje) Azure SQL Database

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

• Uruchamia DBCC CHECKALLOC na bazie danych.
• Uruchamia DBCC CHECKTABLE na każdej tabeli i widoku w bazie danych.
• Uruchamia DBCC CHECKCATALOG na bazie danych.
• Weryfikuje zawartość każdego widoku indeksowanego w bazie danych.
• Weryfikuje spójność na poziomie łącza między metadanymi tabel a katalogami i plikami systemu plików podczas przechowywania danych varbinary(max) w systemie plików przy użyciu FILESTREAM.
• Weryfikuje dane pośrednika usług w bazie danych.

To oznacza, że polecenia DBCC CHECKALLOC, DBCC CHECKTABLE lub DBCC CHECKCATALOG nie muszą być uruchamiane oddzielnie od DBCC CHECKDB. Aby uzyskać bardziej szczegółowe informacje na temat kontroli wykonywanych przez te polecenia, zobacz opisy tych poleceń.

Konwencje składni języka Transact-SQL

Syntaktyka

DBCC CHECKDB ) ] } ] ] 

Argumenty

nazwa_bazy_danych | nazwa_bazy_id | 0
Jest nazwą lub identyfikatorem bazy danych, dla której ma zostać uruchomiona kontrola integralności. Jeśli nie podano lub jeśli podano 0, używana jest bieżąca baza danych. Nazwy baz danych muszą być zgodne z regułami dla identyfikatorów.

NOINDEX
Określa, że intensywne sprawdzanie indeksów nieklastrowych dla tabel użytkownika nie powinno być wykonywane. Zmniejsza to całkowity czas wykonania. NOINDEX nie ma wpływu na tabele systemowe, ponieważ kontrole integralności są zawsze wykonywane na indeksach tabel systemowych.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Określa, że DBCC CHECKDB ma naprawiać znalezione błędy. Opcji REPAIR należy używać tylko w ostateczności. Określona baza danych musi znajdować się w trybie pojedynczego użytkownika, aby można było użyć jednej z poniższych opcji naprawy.

REPAIR_ALLOW_DATA_LOSS
Próbuje naprawić wszystkie zgłoszone błędy. Naprawy te mogą spowodować pewną utratę danych.

REPAIR_FAST
Zachowuje składnię tylko dla kompatybilności wstecznej. Nie są wykonywane żadne czynności naprawcze.

REPAIR_REBUILD
Wykonuje naprawy, które nie powodują utraty danych. Może to obejmować szybkie naprawy, takie jak naprawa brakujących wierszy w indeksach nieklastrowych, oraz bardziej czasochłonne naprawy, takie jak odbudowa indeksu.
Ten argument nie naprawia błędów dotyczących danych FILESTREAM.

ALL_ERRORMSGS
Wyświetla wszystkie zgłoszone błędy dla obiektu. Domyślnie wyświetlane są wszystkie komunikaty o błędach. Podanie lub pominięcie tej opcji nie ma żadnego efektu. Komunikaty o błędach są sortowane według ID obiektu, z wyjątkiem komunikatów wygenerowanych z bazy danych tempdb.

EXTENDED_LOGICAL_CHECKS
Jeśli poziom zgodności wynosi 100 (SQL Server 2008) lub wyższy, wykonuje sprawdzanie spójności logicznej dla widoku indeksowanego, indeksów XML oraz indeksów przestrzennych, jeśli są obecne.
Więcej informacji na ten temat znajduje się w sekcji Wykonywanie sprawdzania spójności logicznej indeksów w sekcji Uwagi w dalszej części tego tematu.

NO_INFOMSGS
Wyłącza wszystkie komunikaty informacyjne.

TABLOCK
Wywołuje DBCC CHECKDB do uzyskania blokad zamiast używania wewnętrznych migawek bazy danych. Obejmuje to krótkotrwałą blokadę wyłączną (X) na bazie danych. TABLOCK spowoduje, że DBCC CHECKDB będzie działać szybciej na bazie danych pod dużym obciążeniem, ale zmniejszy współbieżność dostępną na bazie danych podczas działania DBCC CHECKDB.

ESTIMATEONLY
Wyświetla szacunkową ilość miejsca w bazie danych, która jest wymagana do uruchomienia DBCC CHECKDB przy wszystkich innych określonych opcjach. Rzeczywiste sprawdzanie bazy danych nie jest wykonywane.

PHYSICAL_ONLY
Zawęża sprawdzanie do integralności fizycznej struktury nagłówków stron i rekordów oraz spójności alokacyjnej bazy danych. Ta kontrola została zaprojektowana w celu zapewnienia niewielkiego ogólnego sprawdzenia fizycznej spójności bazy danych, ale może również wykryć rozdarte strony, błędy sum kontrolnych i typowe awarie sprzętu, które mogą zagrozić danym użytkownika.
Pełne uruchomienie DBCC CHECKDB może trwać znacznie dłużej niż w przypadku wcześniejszych wersji. Zachowanie to występuje, ponieważ:

• Sprawdzenia logiczne są bardziej wszechstronne.
• Niektóre ze struktur bazowych podlegających sprawdzeniu są bardziej złożone.
• Wprowadzono wiele nowych sprawdzeń w celu uwzględnienia nowych funkcji.
  W związku z tym użycie opcji PHYSICAL_ONLY może spowodować znacznie krótszy czas działania DBCC CHECKDB na dużych bazach danych i jest zalecane do częstego stosowania w systemach produkcyjnych. Nadal zalecamy, aby okresowo wykonywać pełne uruchomienie DBCC CHECKDB. Częstotliwość tych uruchomień 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 opcji naprawy.

DATA_PURITY
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 czasu, które są większe lub mniejsze niż dopuszczalny zakres dla typu danych datetime; lub kolumny typu danych dziesiętnych lub przybliżonych liczbowych z wartościami skali lub precyzji, które nie są ważne.
Sprawdzanie integralności wartości kolumn jest domyślnie włączone i nie wymaga opcji DATA_PURITY. W przypadku baz danych zaktualizowanych z wcześniejszych wersji SQL Server, sprawdzanie wartości kolumn nie jest domyślnie włączone, dopóki DBCC CHECKDB WITH DATA_PURITY nie zostanie bezbłędnie uruchomione na bazie danych. Po tym DBCC CHECKDB domyślnie sprawdza integralność wartości kolumn. Aby uzyskać więcej informacji o tym, jak na CHECKDB może wpłynąć aktualizacja bazy danych z wcześniejszych wersji SQL Server, zobacz sekcję Uwagi w dalszej części tego tematu.

Błędy sprawdzania poprawności zgłaszane przez tę opcję nie mogą być naprawione za pomocą opcji naprawy DBCC. Informacje na temat ręcznego poprawiania tych błędów można znaleźć w artykule Knowledge Base article 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 and later versions.

MAXDOP
Applies to: SQL Server ( SQL Server 2014 (12.x) SP2 i nowsze).

Nadpisuje opcję konfiguracji max degree of parallelism w sp_configure dla instrukcji. MAXDOP może przekroczyć wartość skonfigurowaną za pomocą sp_configure. Jeśli MAXDOP przekracza wartość skonfigurowaną za pomocą Resource Governor, silnik bazy danych SQL Server używa wartości Resource Governor MAXDOP, opisanej w ALTER WORKLOAD GROUP. Wszystkie reguły semantyczne używane z opcją konfiguracji max degree of parallelism mają zastosowanie, gdy używana jest podpowiedź MAXDOP. Aby uzyskać więcej informacji, zobacz Konfiguracja opcji konfiguracyjnej serwera max degree of parallelism.

Uwagi

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

Jeśli typ zdefiniowany przez użytkownika jest oznaczony jako uporządkowany bajtowo, musi istnieć tylko jedna serializacja typu zdefiniowanego przez użytkownika. Brak spójnej serializacji typów zdefiniowanych przez użytkownika uporządkowanych bajtowo powoduje błąd 2537 podczas uruchamiania polecenia DBCC CHECKDB. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące typów zdefiniowanych przez użytkownika.

Ponieważ baza danych Resource jest modyfikowalna tylko w trybie pojedynczego użytkownika, nie można na niej bezpośrednio uruchomić polecenia DBCC CHECKDB. Jednak gdy polecenie DBCC CHECKDB jest wykonywane względem głównej bazy danych, drugie CHECKDB jest również uruchamiane wewnętrznie na bazie danych Resource. Oznacza to, że DBCC CHECKDB może zwracać dodatkowe wyniki. Polecenie zwraca dodatkowe zestawy wyników, gdy nie są ustawione żadne opcje lub gdy ustawiona jest opcja PHYSICAL_ONLY lub ESTIMATEONLY.

Począwszy od wersji SQL Server 2005 (9.x) SP2, wykonanie polecenia DBCC CHECKDB nie powoduje już wyczyszczenia pamięci podręcznej planu dla instancji programu SQL Server. Przed SQL Server 2005 (9.x) SP2, wykonanie DBCC CHECKDB powoduje wyczyszczenie pamięci podręcznej planu. Wyczyszczenie pamięci podręcznej planów powoduje ponowną kompilację wszystkich późniejszych planów wykonania i może spowodować nagły, tymczasowy spadek wydajności zapytania.

Wykonywanie sprawdzania spójności logicznej na indeksach

Sprawdzanie spójności logicznej na indeksach różni się w zależności od poziomu zgodności bazy danych, jak poniżej:

• Jeśli poziom zgodności wynosi 100 (SQL Server 2008) lub więcej:
• Jeśli nie określono NOINDEX, DBCC CHECKDB wykonuje zarówno fizyczne, jak i logiczne sprawdzanie spójności na pojedynczej tabeli i na wszystkich jej indeksach nieklastrowych. Jednak na indeksach XML, indeksach przestrzennych i widokach indeksowanych domyślnie wykonywane są tylko fizyczne sprawdzenia spójności.
• Jeśli określono WITH EXTENDED_LOGICAL_CHECKS, sprawdzenia logiczne są wykonywane na widoku indeksowanym, indeksach XML i indeksach przestrzennych, jeśli występują. Domyślnie sprawdzanie spójności fizycznej jest wykonywane przed sprawdzaniem spójności logicznej. Jeśli NOINDEX jest również określone, wykonywane są tylko sprawdzenia logiczne.

Sprawdzenia spójności logicznej sprawdzają wewnętrzną tabelę indeksu obiektu indeksu z tabelą użytkownika, do której się odwołuje. Aby znaleźć wiersze odstające, konstruowane jest zapytanie wewnętrzne, które wykonuje pełne przecięcie tabeli wewnętrznej i tabeli użytkownika. Uruchomienie tego zapytania może mieć bardzo duży 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 niezwiązane z uszkodzeniem fizycznym lub gdy sumy kontrolne na poziomie strony zostały wyłączone i podejrzewasz uszkodzenie sprzętowe na poziomie kolumny.

• Jeśli indeks jest indeksem filtrowanym, DBCC CHECKDB wykonuje sprawdzanie spójności, aby zweryfikować, czy wpisy indeksu spełniają predykat filtrowania.
• Jeśli poziom zgodności wynosi 90 lub mniej, chyba że określono NOINDEX, DBCC CHECKDB wykonuje zarówno fizyczne, jak i logiczne sprawdzenia spójności na pojedynczej tabeli lub widoku indeksowanym oraz na wszystkich jego indeksach nieklastrowych i XML. Indeksy przestrzenne nie są obsługiwane.
• Począwszy od wersji SQL Server 2016, dodatkowe sprawdzenia dotyczące persystowanych kolumn obliczeniowych, kolumn UDT i filtrowanych indeksów nie będą domyślnie uruchamiane, aby uniknąć kosztownych ocen wyrażeń. Zmiana ta znacznie skraca czas działania CHECKDB w stosunku do baz danych zawierających te obiekty. Jednakże fizyczne sprawdzanie spójności tych obiektów jest zawsze zakończone. Tylko wtedy, gdy określona jest opcja EXTENDED_LOGICAL_CHECKS, oceny wyrażeń będą wykonywane dodatkowo do już obecnych sprawdzeń logicznych (widok indeksowany, indeksy XML i indeksy przestrzenne) jako część opcji EXTENDED_LOGICAL_CHECKS.

Aby poznać poziom zgodności bazy danych

• Pokaż lub zmień poziom zgodności bazy danych

Wewnętrzna migawka bazy danych

DBCC CHECKDB używa wewnętrznej migawki bazy danych do zapewnienia spójności transakcyjnej potrzebnej do wykonania tych kontroli. Zapobiega to blokowaniu i problemom ze współbieżnością podczas wykonywania tych poleceń. Aby uzyskać więcej informacji, zobacz sekcję Wyświetlanie rozmiaru nielicznych plików migawki bazy danych (Transact-SQL) oraz sekcję Użycie wewnętrznej migawki bazy danych DBCC w DBCC (Transact-SQL). Jeżeli nie można utworzyć migawki lub określono TABLOCK, DBCC CHECKDB nabywa blokady w celu uzyskania wymaganej spójności. W tym przypadku do wykonania kontroli alokacji wymagana jest wyłączna blokada bazy danych, a do wykonania kontroli tabel wymagane są współdzielone blokady tabel.DBCC CHECKDB nie powiedzie się przy uruchomieniu przeciwko master, jeśli nie można utworzyć migawki wewnętrznej bazy danych.Uruchomienie DBCC CHECKDB przeciwko tempdb nie wykonuje żadnych kontroli alokacji ani katalogów i musi uzyskać współdzielone blokady tabel w celu wykonania kontroli tabel. Dzieje się tak dlatego, że ze względów wydajnościowych migawki bazy danych nie są dostępne na tempdb. Oznacza to, że nie można uzyskać wymaganej spójności transakcyjnej.W Microsoft SQL Server 2012 lub wcześniejszej wersji SQL Server, możesz napotkać komunikaty o błędach podczas uruchamiania polecenia DBCC CHECKDB dla bazy danych, której pliki znajdują się na woluminie sformatowanym w ReFS. Aby uzyskać więcej informacji, zobacz artykuł Bazy wiedzy 2974455: Zachowanie DBCC CHECKDB, gdy baza danych SQL Server znajduje się na woluminie ReFS.

Sprawdzanie i naprawa danych FILESTREAM

Gdy FILESTREAM jest włączony dla bazy danych i tabeli, można opcjonalnie przechowywać varbinary(max) binary large objects (BLOBs) w systemie plików. Podczas używania DBCC CHECKDB na bazie danych, która przechowuje BLOB-y w systemie plików, DBCC sprawdza spójność na poziomie łącza między systemem plików a bazą danych. Na przykład, jeśli tabela zawiera kolumnę varbinary(max), która używa atrybutu FILESTREAM, DBCC CHECKDB sprawdzi, czy istnieje odwzorowanie jeden do jednego między katalogami i plikami systemu plików a wierszami, kolumnami i wartościami kolumn tabeli. DBCC CHECKDB może naprawić uszkodzenie, jeśli określisz opcję REPAIR_ALLOW_DATA_LOSS. Aby naprawić uszkodzenie FILESTREAM, DBCC usunie wszystkie wiersze tabeli, w których brakuje danych systemu plików.

Najlepsze praktyki

Zalecamy używanie opcji PHYSICAL_ONLY do częstego stosowania w systemach produkcyjnych. Użycie PHYSICAL_ONLY może znacznie skrócić czas wykonywania DBCC CHECKDB na dużych bazach danych. Zalecamy również okresowe uruchamianie DBCC CHECKDB bez żadnych opcji. To, jak często należy wykonywać te przebiegi, zależy od poszczególnych firm i ich środowisk produkcyjnych.

Sprawdzanie obiektów równolegle

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 konfigurowany tak samo jak zapytania równoległe. Aby ograniczyć maksymalną liczbę procesorów dostępnych dla sprawdzania DBCC, użyj sp_configure. Aby uzyskać więcej informacji, zobacz Konfiguracja maksymalnego stopnia równoległości Opcja konfiguracji serwera. Sprawdzanie równoległe może być wyłączone przez użycie flagi trace 2528. Aby uzyskać więcej informacji, zobacz Flagi śledzenia (Transact-SQL).

Zrozumienie komunikatów o błędach DBCC

Po zakończeniu działania polecenia DBCC CHECKDB do dziennika błędów SQL Server zapisywany jest komunikat. Jeśli polecenie DBCC wykona się pomyślnie, komunikat informuje o powodzeniu i czasie działania polecenia. Jeśli polecenie DBCC zatrzyma się przed zakończeniem sprawdzania z powodu błędu, komunikat wskazuje, że polecenie zostało przerwane, wartość stanu oraz czas działania polecenia. Poniższa tabela zawiera listę i opis wartości stanu, które mogą być zawarte w komunikacie.

Stan	Opis
0	Podniesiono numer błędu 8930. Wskazuje to na uszkodzenie metadanych, które zakończyło działanie polecenia DBCC.
1	Podniesiono numer błędu 8967. Wystąpił wewnętrzny błąd DBCC.
2	Podczas naprawy bazy danych w trybie awaryjnym wystąpiła awaria.
3	Wskazuje to na uszkodzenie metadanych, które zakończyło działanie polecenia DBCC.
4	Wykryto naruszenie asercji lub dostępu.
5	Wystąpił nieznany błąd, który zakończył działanie polecenia DBCC.

Raportowanie błędów

Plik zrzutu (SQLDUMP*nnnn*.txt) jest tworzony w katalogu SQL Server LOG za każdym razem, gdy DBCC CHECKDB wykryje błąd uszkodzenia. Jeśli dla instancji SQL Server włączone są funkcje zbierania danych Feature Usage i raportowania błędów, plik ten jest automatycznie przekazywany do firmy Microsoft. Zebrane dane są wykorzystywane do poprawy funkcjonalności serwera SQL.Plik dump zawiera wyniki polecenia DBCC CHECKDB oraz dodatkowe dane diagnostyczne. Dostęp jest ograniczony do konta usługi SQL Server i członków roli sysadmin. Domyślnie, rola sysadmin zawiera wszystkich członków grupy Windows BUILTIN\Administrators i grupy lokalnego administratora. Polecenie DBCC nie kończy się niepowodzeniem, jeśli proces zbierania danych nie powiedzie się.

Rozwiązywanie błędów

Jeśli DBCC CHECKDB zgłosi jakiekolwiek błędy, zalecamy przywrócenie bazy danych z kopii zapasowej bazy danych zamiast uruchamiania REPAIR z jedną z opcji REPAIR. Jeśli nie istnieje kopia zapasowa, uruchomienie naprawy naprawia zgłoszone błędy. Opcja naprawy, której należy użyć, jest określona na końcu listy zgłoszonych błędów. Jednak naprawienie błędów za pomocą opcji REPAIR_ALLOW_DATA_LOSS może wymagać usunięcia niektórych stron, a zatem niektórych danych.

W pewnych okolicznościach do bazy danych mogą być wprowadzane wartości, które nie są prawidłowe lub wykraczają poza zakres w oparciu o typ danych kolumny. DBCC CHECKDB może wykryć wartości kolumn, które nie są prawidłowe dla wszystkich typów danych kolumn. Dlatego też uruchomienie DBCC CHECKDB z opcją DATA_PURITY na bazach danych, które zostały zaktualizowane z wcześniejszych wersji SQL Server, może ujawnić istniejące wcześniej błędy wartości kolumn. Ponieważ SQL Server nie może automatycznie naprawić tych błędów, wartość kolumny musi zostać ręcznie zaktualizowana. Jeśli CHECKDB wykryje taki błąd, zwraca ostrzeżenie, numer błędu 2570 oraz informacje umożliwiające zidentyfikowanie dotkniętego wiersza i ręczne naprawienie błędu.

Naprawa może być wykonana w ramach transakcji użytkownika, aby umożliwić użytkownikowi cofnięcie wprowadzonych zmian. Jeśli naprawa zostanie cofnięta, baza danych nadal będzie zawierać błędy i musi zostać przywrócona z kopii zapasowej. Po zakończeniu naprawy należy wykonać kopię zapasową bazy danych.

Resolving Errors in Database Emergency Mode

Gdy baza danych została ustawiona w tryb awaryjny za pomocą polecenia ALTER DATABASE, DBCC CHECKDB może wykonać pewne specjalne naprawy bazy danych, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS. Naprawy te mogą pozwolić na przywrócenie normalnie nieodzyskiwalnych baz danych w stanie fizycznie spójnym. Naprawy te powinny być stosowane jako ostateczność i tylko wtedy, gdy nie można przywrócić bazy danych z kopii zapasowej. Gdy baza danych jest ustawiona w trybie awaryjnym, baza danych jest oznaczona jako READ_ONLY, logowanie jest wyłączone, a dostęp jest ograniczony do członków stałej roli serwera sysadmin.

Gdy baza danych znajduje się w trybie awaryjnym i uruchomione jest polecenie DBCC CHECKDB z klauzulą REPAIR_ALLOW_DATA_LOSS, podejmowane są następujące działania:

• DBCC CHECKDB używa stron, które zostały oznaczone jako niedostępne z powodu błędów we/wy lub sum kontrolnych, tak jakby błędy te nie wystąpiły. Takie postępowanie zwiększa szanse na odzyskanie danych z bazy danych.
• DBCC CHECKDB próbuje odzyskać bazę danych przy użyciu zwykłych technik odzyskiwania opartych na dzienniku transakcji.
• Jeśli z powodu uszkodzenia dziennika transakcji odzyskiwanie bazy danych nie powiedzie się, dziennik transakcji jest odbudowywany. Odbudowa dziennika transakcji może spowodować utratę spójności transakcyjnej.

Jeśli polecenie DBCC CHECKDB powiedzie się, baza danych jest fizycznie spójna, a status bazy danych jest ustawiony na ONLINE. Jednakże baza danych może zawierać jedną lub więcej niespójności transakcyjnych. Zalecamy uruchomienie polecenia DBCC CHECKCONSTRAINTS w celu zidentyfikowania wszelkich błędów logiki biznesowej i natychmiastowe utworzenie kopii zapasowej bazy danych.Jeśli polecenie DBCC CHECKDB nie powiedzie się, bazy danych nie można naprawić.

Uruchamianie polecenia DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS w replikowanych bazach danych

Uruchamianie 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 dystrybucyjną bazę danych używaną przez replikację. Bazy danych publikacji i subskrypcji zawierają tabele publikowane i tabele metadanych replikacji. Należy być świadomym następujących potencjalnych problemów w tych bazach danych:

• Published tables. Akcje wykonywane przez proces CHECKDB w celu naprawy uszkodzonych danych użytkownika mogą nie być replikowane:
• Replikacja merge używa wyzwalaczy do śledzenia zmian w tabelach opublikowanych. Jeśli wiersze są wstawiane, aktualizowane lub usuwane przez proces CHECKDB, wyzwalacze nie są uruchamiane; dlatego zmiana nie jest replikowana.
• Replikacja transakcyjna używa dziennika transakcji do śledzenia zmian w publikowanych tabelach. Agent czytający dziennik transakcji przenosi następnie te zmiany do dystrybucyjnej bazy danych. Niektóre naprawy DBCC, mimo że są rejestrowane, nie mogą być replikowane przez Agenta czytającego logi. Na przykład, jeśli strona danych jest deallocowana przez proces CHECKDB, Log Reader Agent nie tłumaczy tego na instrukcję DELETE; dlatego zmiana nie jest replikowana.
• Tabele metadanych replikacji. Czynności 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 na bazie danych użytkownika lub dystrybucyjnej bazie danych:

1. Zatrzymaj system: Zatrzymaj aktywność na bazie danych i na 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 dla jakichkolwiek tabel w dystrybucyjnej bazie danych lub jakichkolwiek tabel metadanych replikacji w bazie danych użytkownika, usuń i ponownie skonfiguruj replikację. Aby uzyskać więcej informacji, zobacz Wyłączanie publikowania i dystrybucji.
4. Jeśli raport DBCC CHECKDB zawiera naprawy dla jakichkolwiek replikowanych tabel, wykonaj sprawdzanie poprawności danych, aby określić, czy istnieją różnice między danymi w bazach danych publikacji i subskrypcji.

Zestawy wyników

DBCC CHECKDB zwraca następujący zestaw wyników. Wartości mogą się różnić, z wyjątkiem sytuacji, gdy określono opcje ESTIMATEONLY, PHYSICAL_ONLY lub 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), gdy określono NO_INFOMSGS:

 The command(s) completed successfully.

DBCC CHECKDB zwraca następujący zestaw wyników, gdy określona jest opcja 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, gdy określona jest opcja 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 stałej roli serwera sysadmin lub stałej roli bazy danych db_owner.

Przykłady

A. Sprawdzanie zarówno bieżącej, jak i innej bazy danych

Następujący przykład wykonuje polecenie DBCC CHECKDB dla bieżącej bazy danych i dla bazy danych AdventureWorks2012.

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

B. Sprawdzanie bieżącej bazy danych, tłumienie komunikatów informacyjnych

Następujący przykład sprawdza bieżącą bazę danych i tłumi wszystkie komunikaty informacyjne.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Zobacz także

DBCC (Transact-SQL)
View the Size of the Sparse File of a Database Snapshot (Transact-SQL)
sp_helpdb (Transact-SQL)
System Tables (Transact-SQL)

.