DBCC CHECKTABLE (Transact-SQL)

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Sprawdza integralność wszystkich stron i struktur tworzących tabelę lub indeksowany widok.

Transact-SQL konwencje składni

Składnia

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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 (w programowaniu)

| table_nameview_name

Tabela lub widok indeksowany, dla którego można uruchomić kontrole integralności. Nazwy tabel lub widoków muszą być zgodne z regułami dotyczącymi identyfikatorów.

NOINDEX

Określa, że nie należy wykonywać intensywnych kontroli indeksów nieklastrowanych dla tabel użytkowników. Zmniejsza to całkowity czas wykonywania. NOINDEX nie ma wpływu na tabele systemowe, ponieważ kontrole integralności są zawsze wykonywane we wszystkich indeksach tabeli systemu.

index_id

Numer identyfikacji indeksu (ID), dla którego ma zostać uruchomione kontrole integralności. Jeśli określono index_id , DBCC CHECKTABLE uruchamia kontrole integralności tylko dla tego indeksu, wraz ze stertą lub indeksem klastrowanym.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Określa, że DBCC CHECKTABLE naprawić znalezione błędy. Aby użyć opcji naprawy, baza danych musi być w trybie pojedynczego użytkownika.

• Zezwolenie_na_naprawę_z_utrata_danych

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

• NAPRAWA_SZYBKO

  Składnia jest obsługiwana tylko w celu zachowania zgodności z poprzednimi wersjami. Nie są wykonywane żadne akcje naprawy.

• NAPRAWA_PRZEBUDOWA

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

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

ALL_ERRORMSGS

Wyświetla nieograniczoną liczbę błędów. Wszystkie komunikaty o błędach są domyślnie wyświetlane. Określenie lub pominięcie tej opcji nie ma wpływu.

ROZSZERZONE_LOGICZNE_SPRAWDZENIA

Jeśli poziom zgodności wynosi 100, wprowadzony w programie SQL Server 2008 (10.0.x), przeprowadza 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 Wykonywanie kontroli spójności logicznej na indeksach w sekcji Uwagi w dalszej części tego artykułu.

NO_INFOMSGS

Pomija wszystkie komunikaty informacyjne.

TABLOCK

Powoduje DBCC CHECKTABLE uzyskanie blokady udostępnionej tabeli zamiast używania wewnętrznej migawki bazy danych. TABLOCK spowoduje DBCC CHECKTABLE szybsze uruchomienie tabeli pod dużym obciążeniem, ale zmniejsza współbieżność dostępną w tabeli podczas DBCC CHECKTABLE działania.

TYLKO SZACOWANIE

Przedstawia szacowaną ilość miejsca potrzebnego tempdb do uruchomienia DBCC CHECKTABLE ze wszystkimi innymi określonymi opcjami.

PHYSICAL_ONLY

Ogranicza sprawdzanie integralności fizycznej struktury strony, nagłówków rekordów i fizycznej struktury drzew B.. Zaprojektowana w celu zapewnienia niewielkiej kontroli spójności fizycznej tabeli, ta kontrola może również wykrywać rozdarte strony i typowe awarie sprzętowe, które mogą naruszyć bezpieczeństwo danych. Pełny przebieg DBCC CHECKTABLE może trwać znacznie dłużej niż we wcześniejszych wersjach. To zachowanie występuje z następujących powodów:

• 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 PHYSICAL_ONLY opcji może spowodować znacznie krótszy czas wykonywania dla DBCC CHECKTABLE dużych tabel i dlatego jest zalecane do częstego używania w systemach produkcyjnych. Nadal zalecamy okresowe wykonywanie pełnego przebiegu DBCC CHECKTABLE . Częstotliwość tych przebiegów zależy od czynników specyficznych dla poszczególnych firm i środowisk produkcyjnych. PHYSICAL_ONLY zawsze oznacza NO_INFOMSGS i nie jest dozwolony z żadną z opcji naprawy.

CZYSTOŚĆ DANYCH

