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 ]
}
]
Примечание
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Аргументы
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 к получению блокировки общей таблицы вместо использования внутренней базы данных snapshot. TABLOCK приведет DBCC CHECKTABLE к более быстрому выполнению в таблице с высокой нагрузкой, но уменьшает параллелизм, доступный для таблицы во время DBCC CHECKTABLE выполнения.
ESTIMATEONLY
Отображает предполагаемый объем пространства, необходимого tempdb для выполнения DBCC CHECKTABLE , со всеми другими указанными параметрами.
PHYSICAL_ONLY
Ограничивает область проверки целостностью физической структуры страниц, заголовков записей и физической структуры сбалансированных деревьев. Параметр предназначен для выполнения облегченной проверки физической согласованности таблицы, а также может выявлять поврежденные страницы и общие сбои оборудования, которые могут привести к потере данных. Полный DBCC CHECKTABLE запуск может занять значительно больше времени, чем в более ранних версиях. Это вызвано следующими причинами.
- Логические проверки стали более сложными.
- Усложнился ряд базовых структур, нуждающихся в проверке.
- Добавлено много новых проверок для поддержки новых функций.
Примечание
В документации по SQL Server термин "сбалансированное дерево" обычно используется в отношении индексов. В индексах rowstore SQL Server реализует B+-дерево. Это не относится к индексам columnstore или хранилищам данных в памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Server и Azure SQL.
Таким образом, использование 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 (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.
Примечание
Если значение 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), дополнительные проверки сохраняемых вычисляемых столбцов, столбцов определяемого пользователем типа и отфильтрованные индексы не будут выполняться по умолчанию, чтобы избежать дорогостоящих вычислений выражений. Это изменение значительно сокращает продолжительность работы
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 получает блокировку общей таблицы для получения требуемой согласованности.
Примечание
Если DBCC CHECKTABLE выполняется в tempdb, он должен получить блокировку общей таблицы. Это связано с тем, что из соображений производительности моментальные снимки базы данных недоступны в tempdb. Это означает, что нельзя достичь требуемой согласованности транзакций.
Проверка и восстановление данных 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 CHECKTABLE Во время операции байты, хранящиеся в байтовом упорядоченном столбце определяемого пользователем типа, должны быть равны вычисляемой сериализации значения определяемого пользователем типа. Если это не так, подпрограмма DBCC CHECKTABLE сообщит об ошибке согласованности.
Примечание
Эта функция поддерживается не во всех выпусках SQL Server. Дополнительные сведения см. в разделе Параллельная согласованность проверка в разделе Управляемость RDBMSстатьи Выпуски и поддерживаемые функции SQL Server 2022.
Общие сведения о сообщениях об ошибках DBCC
DBCC CHECKTABLE После завершения выполнения команды в журнал ошибок SQL Server записывается сообщение. При успешном выполнении команды DBCC сообщается об успешном завершении и количестве времени, затраченном на выполнение команды. Если выполнение команды DBCC прерывается до завершения проверки по причине ошибки, сообщение указывает на прерывание команды и приводит значение состояния и количество времени, затраченного на выполнение команды. В следующей таблице перечислены и описаны значения состояний, которые могут быть включены в сообщение.
| Состояние | Описание |
|---|---|
| 0 | Возникла ошибка с номером 8930. Это указывает на повреждение метаданных, вызвавшее прекращение выполнения команды DBCC. |
| 1 | Возникла ошибка с номером 8967. Внутренняя ошибка DBCC. |
| 2 | При аварийном восстановлении базы данных произошла ошибка. |
| 3 | Это указывает на повреждение метаданных, вызвавшее прекращение выполнения команды DBCC. |
| 4 | Обнаружено нарушение доступа или утверждения. |
| 5 | Возникла неизвестная ошибка, которая привела к прекращению выполнения команды 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);
См. также
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по