• Artykuł

DBCC CHECKDB (Transact-SQL)

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

  • Uruchamia dbcc checkalloc w bazie danych.

  • Uruchamia dbcc checktable w każdej tabela i widoku w bazie danych.

  • Uruchamia dbcc checkcatalog w bazie danych.

  • Sprawdza zawartość każdego indeksowany widok w bazie danych.

  • Sprawdza łącze -poziom spójności tabela metadane i plików i katalogów w systemie plików podczas przechowywania varbinary(max) danych w systemie plików przy użyciu FILESTREAM.

  • Sprawdza poprawność Service Broker danych w bazie danych.

Oznacza to, że polecenia DBCC CHECKALLOC, DBCC CHECKTABLE lub DBCC CHECKCATALOG nie mają być uruchamiane niezależnie od DBCC CHECKDB.Aby uzyskać szczegółowe informacje dotyczące kontroli, które wykonują tych poleceń zobacz opisy tych poleceń.

Ikona łącza do tematuJęzyka Transact-SQL składni konwencje

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 } ]
        }
    ]
]

Argumenty

  • database_name | database_id | 0
    To nazwa lub identyfikator bazy danych, który chcesz uruchomić sprawdzanie integralność .Jeśli nie określono lub określono wartość 0, bieżąca baza danych jest używany.Nazwy bazy danych muszą być zgodne z zasadami identyfikatorów.

  • NOINDEX
    Określa intensywnych kontroli ponownego zbudowania indeksów dla tabel użytkownika nie należy wykonać.Zmniejsza ogólny wykonanie czas.NOINDEX nie wpływa na tabele systemowe , ponieważ jest zawsze wykonywane sprawdzanie integralność w tabela systemowa indeksów.

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    Określa, że DBCC CHECKDB naprawić błędy znalezione.Określonej bazy danychmusi być w tryb jednego użytkownika , aby użyć jednej z następujących opcji naprawy.

    • REPAIR_ALLOW_DATA_LOSS
      Próbuje naprawić wszystkich błędów.Te naprawy może spowodować utratę danych.

    • REPAIR_FAST
      Zachowuje składni zgodność z poprzednimi wersjami.Są wykonywane żadne akcje naprawy.

    • REPAIR_REBUILD
      Dokonuje napraw, które mają możliwości utraty danych.Może to dotyczyć szybkiej naprawy, takich jak naprawianie brakujących wierszy w indeksami nieklastrowanymi i więcej czas-używające naprawy, takich jak odbudowanie indeksu.

      REPAIR_REBUILD nie naprawia błędy danych FILESTREAM.

    Ważna informacjaWażne:

    Użyj opcji naprawy tylko w ostateczności.Aby naprawić błędy, zaleca się przywrócenie z kopia zapasowa.Operacje naprawy uważa ograniczenia, które mogą istnieć na lub między tabelami.Określona tabela jest zaangażowany w jednej lub więcej ograniczeń, zaleca się z systemem DBCC CHECKCONSTRAINTS po operacji naprawiania.Jeśli musisz użyć naprawy, uruchom DBCC CHECKDB bez opcji naprawy znaleźć naprawy poziom używania.Jeśli używasz REPAIR_ALLOW_DATA_LOSS poziom, zaleca się, to możesz tworzyć kopię zapasową bazy danych przed uruchomieniem DBCC CHECKDB przy użyciu tej opcji.

  • ALL_ERRORMSGS
    Wyświetla wszystkie błędy raportowane na obiekt.Domyślnie są wyświetlane wszystkie komunikaty o błędach.Określanie lub pominięcie tej opcji nie ma znaczenia.Komunikaty o błędach są sortowane według identyfikator obiektu, z wyjątkiem tych wiadomości generowane na podstawie bazy danych tempdb.

    W SQL Server Management Studio, maksymalna liczba komunikatów o błędach zwracanych jest 1000.Za pomocą Management Studio, może być konieczne uruchomienie DBCC CHECKDB wiele razy, aby uzyskać pełną listę błędów, gdy określono ALL_ERRORMSGS.Po określeniu ALL_ERRORMSGS zaleca się uruchomienie polecenia DBCC za pomocą Narzędzia polecenie sqlcmd lub planowania SQL Server Agent zadanie należy uruchomić polecenie i skierować dane wyjściowe do pliku.Każdej z tych metod daje pewność, że uruchomienie polecenia raz zgłasza wszystkie komunikaty o błędach.

  • EXTENDED_LOGICAL_CHECKS
    Jeśli poziom zgodności jest 100 (SQL Server 2008) lub wyższym, sprawdza spójność logiczne indeksowany widok, indeksy XML i indeksy przestrzenne, gdzie obecnej.

    Aby uzyskać więcej informacji zobacz "Wykonuje logiczną spójności sprawdza na indeksy" w "Uwagi" sekcja w dalszej części tego tematu.

  • NO_INFOMSGS
    Pomija wszystkie komunikaty informacyjne.

  • TABLOCK
    Powoduje, że DBCC CHECKDB uzyskać blokady zamiast korzystania z wewnętrznego migawka bazy danych.Obejmuje to krótkoterminowych wyłączności (X) blokada bazy danych.TABLOCK spowoduje, że DBCC CHECKDB szybsze działanie bazy danych przy dużym obciążeniu, ale zmniejsza współbieżność dostępne w bazie danych jest uruchomiona DBCC CHECKDB.Aby uzyskać więcej informacji na temat blokady zobacz Tryby Lock.

    TABLOCK ogranicza kontroli, które są wykonywane; DBCC CHECKCATALOG nie jest uruchamiany z bazy danych i Service Broker nie jest sprawdzana poprawność danych.

  • ESTIMATEONLY
    Wyświetla szacowaną liczbę tempdb obszar, który jest wymagany do uruchamiania DBCC CHECKDB z wszystkich innych określonych opcji.Kontrola rzeczywistej bazy danych nie jest wykonywana.

  • PHYSICAL_ONLY
    Ogranicza sprawdzania integralność fizycznej struktury nagłówki strona i rekord i alokacji spójność bazy danych.Ten test jest umożliwienie małych narzutów kontroli fizycznej spójność bazy danych, ale także może wykrywać podarte stron, błędów suma kontrolna i wspólne awarie sprzętowe, które mogą wpłynąć na dane użytkownika.

    Pełne uruchomienia DBCC CHECKDB może potrwać znacznie dłużej niż jego poprzednie wersje.To zachowanie występuje, ponieważ:

    • Kontrole logiczne są bardziej wyczerpujące.

    • Niektóre z podstawowych struktur mają być sprawdzane są bardziej złożone.

    • Aby uwzględnić nowe funkcje zostały wprowadzone wiele nowych kontroli.

    W związku z tym za pomocą opcji PHYSICAL_ONLY może powodować znacznie krótszy Uruchomczas dla DBCC CHECKDB do dużych baz danych i zaleca się częste stosowanie w systemach produkcyjnych.Nadal zaleca się okresowo wykonać pełne uruchomienia DBCC CHECKDB.Częstotliwość tych uruchamia zależy od czynników specyficznych dla poszczególnych firm i w środowiskach produkcyjnych.

    PHYSICAL_ONLY zawsze oznacza NO_INFOMSGS i nie jest dozwolone przy użyciu dowolnej opcji naprawy.

    Ostrzeżenie

    Określanie przyczyny DBCC CHECKDB pominąć wszystkie PHYSICAL_ONLY sprawdza danych FILESTREAM.

  • DATA_PURITY
    Powoduje, że DBCC CHECKDB do sprawdzania bazy danych dla wartości kolumna , które nie są prawidłowe lub na zewnątrz-o-zakres.Na przykład DBCC CHECKDB wykryje kolumny z wartościami data i czas , które są większe niż lub równa dopuszczalnego zakres datetime typu danych; lub decimal lub typ danych numeric zbliżenie kolumny z wartościami skali lub precision, które nie są prawidłowe.

    Dla baz danych utworzonych w SQL Server 2005 i nowsze, kolumna-sprawdza wartość integralność są domyślnie włączone i nie wymagają opcji DATA_PURITY.Uaktualnienia ze starszych wersji baz danych SQL Server, kolumna-wartość sprawdza, czy nie są włączone domyślnie, dopóki DBCC CHECKDB Z DATA_PURITY został uruchomiony bez błędów w bazie danych.Po tym DBCC CHECKDB sprawdza, czy kolumna-wartość integralność domyślnie.Aby uzyskać więcej informacji dotyczących sposobu CHECKDB może wpływać uaktualnianie bazy danych z wcześniejszych wersji programu SQL Server, zobacz sekcję Spostrzeżenia w dalszej części tego tematu.

    Jeżeli określono PHYSICAL_ONLY kolumna- sprawdzanieintegralność nie są wykonywane.

    Nie można naprawić błędy sprawdzania poprawności raportowane przez tę opcję za pomocą opcji naprawy DBCC.Aby uzyskać informacje dotyczące ręcznego poprawiania tych błędów Zobacz bazy wiedzy Knowledge Base w artykuł 923247: Rozwiązywanie problemów błąd DBCC 2570 w SQL Server 2005.

