Поделиться через

DBCC CHECKTABLE (Transact-SQL)

  • Статья

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

Производит проверку целостности всех страниц и структур, составляющих таблицу или индексированное представление.

Соглашения о синтаксисе Transact-SQL

Синтаксис

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

Аргументы

table_name | view_name

Таблица или индексированное представление, для которого выполняются проверки целостности. Имена таблиц и представлений должны соответствовать правилам построения идентификаторов.

NOINDEX

Указывает, что не следует выполнять интенсивные проверки некластеризованных индексов для пользовательских таблиц. Это уменьшает общее время выполнения. NOINDEX Не влияет на системные таблицы, так как проверки целостности всегда выполняются во всех системных индексах таблиц.

index_id

Номер идентификатора индекса, для которого выполняются проверки целостности. Если указан index_id , DBCC CHECKTABLE выполняет проверку целостности только на этом индексе вместе с кучей или кластеризованным индексом.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Указывает, что DBCC CHECKTABLE исправите найденные ошибки. Для использования параметра исправления база данных должна быть открыта в однопользовательском режиме.

  • REPAIR_ALLOW_DATA_LOSS

    Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

  • REPAIR_FAST

    Синтаксис сохраняется только в целях обратной совместимости. Действия по восстановлению не выполняются.

  • REPAIR_REBUILD

    Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).

    Этот аргумент не исправляет ошибки, связанные с данными FILESTREAM.

Внимание

Используйте аргументы REPAIR только как последнее средство. Для устранения ошибок рекомендуется восстановление из резервной копии. Операции восстановления не учитывают какие-либо ограничения, которые могут существовать в таблицах или между ними. Если указанная таблица включена в одно или несколько ограничений, рекомендуется выполнить инструкцию DBCC CHECKCONSTRAINTS после операции восстановления. Если необходимо использовать аргумент REPAIR, выполните инструкцию DBCC CHECKTABLE без параметра восстановления, чтобы узнать требуемый уровень восстановления. Если вы используете REPAIR_ALLOW_DATA_LOSS уровень, рекомендуется создать резервную копию базы данных перед выполнением DBCC CHECKTABLE этого параметра.

ALL_ERRORMSGS

Отображает неограниченное число ошибок. Все сообщения об ошибках выводятся по умолчанию. Указание или пропуск этого параметра не приводит к изменениям.

EXTENDED_LOGICAL_CHECKS

Если уровень совместимости равен 100, представлен в SQL Server 2008 (10.0.x), выполняет логические проверки согласованности для индексированного представления, XML-индексов и пространственных индексов, где присутствует.

Дополнительные сведения см. в разделе "Выполнение логических проверок согласованности по индексам" в разделе "Примечания" далее в этой статье.

NO_INFOMSGS

Подавляет вывод всех информационных сообщений.

TABLOCK

DBCC CHECKTABLE Причины получения общей блокировки таблицы вместо использования внутреннего моментального снимка базы данных. TABLOCK приведет DBCC CHECKTABLE к более быстрому выполнению таблицы под тяжелой нагрузкой, но уменьшает параллелизм, доступный в таблице во время DBCC CHECKTABLE выполнения.

ESTIMATEONLY

Отображает предполагаемое количество места, необходимого tempdb для выполнения DBCC CHECKTABLE со всеми другими указанными параметрами.

PHYSICAL_ONLY

Ограничивает область проверки целостностью физической структуры страниц, заголовков записей и физической структуры сбалансированных деревьев. Параметр предназначен для выполнения облегченной проверки физической согласованности таблицы, а также может выявлять поврежденные страницы и общие сбои оборудования, которые могут привести к потере данных. Полный запуск DBCC CHECKTABLE может занять значительно больше времени, чем в более ранних версиях. Это вызвано следующими причинами.

  • Логические проверки стали более сложными.
  • Усложнился ряд базовых структур, нуждающихся в проверке.
  • Добавлено много новых проверок для поддержки новых функций.

Примечание.

В документации термин B-tree обычно используется в ссылке на индексы. В индексах rowstore ядро СУБД реализует дерево B+. Это не относится к индексам columnstore или индексам в таблицах, оптимизированных для памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Sql Server и Azure.

