Udostępnij za pośrednictwem

  • Artykuł

DBCC CHECKDB (języka Transact-SQL)

Sprawdza spójność logiczną i fizyczną 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 w widoku w bazie danych.

  • Uruchamia DBCC CHECKCATALOG w bazie danych.

  • Sprawdza poprawność zawartości każdy widok indeksowany w bazie danych.

  • Sprawdza spójność poziom łącza między tabela metadane i plików systemowych katalogów i plików przy zapisywaniu varbinary(max) dane w systemie plików przy użyciu FILESTREAM.

  • Sprawdza poprawność Service Broker w bazie danych.

Oznacza to, że polecenia DBCC CHECKALLOC, CHECKTABLE DBCC lub CHECKCATALOG DBCC nie mają być uruchamiana oddzielnie z CHECKDB DBCC.Aby uzyskać więcej informacji na temat kontroli, służące do wykonywania tych poleceń zobacz opisy poleceń.

Topic link iconKonwencje składni języka Transact-SQL

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
    Jest to nazwa lub identyfikator bazy danych, dla którego ma być uruchomienia sprawdzania integralność.Jeśli nie zostanie określony, lub jeżeli określono wartość 0, bieżąca baza danych jest używana.Nazwy bazy danych muszą być zgodne z zasadami identyfikatory.

  • NOINDEX
    Określa, że intensywne kontroli ponownego zbudowania indeksów nie klastrowanych tabel użytkownika nie należy wykonać.Zmniejsza to całkowity czas realizacji.NOINDEX nie wpływa na tabelach systemowych, ponieważ integralność są zawsze sprawdzane na indeksy tabela systemu.

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    Określa, że CHECKDB DBCC naprawy znalezionych błędów.The specified databasemust be in single-user mode to use one of the following repair options.

    • REPAIR_ALLOW_DATA_LOSS
      Próbuje naprawić wszelkie zgłoszone błędy.Te naprawy może spowodować utratę danych.

    • REPAIR_FAST
      Przechowuje składni zgodność z poprzednimi wersjami.Żadne naprawy akcje są wykonywane.

    • REPAIR_REBUILD
      Wykonuje naprawy o możliwości utraty danych.Może to dotyczyć szybkiej naprawy, takich jak naprawianie brakuje wierszy indeksami nieklastrowanymi i więcej naprawy czasochłonne, takie jak przebudowywanie indeksu.

      REPAIR_REBUILD nie naprawić błędy FILESTREAM danych.

    Important noteImportant Note:

    Za pomocą opcji naprawy tylko w ostateczności.Aby naprawić błędy, zaleca się przywrócenie z kopia zapasowa.Operacje naprawy nie rozważyć żadnego ograniczenia, może istnieć na lub między tabelami.Jeśli określona tabela uczestniczy w jednej lub więcej ograniczeń, zaleca się systemem CHECKCONSTRAINTS DBCC po operacji naprawy.Jeśli musisz użyć REPAIR, CHECKDB DBCC powinny być uruchamiane bez opcji naprawy, aby znaleźć używany poziom naprawy.Jeżeli korzystasz z poziom REPAIR_ALLOW_DATA_LOSS, zaleca się wykonanie tworzyć kopię zapasową zapasowej bazy danych przed uruchomieniem CHECKDB DBCC przy użyciu tej opcji.

  • ALL_ERRORMSGS
    Wyświetla wszystkie błędy raportowane na obiekt.W SQL Server 2008 Dodatek usługa Pack 1 (SP1), wszystkie komunikaty o błędach są domyślnie wyświetlane. Określanie lub pomijanie tej opcji nie powoduje żadnych zmian.We wcześniejszych wersjach SQL Server (z wyjątkiem SQL Server 2005 Dodatek SP3), jeżeli nie określono ALL_ERRORMSGS wyświetlane są tylko pierwszy błąd 200 wiadomości dla każdego obiektu. 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 wynosi 1000. Za pomocą Management Studio, konieczne może być uruchamiać wiele razy, aby uzyskać pełną listę błędów, gdy określono ALL_ERRORMSGS CHECKDB DBCC. Po określeniu ALL_ERRORMSGS zaleca się uruchomienie polecenia DBCC przy użyciu Narzędzie SQLCMD lub planowaniaSQL Server zadanie agenta, uruchom polecenie i skierować dane wyjściowe do pliku. Każda z tych metod daje pewność, że uruchomienie polecenia raz zgłosi wszystkie komunikaty o błędach.

  • EXTENDED_LOGICAL_CHECKS
    Jeśli poziom zgodności jest 100)SQL Server 2008) lub wyższym, sprawdza spójność logicznych na widok indeksowany, indeksy XML i przestrzennej indeksów, w przypadku, gdy obecna.

    Aby uzyskać więcej informacji zobacz "Wykonywanie logicznych spójności testy na indeksy," w sekcji "Uwagi" w dalszej części tego tematu.

  • NO_INFOMSGS
    Pomija wszystkie komunikaty informacyjne.

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

    TABLOCK ogranicza kontroli, które są wykonywane; CHECKCATALOG DBCC nie jest uruchomione w bazie danych, a Service Broker nie sprawdzają poprawność danych.

  • ESTIMATEONLY
    Wyświetla szacowaną ilość tempdb Miejsce wymagane do uruchomienia CHECKDB DBCC z wszystkie inne określone opcje. Sprawdzanie rzeczywistej bazy danych nie jest wykonywane.

  • PHYSICAL_ONLY
    Ogranicza sprawdzania integralność struktury fizycznej nagłówków strona i rekordu, fizycznej struktury drzewa B i spójność alokacji bazy danych.Ten test ma na celu zapewnienie małych wyboru narzutów fizycznej spójności bazy danych, ale może również wykrywać podarte stron, błędów suma kontrolna oraz typowych błędów sprzętowych, które mogą wpłynąć na dane użytkownika.

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

    • Kontrole logiczne są szersze.

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

    • Aby uwzględnić nowe funkcje zostały wprowadzone szereg testów nowe.

    W związku z tym, za pomocą opcji PHYSICAL_ONLY może spowodować, że znacznie krótsze wykonywania-czas dla CHECKDB DBCC na dużych baz danych i zaleca się częste stosowanie w systemach produkcyjnych.Zaleca się wciąż pełnego uruchomienia programu DBCC CHECKDB wykonywane co pewien czas.Częstotliwość tych uruchamia zależy od czynników, które są specyficzne dla poszczególnych firm i w środowisku produkcyjnym.

    PHYSICAL_ONLY zawsze pociąga za sobą NO_INFOMSGS i nie jest dozwolone z jednej z opcji naprawy.

    Uwaga

    Określanie PHYSICAL_ONLY powoduje, że CHECKDB DBCC pominąć wszystkie sprawdza FILESTREAM danych.

  • DATA_PURITY
    Powoduje, że CHECKDB DBCC sprawdzić, czy bazy danych dla wartości kolumna, które nie są prawidłowe lub poza zakres.Na przykład CHECKDB DBCC wykryje kolumny z wartościami data i godziny, które są większe niż lub mniejsze niż dopuszczalny zakres dla datetime Typ danych; lub decimal lub typ danych numerycznych zbliżenie kolumny z wartościami skalę lub dokładności, które nie są prawidłowe.

    Dla baz danych utworzonych w SQL Server 2005 a później, kontrole integralność wartości kolumna są domyślnie włączone i nie wymagają opcji DATA_PURITY. W przypadku uaktualnienia ze starszych wersji baz danych SQL Server, sprawdza wartość kolumna nie są włączone domyślnie, dopóki DBCC CHECKDB WITH DATA_PURITY uruchomieniu błąd wolnego w bazie danych. Potem CHECKDB DBCC sprawdza integralność wartość kolumna domyślnie.Aby uzyskać więcej informacji na temat sposobu mogą mieć wpływ CHECKDB uaktualnianiu 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, nie są wykonywane kontrole integralność kolumna.

    Nie można naprawić błędy sprawdzania poprawności raportowane przez tę opcję za pomocą opcji naprawy DBCC.Aby uzyskać informacje na temat ręcznego korygowania tych błędów zobacz artykuł bazy wiedza Microsoft wiedza Base 923247: Rozwiązywanie problemów błąd DBCC 2570 w programie SQL Server 2005.