Uwagi

W starszych wersjach SQL Server, wartości na-tabela i liczba wierszy na indeks i licznik strona może stać się nieprawidłowe.W pewnych okolicznościach co najmniej jeden z tych wartości może być nawet ujemnych.W SQL Server 2005 i później, wartości te są zawsze konserwowany.W związku z tym, baz danych, które są tworzone na SQL Server 2005 i później nigdy nie powinny zawierać niepoprawne zlicza; Jednakże baz danych, które są uaktualniane do SQL Server 2005 i może później.Nie jest uszkodzenie dowolne dane przechowywane w bazie danych.DBCC CHECKDB zostało rozszerzone do wykrywać , gdy jeden z tych liczników staje się ujemna.Po wykryciu liczby ujemne wyjścia DBCC CHECKDB zawiera ostrzeżenia i zalecenie, aby uruchomić dbcc updateusage Aby rozwiązać ten problem.

DBCC CHECKDB nie badać indeksy wyłączone.Aby uzyskać więcej informacji na temat indeksów wyłączone zobacz Wyłączanie indeksów.

Jeśli typ zdefiniowany przez użytkownika jest oznaczone jako bajt zamawiane, musi istnieć tylko jeden Serializacja typ zdefiniowany przez użytkownika.Nie ma spójnego serializacji zamówione bajt typy zdefiniowane przez użytkownika powoduje błąd 2537 uruchomienia DBCC CHECKDB.Aby uzyskać więcej informacji, zobacz Wymagania typ zdefiniowany przez użytkownika.