Поэтому использование PHYSICAL_ONLY параметра может привести к гораздо более короткому времени выполнения для DBCC CHECKTABLE больших таблиц и поэтому рекомендуется для частого использования в рабочих системах. Мы по-прежнему рекомендуем периодически выполнять полный DBCC CHECKTABLE запуск. Периодичность запуска зависит от факторов, индивидуальных для каждого предприятия и каждой производственной среды. PHYSICAL_ONLY всегда подразумевает NO_INFOMSGS и не допускается с одним из вариантов восстановления.

Примечание.

Указание PHYSICAL_ONLY причин DBCC CHECKTABLE пропуска всех проверок данных FILESTREAM.

DATA_PURITY

Причины DBCC CHECKTABLE проверки таблицы для значений столбцов, которые не являются допустимыми или не допустимыми. Например, DBCC CHECKTABLE обнаруживает столбцы со значениями даты и времени, которые больше или меньше допустимого диапазона для типа данных datetime ; или столбцы типа данных десятичного или приблизительного числа с недопустимыми значениями масштабирования или точности.

Проверки целостности столбцов включены по умолчанию и не требуют этого DATA_PURITY параметра. Для баз данных, обновленных с более ранних версий SQL Server, можно DBCC CHECKTABLE WITH DATA_PURITY найти и исправить ошибки в определенной таблице. Однако проверки значений столбцов в таблице по умолчанию не включены до тех пор, пока DBCC CHECKDB WITH DATA_PURITY не будет запущена ошибка в базе данных. После этого DBCC CHECKDB и DBCC CHECKTABLE проверьте целостность значения столбца по умолчанию.

Ошибки проверки, сообщаемые этим параметром, не могут быть исправлены с помощью параметров восстановления DBCC. Дополнительные сведения об устранении этих ошибок вручную см. в статье 923247 базы знаний Майкрософт: Устранение ошибки DBCC 2570 в SQL Server 2005 и более поздних версиях.

Если PHYSICAL_ONLY задано, проверки целостности столбцов не выполняются.

MAXDOP

Область применения: SQL Server 2014 (12.x) с пакетом обновления 2 и более поздних версий.

Переопределяет параметр sp_configure конфигурации максимальной степени параллелизма для инструкции. MaxDOP может превышать значение, настроенное с sp_configureпомощью . Если MAXDOP превышает значение, настроенное с помощью Resource Governor, ядро СУБД использует значение MAXDOP из Resource Governor, как описано в разделе ALTER WORKLOAD GROUP (Transact-SQL). Все семантические правила, используемые параметром конфигурации max degree of parallelism, применимы при использовании указания запроса MAXDOP. Дополнительные сведения см. в разделе Настройка параметра конфигурации сервера max degree of parallelism.

Примечание.

Если значение MAXDOP равно нулю, то сервер выбирает максимальную степень параллелизма.

Замечания

Примечание.

Чтобы выполнить DBCC CHECKTABLE каждую таблицу в базе данных, используйте DBCC CHECKDB.

В указанной таблице DBCC CHECKTABLE проверяется следующее:

  • Верны ли ссылки на страницы данных индекса, на страницы данных в строке, на превышающие размер страницы данные строки и на страницы больших объектов.
  • Верен ли порядок сортировки индексов.
  • Согласованы ли указатели.
  • Обоснованы ли данные, содержащиеся на каждой из страниц, в том числе вычисляемые столбцы.
  • Обоснованы ли смещения страниц.
  • Все ли строки в базовой таблице имеют совпадающие строки в некластеризованных индексах, и наоборот.
  • Все ли строки в секционированной таблице или индексе находятся в соответствующих секциях.
  • Согласованность между файловой системой и таблицей на уровне ссылок при хранении данных varbinary(max) в файловой системе с помощью FILESTREAM.

Выполнение проверок логической согласованности индексов

