DBCC CHECKTABLE (Transact-SQL)

Применимо к:База данныхSQL Server Azure SQL Управляемый экземпляр 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.

ALL_ERRORMSGS

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

EXTENDED_LOGICAL_CHECKS

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

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

NO_INFOMSGS

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

TABLOCK

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

ESTIMATEONLY

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

PHYSICAL_ONLY

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

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

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

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 (SP2) и более поздних версий.

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

Комментарии

Для указанной таблицы 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), дополнительные проверки сохраняемых вычисляемых столбцов, столбцов определяемого пользователем типа и отфильтрованные индексы не будут выполняться по умолчанию, чтобы избежать дорогостоящих вычислений выражений. Это изменение значительно сокращает продолжительность работы CHECKTABLE с базами данных, содержащими эти объекты. Однако проверки физической согласованности этих объектов всегда выполняются. Вычисления выражений выполняются только при EXTENDED_LOGICAL_CHECKS указании параметра в дополнение к уже имеющимся логическим проверкам (индексированные представления, XML-индексы и пространственные индексы) в EXTENDED_LOGICAL_CHECKS качестве части параметра.

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

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

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

Внутренняя snapshot базы данных

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

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

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

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

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

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

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

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

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

Если DBCC CHECKTABLE вы отчеты об ошибках, рекомендуется восстановить базу данных из резервной копии базы данных, а не запускать repair с одним из вариантов 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.

Примеры

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

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

DBCC CHECKTABLE ('HumanResources.Employee');
GO

Б. Выполнение проверка таблицы с минимальными затратами

В следующем примере выполняется низкая проверка 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);

См. также

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