Ponieważ zasobów bazy danych można modyfikować tylko w tryb jednego użytkownika, CHECKDB DBCC polecenia nie można uruchomić na nim bezpośrednio.Jednak gdy DBCC CHECKDB wykonywana jest baza danych master, CHECKDB drugiego również uruchomić wewnętrznie z Resource bazy danych.Oznacza to, że DBCC CHECKDB można powrócić dodatkowe wyniki.To polecenie zwraca wynik dodatkowe Ustawia opcje nie są zestawlub gdy opcja PHYSICAL_ONLY lub ESTIMATEONLY nie jest zestaw.

W wersjach SQL Server 2005 przed dodatkiem SP2, wykonywanie DBCC CHECKDB Czyści pamięć podręczną plan dla wystąpienie SQL Server.Czyszczenie pamięci podręcznej plan powoduje ponowną kompilację wszystkich planów wykonanie nowszych i może spowodować nagłe, tymczasowe spadek wydajności kwerendy.W dodatku SP2 i nowszych wykonywanie DBCC CHECKDB nie Wyczyść pamięć podręczną planu.

Wykonuje logiczną spójność kontrole indeksów

Sprawdzanie na indeksy logiczne spójności zależy zgodnie z poziom zgodności bazy danych:

  • Jeśli poziom zgodności jest 100 (SQL Server 2008) lub wyższej:

    • Jeśli nie określono NOINDEX DBCC CHECKDB sprawdza zarówno spójność fizycznych i logicznych na pojedynczej tabela i wszystkich jego zbudowania indeksów nie klastrowanych.Jednak indeksy XML, indeksy przestrzenne i spójność fizycznych tylko widoki indeksowane są sprawdzane domyślnie.

    • Jeżeli określono Z EXTENDED_LOGICAL_CHECKS logiczne są sprawdzane na indeksowany widok, indeksy XML i indeksy przestrzenne, gdzie przedstawia.Domyślnie spójność fizycznych są sprawdzane przed sprawdzania spójności logicznych.Jeśli określony jest również NOINDEX, wykonywane są tylko kontrole logiczne.

      Te logiczną spójność między domenami wyboru indeks wewnętrzny tabela indeks obiektu użytkownika tabela , która odwołuje się do.Aby znaleźć wiersze skrajne, wewnętrznego kwerendy jest skonstruowane, aby wykonać pełny przecięcia wewnętrznego i tabele użytkowników.Uruchomienie tej kwerendy mogą mieć bardzo duży wpływ na wydajność i nie można śledzić postęp.Dlatego zaleca się, aby określić Z EXTENDED_LOGICAL_CHECKS tylko wtedy, gdy podejrzewasz, że problemy indeksu, które są niezwiązane fizyczne uszkodzenie lub jeśli strona- sum kontrolnychpoziom zostały wyłączone i podejrzewasz, że kolumna-poziom uszkodzenie sprzętu.

    • Jeżeli indeks jest indeksem przefiltrowane, DBCC CHECKDB sprawdza spójność zweryfikować, że pozycje indeksu spełniają predykat filtru.

  • Jeśli poziom zgodności jest 90 lub mniej, chyba że określono NOINDEX DBCC CHECKDB wykonuje sprawdzania spójności fizycznej i logicznej na pojedynczej tabela lub indeksowany widok i wszystkie jego nieklastrowany i indeksy XML.Przestrzennej indeksy nie są obsługiwane.