Процедура проверки логической целостности индексов зависит от уровня совместимости базы данных следующим образом.

  • Если уровень совместимости равен 100 (SQL Server 2008 (10.0.x)) или выше:

    • Если не NOINDEX указано, выполняет как физические, DBCC CHECKTABLE так и логические проверки согласованности для одной таблицы и всех некластеризованных индексов. Однако в XML-индексах, пространственных индексах и индексированных представлениях по умолчанию выполняются только проверки физической целостности.

    • Если указан параметр WITH EXTENDED_LOGICAL_CHECKS, выполняются проверки логической согласованности в индексированном представлении, XML-индексах и пространственных индексах (при их наличии). По умолчанию проверки физической согласованности выполняются раньше, чем проверки логической согласованности. Если также указан параметр NOINDEX, выполняются только проверки логической согласованности.

      Они проверяют согласованность внутренней таблицы индексов или объекта индекса с пользовательской таблицей, на которую он указывает. Для поиска выбросов создается внутренний запрос, выполняющий полную проверку пересечения внутренних и пользовательских таблиц. Выполнение этого запроса может иметь очень высокий эффект на производительность, и его ход выполнения не может быть отслеживаем. Поэтому рекомендуется указывать параметр WITH EXTENDED_LOGICAL_CHECKS только в тех случаях, когда возможно возникновение проблем с индексированием, не связанных с физическими повреждениями, или при неверных контрольных суммах на уровне страниц, либо же при подозрении на повреждение оборудования на уровне столбцов.

    • Если индекс является отфильтрованным индексом, выполняет проверки согласованности, чтобы убедиться, DBCC CHECKTABLE что записи индекса удовлетворяют предикату фильтра.

  • Начиная с SQL Server 2016 (13.x), дополнительные проверки на сохраненные вычисляемые столбцы, столбцы UDT и отфильтрованные индексы по умолчанию не выполняются, чтобы избежать дорогостоящих вычислений выражений. Это изменение значительно сокращает продолжительность CHECKTABLE баз данных, содержащих эти объекты. Однако проверки физической согласованности этих объектов всегда выполняются. EXTENDED_LOGICAL_CHECKS В дополнение к уже имеющимся логическим проверкам (индексированные представления, XML-индексы и пространственные индексы) EXTENDED_LOGICAL_CHECKS выполняются только при указании параметра вычислений выражений.

  • Если уровень совместимости равен 90 (SQL Server 2005 (9.x)) или меньше, если NOINDEX он не указан, выполняет как физические, DBCC CHECKTABLE так и логические проверки согласованности для одной таблицы или индексированного представления, а также для всех некластеризованных и XML-индексов. Пространственные индексы не поддерживаются.

Определение уровня совместимости базы данных

Внутренний моментальный снимок базы данных

DBCC CHECKTABLE использует внутренний моментальный снимок базы данных для обеспечения согласованности транзакций, который должен выполнять эти проверки. Дополнительные сведения см. в разделе "Размер разреженного файла моментального снимка базы данных" (Transact-SQL) и раздела об использовании внутреннего моментального снимка базы данных DBCC (Transact-SQL).

Если моментальный снимок не может быть создан или TABLOCK указан, DBCC CHECKTABLE получает блокировку общей таблицы для получения требуемой согласованности.

Примечание.

Если DBCC CHECKTABLE выполняется против tempdb, он должен получить общую блокировку таблицы. Это связано с тем, что по соображениям производительности моментальные снимки базы данных недоступны tempdb. Это означает, что нельзя достичь требуемой согласованности транзакций.

Проверка и восстановление данных FILESTREAM

Если для базы данных и таблицы включен режим FILESTREAM, то существует возможность хранения больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе. При использовании в таблице, в которой хранятся DBCC CHECKTABLE BLOB-объекты в файловой системе, DBCC проверяет согласованность на уровне ссылок между файловой системой и базой данных.

Например, если таблица содержит столбец varbinary(max), использующий атрибут FILESTREAM, убедитесь, DBCC CHECKTABLE что между каталогами файловой системы и файлами и строками таблиц, столбцами и значениями столбцов существует одно-одно сопоставление. DBCC CHECKTABLE Может исправить повреждение, если указать REPAIR_ALLOW_DATA_LOSS этот параметр. Чтобы восстановить повреждение FILESTREAM, DBCC удаляет все строки таблицы, отсутствующие данные файловой системы, и будут удалять все каталоги и файлы, которые не сопоставляются со строкой таблицы, столбцом или значением столбца.

Параллельное проверка объектов

По умолчанию DBCC CHECKTABLE выполняется параллельная проверка объектов. Степень параллелизма определяется автоматически обработчиком запросов. Максимальная степень параллелизма настраивается точно так же, как и для параллельных запросов. Чтобы ограничить максимальное число процессоров, доступных для проверки DBCC, используйте процедуру sp_configure. Дополнительные сведения см. в разделе Настройка параметра конфигурации сервера max degree of parallelism.