Remarks

We wcześniejszych wersjach SQL Server, wartości dla 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 mogą nawet być ujemna.W SQL Server 2005 a później, wartości te zawsze są obsługiwane poprawnie. Dlatego też bazy danych, które są tworzone na SQL Server 2005 i później nigdy nie powinna zawierać niepoprawne liczniki; jednak baz danych, które są uaktualniane do SQL Server 2005 a później. Nie jest uszkodzenie danych przechowywanych w bazie danych.DBCC CHECKDB został rozszerzony, aby wykryć, kiedy jeden z tych liczb staje się ujemna.Gdy ujemne liczby zostaną wykryte, dane wyjściowe CHECKDB DBCC zawiera ostrzeżenia i zalecenia, aby uruchomić DBCC UPDATEUSAGE , aby rozwiązać ten problem.

CHECKDB DBCC nie sprawdzić indeksy wyłączone.Aby uzyskać więcej informacji na temat indeksów niepełnosprawnych zobacz Disabling Indexes.

Jeśli typ zdefiniowany przez użytkownika jest zaznaczone, zgodnie z zamówieniem jest bajt, musi istnieć tylko serializacji jednego typu zdefiniowanego przez użytkownika.Nie ma spójnego serializacji zamówione bajt typów zdefiniowanych przez użytkownika powoduje, że błąd 2537 uruchomienia CHECKDB DBCC.Aby uzyskać więcej informacji zobaczWymagania dotyczące typ zdefiniowany przez użytkownika.