Aby dowiedzieć się, poziom zgodności bazy danych

Migawki wewnętrznej bazy danych

DBCC CHECKDB używa wewnętrznego migawka bazy danych spójności transakcyjnej potrzebnymi do wykonywania tych kontroli.Pozwala to uniknąć problemów z blokowaniem i współbieżność te polecenia są wykonywane.Aby uzyskać więcej informacji, zobacz Opis Sparse rozmiary plików w bazie danych migawek i sekcji DBCC wewnętrznego użycia migawkę bazy danych w DBCC (Transact-SQL).Jeśli nie można utworzyć migawka lub określonym TABLOCK, DBCC CHECKDB nabywa blokady, aby uzyskać wymaganą konsystencję.W tym przypadekwyłącznych bazy danych blokada jest wymagane do przeprowadzenia kontroli alokacji i zamki udostępnionego tabela są wymagane do przeprowadzenia kontroli tabela .

DBCC CHECKDB nie powiedzie się, gdy wykonywane są master wewnętrzny migawka bazy danych nie można utworzyć.

Uruchamianie DBCC CHECKDB przeciwko tempdb nie przeprowadza wszelkie kontrole, przydziału lub wykazu i muszą nabyć zamki udostępnionego tabela do wykonywania kontroli tabela .To, ponieważ ze względu na wydajność bazy danych migawek nie są dostępne na tempdb.Oznacza to, nie można uzyskać wymaganej spójności transakcyjnej.

Sprawdzanie i naprawianie FILESTREAM danych

Po włączeniu FILESTREAM dla bazy danych i tabelamożna opcjonalnie przechowywać varbinary(max) dużych obiektów binarnych (bloków BLOB) w systemie plików.Używając DBCC CHECKDB w bazie danych, który przechowuje bloków BLOB w systemie plików, DBCC sprawdza łącze -poziom spójności systemu plików i bazy danych.