Параллельная проверка может быть отключена с помощью флага трассировки 2528. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).

Примечание.

DBCC CHECKTABLE Во время операции байты, хранящиеся в столбце определяемого пользователем типа байтов, должны быть равны вычисляемой сериализации определяемого пользователем значения типа. Если это не так, подпрограмма DBCC CHECKTABLE сообщит об ошибке согласованности.

Примечание.

Эта функция недоступна в каждом выпуске SQL Server. Дополнительные сведения см. в разделе проверки согласованности параллельной согласованности в разделе управляемости RDBMS в выпусках и поддерживаемых функциях SQL Server 2022.

Общие сведения об ошибках DBCC

DBCC CHECKTABLE После завершения команды сообщение записывается в журнал ошибок SQL Server. При успешном выполнении команды DBCC сообщается об успешном завершении и количестве времени, затраченном на выполнение команды. Если выполнение команды DBCC прерывается до завершения проверки по причине ошибки, сообщение указывает на прерывание команды и приводит значение состояния и количество времени, затраченного на выполнение команды. В следующей таблице перечислены и описаны значения состояний, которые могут быть включены в сообщение.

State Описание:
0 Возникла ошибка с номером 8930. Это указывает на повреждение метаданных, вызвавшее прекращение выполнения команды DBCC.
1 Возникла ошибка с номером 8967. Внутренняя ошибка DBCC.
2 При аварийном восстановлении базы данных произошла ошибка.
3 Это указывает на повреждение метаданных, вызвавшее прекращение выполнения команды DBCC.
4 Обнаружено нарушение доступа или утверждения.
5 Возникла неизвестная ошибка, которая привела к прекращению выполнения команды DBCC.

Отчеты об ошибках

Файл мини-дампа (SQLDUMP<nnnn>.txt) создается в каталоге SQL Server LOG при обнаружении DBCC CHECKTABLE ошибки повреждения. Если для экземпляра SQL Server включены сбор данных об использовании компонентов и функции отчетов об ошибках, файл автоматически перенаправляются в корпорацию Майкрософт. Собранные данные используются для улучшения функциональности SQL Server.

Файл дампа содержит результаты DBCC CHECKTABLE команды и дополнительные диагностические выходные данные. Доступ к этому файлу ограничен списками управления доступом на уровне пользователей. Доступ ограничен учетной записью службы SQL Server и членами роли sysadmin. По умолчанию роль sysadmin содержит всех членов группы Windows BUILTIN\Administrators и группы локальных администраторов. Команда DBCC не завершается ошибкой, если процесс сбора данных завершается сбоем.

Устранение ошибок

Если DBCC CHECKTABLE сообщает об ошибках, рекомендуется восстановить базу данных из резервной копии базы данных вместо запуска REPAIR с одним из вариантов ВОССТАНОВЛЕНИЯ. Если резервная копия отсутствует, исправить выданные ошибки можно запуском параметра REPAIR. В конце списка ошибок указано, какой из параметров REPAIR следует использовать. Тем не менее, что исправление ошибок с помощью REPAIR_ALLOW_DATA_LOSS параметра может потребовать удаления некоторых страниц и, следовательно, данных.

Исправление ошибок может быть выполнено в пользовательской транзакции, позволяя откатить произведенные изменения. Если восстановление откатывается, база данных по-прежнему будет содержать ошибки и должна быть восстановлена из резервной копии. После завершения исправления всех ошибок создайте резервную копию базы данных.

Результирующие наборы

DBCC CHECKTABLE возвращает следующий результирующий набор. Тот же результирующий набор возвращается как при указании только имени таблицы, так и при указании любых параметров.

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 Возвращает следующий результирующий набор, если указан параметр 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.

Разрешения

Пользователь должен быть либо владельцем таблицы, либо членом предопределенной роли сервера sysadmin, предопределенной роли базы данных db_owner или предопределенной роли базы данных db_ddladmin.

Примеры

А. Проверка определенной таблицы

В следующем примере проверяется HumanResources.Employee целостность страницы данных таблицы в базе данных AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Проверка низкой нагрузки таблицы

В следующем примере выполняется низкая нагрузка на Employee таблицу в базе данных AdventureWorks2022.

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

В. Проверка определенного индекса

В следующем примере производится проверка указанного индекса, полученного из sys.indexes.

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);

См. также