Ponieważ Baza danych zasób można modyfikować tylko tryb jednego użytkownika, polecenie DBCC CHECKDB nie można uruchomić na nim bezpośrednio.Jednak po wykonaniu CHECKDB DBCC przed wzorzec bazy danych, drugi CHECKDB jest również uruchomić wewnętrznie na Resource Baza danych. Oznacza to, że CHECKDB DBCC może zwracać wyniki dodatkowych.Polecenie zwraca zestaw wyników dodatkowe opcje nie są ustawione tak, lub jeśli ustawiono opcję PHYSICAL_ONLY albo ESTIMATEONLY.

W wersjach SQL Server 2005 przed dodatkiem SP2 wykonywanie CHECKDB DBCC Czyści bufor 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 CHECKDB DBCC nie czyści pamięć podręczną planu.

Wykonywanie logicznych spójności testy na indeksy

Sprawdzanie na indeksy spójności logiczne zmienia się zgodnie z poziomem zgodności bazy danych, w następujący sposób:

  • Jeśli poziom zgodności jest 100)SQL Server 2008) lub nowszej:

    • Pod warunkiem, że nie określono NOINDEX, CHECKDB DBCC wykonuje zarówno fizyczne i logiczne spójności sprawdza, czy w jednej tabela i wszystkich jego ponownego zbudowania indeksów nie klastrowanych.Jednak indeksy XML, przestrzennej indeksy i spójność fizycznych tylko widoki indeksowane są sprawdzane domyślnie.

    • Jeżeli określono EXTENDED_LOGICAL_CHECKS WITH, logiczne są sprawdzane na widok indeksowany, indeksy XML i przestrzennej indeksów, których obecnie.Domyślnie spójność fizyczne są sprawdzane przed sprawdzania spójności logiczne.Jeśli określony jest również NOINDEX, wykonywane są tylko testy logiczne.

      Te logiczne spójności sprawdza między domenami wyboru tabela indeks wewnętrznego obiektu indeksu z tabela użytkownika, która odwołuje się do.Aby znaleźć wiersze skrajne, kwerendę wewnętrznej jest skonstruowany do wykonywania pełnej przecięcia wewnętrznego i tabele użytkowników.Tę kwerendę mogą mieć bardzo duże wpływ na wydajność i nie można śledzić jego postęp.Dlatego zaleca się, aby określić WITH EXTENDED_LOGICAL_CHECKS tylko wtedy, gdy użytkownik podejrzewa, że indeks problemy, które są wpływu na to fizyczne uszkodzenie lub jeśli zostały wyłączone poziom strona sum kontrolnych, a użytkownik podejrzewa, że uszkodzenie sprzętu poziom kolumna.

    • Jeżeli indeks jest filtrowany indeksu, CHECKDB DBCC wykonuje sprawdzania spójności, aby zweryfikować, że pozycje indeksu spełniają predykat filtru.

  • Jeśli poziom zgodności wynosi 90 lub mniej, pod warunkiem, że nie określono NOINDEX, CHECKDB DBCC sprawdza zarówno fizyczne i logiczne spójności w pojedynczej tabela lub widok indeksowany i wszystkich jego nieklastrowany i indeksów XML.Przestrzennej indeksy nie są obsługiwane.