Na przykład, jeśli tabela zawiera varbinary(max) kolumna używające FILESTREAM atrybutDBCC CHECKDB sprawdzi się mapowanie jeden do jednego między katalogów systemu plików oraz pliki i tabela wiersze, kolumny i wartości kolumna .DBCC CHECKDB można naprawić uszkodzenie, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS.Aby naprawić uszkodzenie FILESTREAM, DBCC spowoduje usunięcie wszystkich wierszy tabela , których brakuje danych systemu plików.

Najważniejsze wskazówki

Firma Microsoft zaleca użycie opcji PHYSICAL_ONLY często używane w systemach produkcji.Przy użyciu PHYSICAL_ONLY może znacznie skrócić Uruchomczas dla DBCC CHECKDB do dużych baz danych.Ponadto zaleca się okresowe uruchamianie DBCC CHECKDB bez żadnych opcji.Jak często należy wykonać te uruchamia zależy od poszczególnych firm i w środowiskach ich produkcji.

Sprawdzanie obiektów równolegle

Domyślnie DBCC CHECKDB wykonuje równoległe sprawdzanie obiektów.Stopień równoległości prostych jest automatycznie określany przez procesor kwerend.Maksymalny stopień równoległości prostych jest skonfigurowane tak samo jak równoległych kwerend.Aby ograniczyć maksymalną liczbę procesorów dostępnych dla sprawdzenia DBCC, użyj sp_configure.Aby uzyskać więcej informacji, zobacz maksymalny stopień równoległości prostych opcji.Równoległe sprawdzanie można wyłączyć za pomocą flagi śledzenia 2528.Aby uzyskać więcej informacji, zobacz Flagi śledzenia (Transact-SQL).

Opis komunikatów o błędach DBCC

Po zakończeniu działania polecenia DBCC CHECKDB jest zapisywany komunikat SQL Server dziennik błędów.Jeśli polecenie DBCC pomyślnie wykona wiadomości wskazuje sukces i ilość czas , który uruchomił polecenie.Polecenie DBCC zatrzymuje się przed zakończeniem kontroli z powodu błędu, komunikat wskazuje, że polecenie zostało zakończone, wartość stanu i czas , który uruchomił polecenie.W poniższej tabela wymieniono i opisano wartości stanu, które mogą być dołączone do wiadomości.

Stan

Opis

0

Błąd numer 8 930 był uruchamiany.Oznacza to uszkodzenie metadane zakończone polecenie DBCC.

1

Błąd numer 8967 był uruchamiany.Wystąpił błąd wewnętrzny DBCC.

2

Wystąpił błąd podczas naprawy bazy danych trybu awaryjnego.

3

Oznacza to uszkodzenie metadane zakończone polecenie DBCC.

4

Wykryto assert lub naruszenie zasad dostępu.

5

Wystąpił nieznany błąd, który polecenie DBCC zakończone.

Raportowanie błędów

Plik automatyczna kopia zapasowa (SQLDUMPnnnn.txt) jest tworzony w SQL Server katalog dziennika, ilekroć DBCC CHECKDB wykryje błąd uszkodzenia.Jeżeli dane użycia funkcji kolekcja i funkcje raportowania błędów są włączone dla wystąpienie SQL Server, plik jest automatycznie przesyłane dalej Microsoft.Zebrane dane są używane do poprawy SQL Server funkcji.

Plik automatyczna kopia zapasowa zawiera wyniki polecenia DBCC CHECKDB i dodatkowej produkcji diagnostycznych.Dostęp jest ograniczony do SQL Serverkontousługa i członków sysadmin rolę.Domyślnie sysadmin roli zawiera wszystkich członków grupy systemu Windows BUILTIN\Administratorzy oraz grupa administratora lokalnego.Polecenie DBCC się nie powieść, jeśli proces kolekcja danych nie powiedzie się.

Rozwiązywanie błędów