Przyczyny DBCC CHECKTABLE sprawdzania tabeli pod kątem wartości kolumn, które nie są prawidłowe lub poza zakresem. Na przykład DBCC CHECKTABLE 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 można DBCC CHECKTABLE WITH DATA_PURITY znaleźć i poprawić błędy w określonej tabeli. Jednak kontrole wartości kolumn w tabeli nie są domyślnie włączone, dopóki DBCC CHECKDB WITH DATA_PURITY nie zostanie uruchomiony błąd wolny od błędu w bazie danych. DBCC CHECKDB Następnie sprawdź DBCC CHECKTABLE integralność wartości kolumny domyślnie.

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 Rozwiązywanie problemów z błędami spójności bazy danych zgłoszonymi przez bazę danych DBCC CHECKDB.

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

MAXDOP

Dotyczy: SQL Server 2014 (12.x) Service Pack 2 i nowsze wersje.

Zastępuje opcję konfiguracji sp_configure dla instrukcji . Parametr MAXDOP może przekroczyć wartość skonfigurowaną za pomocą sp_configurepolecenia . Jeśli parametr MAXDOP przekracza wartość skonfigurowaną za pomocą zarządcy zasobów, aparat bazy danych używa wartości MAXDOP zarządcy zasobów opisanej w artykule ALTER WORKLOAD GROUP (Transact-SQL). Wszystkie reguły semantyczne używane z maksymalną opcją konfiguracji równoległości mają zastosowanie podczas korzystania z wskazówki zapytania MAXDOP. Aby uzyskać więcej informacji, zobacz Configure the max degree of parallelism Server Configuration Option.

Uwagi

W przypadku określonej tabeli sprawdza następujące DBCC CHECKTABLE kwestie:

• Indeksowanie, strony danych w wierszu, LOB i przepełnienie wierszy są poprawnie połączone.
• Indeksy są w prawidłowej kolejności sortowania.
• Wskaźniki są spójne.
• Dane na każdej stronie są uzasadnione, uwzględniane kolumny obliczeniowe.
• Przesunięcia stron są uzasadnione.
• Każdy wiersz w tabeli bazowej ma pasujący wiersz w każdym indeksie nieklastrowanym i odwrotnie.
• Każdy wiersz w partycjonowanej tabeli lub indeksie znajduje się we właściwej partycji.
• Spójność na poziomie połączenia między systemem plików i tabelą podczas przechowywania danych varbinary(max) w systemie plików przy użyciu funkcji FILESTREAM.

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 to 100 (SQL Server 2008 (10.0.x)) lub nowszy:

  • O ile nie określono NOINDEX, DBCC CHECKTABLE 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.

    Te testy spójności logicznej sprawdzają krzyżowo wewnętrzną tabelę indeksów obiektu indeksu z tabelą użytkownika, do którego się odwołuje. 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ć 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, 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 CHECKTABLE przeprowadza sprawdzanie spójności w celu sprawdzenia, czy wpisy indeksu spełniają predykat filtru.

• Począwszy od programu SQL Server 2016 (13.x), dodatkowe kontrole utrwalonych kolumn obliczeniowych, kolumn UDT i filtrowanych indeksów nie będą domyślnie uruchamiane, aby uniknąć kosztownych ocen wyrażeń. Ta zmiana znacznie skraca długość trwania CHECKTABLE w przypadku baz danych zawierających te obiekty. Jednak testy spójności fizycznej tych obiektów są zawsze wykonywane. Tylko wtedy, gdy EXTENDED_LOGICAL_CHECKS jest określona opcja, są wykonywane oceny wyrażeń, oprócz już obecnych kontroli logicznych (widok indeksowany, indeksy XML i indeksy przestrzenne) w ramach EXTENDED_LOGICAL_CHECKS opcji.

• Jeśli poziom zgodności wynosi 90 (SQL Server 2005 (9.x)) lub mniej, chyba że NOINDEX zostanie określony, DBCC CHECKTABLE 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.

Aby poznać poziom zgodności bazy danych

• Wyświetlanie lub zmienianie poziomu zgodności bazy danych

Wewnętrzna migawka bazy danych

DBCC CHECKTABLE używa wewnętrznej migawki bazy danych, aby zapewnić spójność transakcyjną, którą musi wykonać te testy. Aby uzyskać więcej informacji, zobacz Wyświetlanie rozmiaru pliku rozrzedzielonego migawki bazy danych (Transact-SQL) i sekcji użycia wewnętrznej migawki bazy danych DBCC w pliku DBCC (Transact-SQL).