Aby dowiedzieć się poziom zgodności bazy danych

Wewnętrzny migawka bazy danych

DBCC CHECKDB używa wewnętrznego migawka bazy danych spójności transakcyjnej, wymagane 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 odstępem rozmiary plików w migawek bazy danych i w sekcji DBCC wewnętrzny migawka bazy danych obciążenie DBCC (języka Transact-SQL). Jeśli nie można utworzyć migawkę lub TABLOCK jest określony, CHECKDB DBCC nabywa blokady w celu uzyskania wymaganej spójności.W takim przypadek blokada wyłączności bazy danych jest wymagana do sprawdzania alokacji i udostępnionego tabela blokady są wymagane do sprawdzania tabela.

DBCC CHECKDB kończy się niepowodzeniem, jeśli wykonywane są master Jeśli nie można utworzyć migawka wewnętrznej bazy danych.

DBCC CHECKDB przed uruchomieniem tempdb nie wykonuje żadnych kontroli alokacji lub w katalogu i musi uzyskać blokady tabela udostępnionego do sprawdzania tabela. Jest to, ponieważ ze względu na wydajność, nie są dostępne na bazę danych migawek tempdb. Oznacza to, że nie można uzyskać wymaganej spójności transakcyjnej.

Sprawdzanie i naprawianie FILESTREAM danych

Po włączeniu FILESTREAM dla bazy danych i tabela można opcjonalnie przechowywać varbinary(max) binarne dużych obiektów (bloków BLOB) w systemie plików. Używając CHECKDB DBCC na bazie danych, które są przechowywane bloków BLOB w systemie plików, DBCC sprawdza spójność poziom łącze między systemem plików a bazą danych.

Na przykład, jeśli tabela zawiera varbinary(max) kolumna, która korzysta z atrybut FILESTREAM, CHECKDB DBCC sprawdzi jest mapowanie typu jeden-do-jednego między katalogów systemu plików i plików i wierszy, kolumn i wartości kolumna. DBCC CHECKDB można naprawić uszkodzenie, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS.Aby naprawić uszkodzenie FILESTREAM, DBCC usunie wszystkie wiersze tabela, które nie zawierają danych systemu plików i spowoduje usunięcie wszystkich katalogów i plików, które nie mapowane na wartość wiersza, kolumna lub kolumn tabela.

Najważniejsze wskazówki

Firma Microsoft zaleca użycie opcji PHYSICAL_ONLY często używane w systemach produkcyjnych.Za pomocą PHYSICAL_ONLY może znacznie skrócić czas wykonania dla CHECKDB DBCC na dużych baz danych.Zaleca się również co pewien czas uruchamiane CHECKDB DBCC z opcji.Jak często należy wykonać te uruchamia zależy od poszczególnych firm i w ich środowisku produkcyjnym.

Sprawdzanie obiekty w równoległy

Domyślnie CHECKDB DBCC wykonuje sprawdzanie równoległych obiektów.Stopień proste jest automatycznie określana przez procesor kwerend.Maksymalny stopień proste jest skonfigurowane tak samo, jak równoległych kwerendy.Aby ograniczyć maksymalną liczbę procesorów dostępnych sprawdzania DBCC, należy użyć sp_configure.Aby uzyskać więcej informacji zobaczmax degree of parallelism Option.Sprawdzanie równoległych można wyłączyć za pomocą flagi śledzenia 2528.Aby uzyskać więcej informacji zobaczFlagi ś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 wykonuje, wiadomości oznacza sukces i czas, który uruchomił polecenie.Polecenie DBCC zatrzymuje się przed zakończeniem sprawdzania z powodu błędu, komunikat wskazuje, że polecenie zostało zakończone, wartość stan i czas uruchomienia polecenia.W poniższej tabela wymieniono i opisano wartości stanu, które mogą być dołączone do wiadomości.