Wszelkie błędy są zgłaszane przez DBCC CHECKDB, zaleca się przywrócenie bazy danych z bazy danych kopia zapasowa zamiast uruchomić narzędzie do naprawy jedną z opcji naprawy.Jeśli istnieje nie kopia zapasowa uruchomić narzędzie do naprawy poprawia błędy raportowane.Określono opcję Napraw, aby użyć na końcu listy błędów.Poprawianie błędów za pomocą opcji REPAIR_ALLOW_DATA_LOSS mogą jednak wymagać usunięcia niektórych stron i w związku z tym niektóre dane.

W niektórych okolicznościach wartości mogą zostać wprowadzone do bazy danych, które są nieprawidłowe lub na zewnątrz-o-zakres oparty na typ danych kolumna.W SQL Server 2000, DBCC CHECKDB nie wykonuje zakres lub integralność kontroli tych wartości kolumna .Jednakże w SQL Server 2005 , a później DBCC CHECKDB mogą wykrywaćwartościkolumna są nieprawidłowe dla wszystkich typów danych kolumna . Dlatego uruchomiono DBCC CHECKDB z opcją DATA_PURITY baz danych, które zostały uaktualnione z wcześniejszych wersji programu SQL Server może pokazać istniejące wcześniej kolumna— wartości błędów.Ponieważ SQL Server nie może automatycznie naprawić błędy te wartości kolumna muszą być aktualizowane ręcznie.Jeśli CHECKDB wykryje taki błąd, ostrzeżenie, numer błędu 2570 i informacji do identyfikowania odpowiednim wierszu i ręcznego poprawiania błędu zwraca wartość CHECKDB.

Naprawy można wykonać w transakcji użytkownika, aby poinformować użytkownika wycofać wprowadzonych zmian.Jeśli są przywracane naprawy, bazy danych będzie nadal zawierać błędy i musi zostać przywrócony z kopia zapasowa.Po zakończeniu naprawy tworzyć kopię zapasową bazy danych.

Rozwiązywanie błędów w bazie danych trybu awaryjnego

Kiedy bazy danych została zestaw do trybu awaryjnego za pomocą ALTER DATABASE instrukcjaDBCC CHECKDB można wykonać niektóre specjalne naprawy do bazy danych, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS.Napraw tych mogą zezwalać na zwykle nieodwracalny baz danych można przełączyć z powrotem do trybu online fizycznie spójna.Napraw tych należy używać w ostateczności, i tylko wtedy, gdy nie można przywracanie bazę danych z kopia zapasowa.Gdy baza danych jest zestaw do trybu awaryjnego, baza danych jest oznaczony jako TYLKO_DO_ODCZYTU, rejestrowanie jest wyłączone i dostęp jest ograniczony do członków sysadmin stała rola serwera.

Ostrzeżenie

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

Gdy baza danych jest w trybie awaryjne i uruchomić DBCC CHECKDB z REPAIR_ALLOW_DATA_LOSS klauzula , podejmowane są następujące akcje:

  • DBCC CHECKDB używa stron, które zostały oznaczone niedostępne z powodu błędów We/Wy lub suma kontrolna , jak gdyby nie wystąpiły błędy.W ten sposób zwiększa szanse odzyskiwanie danych z bazy danych.

  • DBCC CHECKDB próby odzyskać bazy danych przy użyciu technik regularnych dziennik odzyskiwanie .

  • Jeśli z powodu uszkodzenia dziennika transakcji nie powiedzie się odzyskiwanie bazy danych, jest odbudowywany w dzienniku transakcji.Odbudowywanie dziennika transakcji może spowodować utratę spójności transakcyjnej.

Jeśli polecenie DBCC CHECKDB powiedzie się, baza danych jest fizycznie spójna i stan bazy danych jest zestaw na ONLINE.Jednak baza danych może zawierać jedną lub więcej niespójności transakcyjnych.Firma Microsoft zaleca uruchomieniedbcc checkconstraints do identyfikowania wszelkich wad logika biznesowa i natychmiast tworzyć kopię zapasową bazy danych.