Jeśli nie można utworzyć migawki lub TABLOCK jest określona, uzyskuje blokadę udostępnionej tabeli w DBCC CHECKTABLE celu uzyskania wymaganej spójności.

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 użycia DBCC CHECKTABLE w tabeli, która przechowuje obiekty BLOB w systemie plików, funkcja DBCC sprawdza spójność na poziomie połączenia między systemem plików a bazą danych.

Jeśli na przykład tabela zawiera kolumnę varbinary(max), która używa atrybutu FILESTREAM, sprawdzi, DBCC CHECKTABLE czy istnieje mapowanie jeden do jednego między katalogami systemu plików a plikami i wierszami tabeli, kolumnami i wartościami kolumn. DBCC CHECKTABLE może naprawić uszkodzenie, jeśli określisz opcję REPAIR_ALLOW_DATA_LOSS. Aby naprawić uszkodzenie FILESTREAM, DBCC usunie wszystkie wiersze tabeli, które nie zawierają danych systemu plików i usunie wszystkie katalogi i pliki, które nie są mapowane na wiersz tabeli, kolumnę lub wartość kolumny.

Równoległe sprawdzanie obiektów

Domyślnie DBCC CHECKTABLE 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 w taki sam sposób, jak w przypadku zapytań równoległych. Aby ograniczyć maksymalną liczbę procesorów dostępnych do sprawdzania DBCC, użyj sp_configure. Aby uzyskać więcej informacji, zobacz Configure the max degree of parallelism Server Configuration Option.

Sprawdzanie równoległe można wyłączyć przy użyciu flagi śledzenia 2528. Aby uzyskać więcej informacji, zobacz Trace Flags (Transact-SQL).

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

Po zakończeniu DBCC CHECKTABLE polecenia zostanie zapisany komunikat w dzienniku błędów programu SQL Server. Jeśli polecenie DBCC zostanie wykonane pomyślnie, komunikat wskazuje pomyślne ukończenie i czas uruchomienia polecenia. Jeśli polecenie DBCC zatrzymuje się przed ukoń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.

Raportowanie błędów

Plik mini-zrzutu (SQLDUMP<nnnn>.txt) jest tworzony w katalogu LOG programu SQL Server za każdym razem, gdy DBCC CHECKTABLE wykryje błąd uszkodzenia. 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 CHECKTABLE i dodatkowe dane wyjściowe diagnostyczne. Plik ma ograniczone uznaniowe listy kontroli dostępu (DACLs). 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 WINDOWS BUILTIN\Administrators i grupy administratora lokalnego. Polecenie DBCC nie ulega awarii, jeśli proces zbierania danych zakończy się niepowodzeniem.

Usuwanie błędów

Jeśli DBCC CHECKTABLE wystąpią jakiekolwiek błędy, zalecamy przywrócenie bazy danych z kopii zapasowej bazy danych zamiast uruchamiania funkcji REPAIR przy użyciu jednej z opcji NAPRAW. Jeśli żadna kopia zapasowa nie istnieje, uruchomienie polecenia REPAIR może poprawić zgłoszone błędy. Opcja NAPRAWa do użycia jest określona na końcu listy zgłoszonych błędów. Jednak usunięcie błędów przy użyciu REPAIR_ALLOW_DATA_LOSS opcji może wymagać usunięcia niektórych stron, a tym samym danych.

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

Zestawy wyników

DBCC CHECKTABLE zwraca następujący zestaw wyników. Ten sam zestaw wyników jest zwracany, jeśli określisz tylko nazwę tabeli lub dowolną z opcji.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE Zwraca następujący zestaw wyników, jeśli określono opcję ESTIMATEONLY:

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Uprawnienia

Użytkownik musi być właścicielem tabeli lub być członkiem stałej roli serwera sysadmin, db_owner stałej roli bazy danych lub db_ddladmin stałej roli bazy danych.

Przykłady

Odp. Sprawdzanie określonej tabeli

Poniższy przykład sprawdza integralność HumanResources.Employee strony danych tabeli w bazie danych AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Przeprowadzanie sprawdzania niskiego obciążenia tabeli

W poniższym przykładzie jest wykonywane sprawdzanie Employee niskiego obciążenia tabeli w bazie danych AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Sprawdzanie określonego indeksu

Poniższy przykład sprawdza określony indeks uzyskany przez uzyskanie sys.indexesdostępu do elementu .

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Zobacz także

• DBCC (Transact-SQL)
• DBCC CHECKDB (Transact-SQL)