Stan

Description

0

Numer błędu 8930 był uruchamiany.Oznacza to uszkodzenie metadane, które polecenie DBCC zakończone.

1

Numer błędu 8967 był uruchamiany.Wystąpił błąd wewnętrzny DBCC.

2

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

3

Oznacza to uszkodzenie metadane, które polecenie DBCC zakończone.

4

Wykryto naruszenie zasad dostępu lub zapewnienia.

5

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

Raportowanie błędów

Plik automatyczna kopia zapasowa (SQLDUMPNNNNtworzenia w .txt)SQL Server DZIENNIK katalogu za każdym razem, gdy CHECKDB DBCC wykryje błąd uszkodzenia. Gdy dane użycia funkcji kolekcja i raportowanie błędów funkcji są włączone dla wystąpienie SQL Server, plik jest automatycznie przesyłane dalej do Microsoft. Zebrane dane są używane do poprawienia SQL Server funkcje.

Plik automatyczna kopia zapasowa zawiera wyniki polecenia DBCC CHECKDB i dodatkowe dane wyjściowe diagnostycznych.Dostęp jest ograniczony do SQL Server usługa kont i członkowie sysadmin Rola. Domyślnie sysadmin Rola zawiera wszystkich członków grupy BUILTIN\Administratorzy systemu Windows oraz do lokalnej grupy Administratorzy. Polecenie DBCC nie się niepowodzeniem, gdy proces zbierania danych nie powiodło się.

Rozwiązywanie błędów

Jeśli wszystkie błędy są zgłaszane przez CHECKDB DBCC, zaleca się przywrócenie bazy danych z kopia zapasowa bazy danych zamiast z REPAIR z jedną z opcji naprawy.Jeśli brakuje kopia zapasowa, uruchomienie naprawy koryguje błędy, raportowane.Za pomocą opcji naprawy jest określona na końcu listy zgłoszone błędy.Poprawianie błędów przy użyciu 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 nie są prawidłowe lub limit czasu z zakres na podstawie typu danych kolumna.W SQL Server 2000CHECKDB DBCC nie jest sprawdzana zakres lub integralność kontrole te wartości kolumna. Jednak w SQL Server 2005 a później CHECKDB DBCC może wykryć wartości kolumna, które nie są prawidłowe dla wszystkich typów danych kolumn. Dlatego systemem CHECKDB DBCC z opcją DATA_PURITY baz danych, które zostały uaktualnione z wcześniejszych wersji programu SQL Server może ujawnić gotowe błędy wartość kolumna. Ponieważ SQL Server nie może automatycznie naprawić te błędy, należy ręcznie zaktualizować wartość kolumna. Jeśli CHECKDB wykrywa taki błąd, CHECKDB zwraca komunikat ostrzegawczy, numer błędu 2570 i informacji do identyfikacji odpowiednim wierszu i ręcznie poprawić błąd.

Napraw można wykonać w transakcji użytkownika, aby umożliwić użytkownikowi wycofać zmiany, które zostały wprowadzone.Jeśli są przywracane naprawy, baza 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 tryb awaryjny bazy danych

Gdy baza danych została zestaw do trybu awaryjnego za pomocą ZMIENIANIE BAZY DANYCH Instrukcja CHECKDB DBCC można wykonywać pewne specjalne naprawy do bazy danych, jeśli określono opcję REPAIR_ALLOW_DATA_LOSS. Napraw te mogą zezwalać na zwykle nieodwracalny baz danych, można przełączyć z powrotem do trybu online fizycznie spójna.W ostateczności, i tylko wtedy, gdy nie można przywrócić z kopia zapasowa bazy danych, należy wykorzystać te naprawy.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.

Uwaga

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