Jeśli polecenie DBCC CHECKDB nie powiedzie się, baza danych nie może być naprawiona.

Uruchamianie DBCC CHECKDB z REPAIR_ALLOW_DATA_LOSS w replikowanych bazach danych

Uruchomienie polecenia DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS może wpłynąć na baz danych użytkowników (publikacja i subskrypcja bazy danych) a bazą baza danych dystrybucji używana przez replikacja.Publikacja i subskrypcja baz danych obejmują opublikowanych tabelami i tabelamimetadane replikacja. Należy pamiętać o następujących potencjalnych problemów w tych baz danych:

  • Opublikowanych tabel.Akcje wykonywane przez proces CHECKDB, aby naprawić uszkodzony użytkownika danych może nie zostać zreplikowane:

    • Scalania replikacja wyzwalaczy używa do śledzenia zmian do opublikowanych tabel.Jeśli wiersze są wstawiane, aktualizowane lub usuwane przez proces CHECKDB, nie uruchamiaj wyzwalaczy; w związku z tym zmiana nie jest replikowana.

    • Transakcyjne replikacja używa dziennika transakcji do śledzenia zmian do opublikowanych tabel.Agent odczytywania dziennika przenosi te zmiany do baza danych dystrybucji.Niektóre naprawy DBCC, chociaż zarejestrowane, nie mogą być replikowane przez Agent odczytywania dziennika.Na przykład jeśli dane strona dealokowaniu przez proces CHECKDB, Agent odczytywania dziennika nie dadzą to DELETE instrukcja; w związku z tym zmiana nie jest replikowana.

  • Tabele metadane replikacji.Akcje wykonywane przez proces CHECKDB, aby naprawić uszkodzony replikacja metadane tabele wymagają usunięcie i ponowne konfigurowanie replikacja.

Jeśli trzeba uruchomić polecenie DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS na baza danych użytkownika :

  1. Quiesce system: Zatrzymaj działanie bazy danych i na wszystkich innych baz danych w topologii replikacja , a następnie spróbuj zsynchronizować wszystkie węzły.Aby uzyskać więcej informacji, zobacz Jak Quiesce topologii replikacji (Programowanie replikacji Transact-SQL).

  2. Wykonanie DBCC CHECKDB.

  3. Jeśli raport DBCC CHECKDB obejmuje napraw wszystkie tabele w baza danych dystrybucji lub wszystkie tabelemetadane replikacjaw baza danych użytkownika, usuń i ponownie skonfigurować replikacja. Aby uzyskać więcej informacji, zobacz Usuwanie replikacji.

  4. Jeśli raport DBCC CHECKDB zawiera naprawy zreplikowanych tabelach, należy wykonać sprawdzanie poprawności danych, aby ustalić, czy istnieją różnice między danymi w bazach danych publikacja i subskrypcja .Aby uzyskać więcej informacji, zobacz Dane na Wydawca i subskrybenta nie pasują..

Zestawy wyników

DBCC CHECKDB zwraca następujące zestaw wyników.Wartości mogą być różne, z wyjątkiem przypadków, gdy określone 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ące zestaw wyników (komunikat) po NO_INFOMSGS:

The command(s) completed successfully.

DBCC CHECKDB zwraca następujące 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ące zestaw wyników po 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ła rola serwera lub db_owner rola bazy danychstałej.

Przykłady

A.Sprawdzanie zarówno bieżące i innej bazy danych

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

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

B.Sprawdzanie bieżącej bazy danych pomijanie komunikatów informacyjnych

W poniższym przykładzie sprawdza, czy bieżąca baza danych i pomija wszystkie komunikaty informacyjne.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Historia zmian

Zaktualizowaną zawartość

W sekcji "Sprawdzanie i naprawianie FILESTREAM danych", zawartość została usunięta wskazane, że FILESTREAM katalogów lub plików, które nie są mapowane na wartość wiersza, kolumnalub kolumna tabela są usuwane.