Gdy baza danych znajduje się w tryb awaryjny i CHECKDB DBCC z klauzula REPAIR_ALLOW_DATA_LOSS jest uruchamiany, podejmowane są następujące czynności:

  • DBCC CHECKDB używa stron, które zostały oznaczone niedostępny z powodu We/Wy lub suma kontrolna błędów, tak jakby nie wystąpiły błędy.W ten sposób zwiększa to szansę na przeprowadzenie przy odzyskiwaniu danych z bazy danych.

  • DBCC CHECKDB podejmie próbę odzyskać bazy danych, przy użyciu technik odzyskać opartego na dzienniku regularnych.

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

Jeśli polecenie DBCC CHECKDB powiedzie się, baza danych jest w stanie spójnym fizycznie i stan bazy danych jest ustawiony na ONLINE.Jednak w bazie danych może zawierać jedną lub więcej niespójności transakcyjnych.Zaleca się uruchomienieDBCC CHECKCONSTRAINTS do identyfikowania wszelkich wady logika biznesowa i natychmiast wykonaj kopię zapasową bazy danych.

Jeśli polecenie DBCC CHECKDB nie powiedzie się, nie można naprawić bazę danych.

Z CHECKDB DBCC z REPAIR_ALLOW_DATA_LOSS w replikowane bazy danych

Uruchamianie CHECKDB DBCC polecenie z opcją REPAIR_ALLOW_DATA_LOSS może mieć wpływ na użytkowników bazy danych (publikacja i subskrypcja bazy danych) i baza danych dystrybucji używany przez replikację.publikacja i subskrypcja baz danych zawiera opublikowaną tabelami i tabelami metadane replikacja.Należy pamiętać o następujących potencjalnych problemów w tych baz danych:

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

    • replikacja łączenia używa wyzwalaczy do śledzenia zmian do opublikowanych tabel.Jeśli wiersze są wstawiane, aktualizowane lub usuwane w procesie CHECKDB, wyzwalacze nie ognia; z tego powodu, zmiany nie są replikowane.

    • Replikacja transakcyjnych używa dziennik transakcji do śledzenia zmian do opublikowanych tabel.Agent odczytywania dziennika program przenosi te zmiany do baza danych dystrybucji.Niektóre naprawy DBCC, chociaż zarejestrowane, nie można zreplikować przez Agent odczytywania dziennika.Na przykład jeśli strona danych jest dealokowane w procesie CHECKDB, Agent odczytywania dziennika nie wykonuje tłumaczenia to Instrukcja DELETE; dlatego zmiany nie są replikowane.

  • Tabele metadane replikacja.Akcje wykonywane przez proces CHECKDB 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 baza danych użytkownika lub baza danych dystrybucji:

  1. Quiesce systemu: Zatrzymanie działania na bazie 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 zobaczHow to: Quiesce a Replication Topology (Replication Transact-SQL Programming).

  2. wykonać CHECKDB DBCC.

  3. Jeśli raport CHECKDB DBCC zawiera naprawy dla wszystkich tabel w bazie danych dystrybucji lub wszystkich tabel metadane replikacja baza danych użytkownika, należy usunąć i ponownie skonfigurować replikację.Aby uzyskać więcej informacji zobaczUsuwanie replikacja.

  4. Jeśli raport CHECKDB DBCC zawiera naprawy dla wszystkich zreplikowanych tabelach, należy wykonać sprawdzania poprawności danych, aby określić, czy istnieją różnice między danymi w publikacja i subskrypcja baz danych.Aby uzyskać więcej informacji zobaczData at the Publisher and Subscriber Do Not Match.

Zestawy wyników

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

The command(s) completed successfully.

DBCC CHECKDB zwraca następujący zestaw wyników, gdy określono 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ślono 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

Członkostwo w grupie wymaga sysadmin Rola serwera stałe lub db_owner stała rola bazy danych.

Przykłady

A.Sprawdzanie bazy danych AdventureWorks i bieżące

W poniższym przykładzie wykonywany DBCC CHECKDB dla bieżącej bazy danych i AdventureWorks Baza danych.

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

W poniższym przykładzie sprawdza, czy bieżąca baza danych i pozwala na wyświetlanie wszystkich komunikatów informacyjnych.

Historia zmian

Microsoft Learning

W definicji ALL_ERRORMSGS opisane nowe funkcje w dodatku SP1 dla programu SQL Server 2008.