DBCC CHECKDB (Transact-SQL)

Статья
12/15/2008

Изменения: 17 ноября 2008 г.

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

Выполнение инструкции DBCC CHECKALLOC для базы данных.
Выполнение инструкции DBCC CHECKTABLE для каждой таблицы и каждого представления в базе данных.
Выполнение инструкции DBCC CHECKCATALOG для базы данных.
Проверка содержимого каждого индексированного представления в базе данных.
Проверка данных компонента Service Broker в базе данных.

Из этого следует, что не требуется дополнительно вызывать инструкции DBCC CHECKALLOC, DBCC CHECKTABLE и DBCC CHECKCATALOG при использовании инструкции DBCC CHECKDB. Дополнительные сведения о проверках, выполняемых этими командами, см. в описании данных команд.

Значок ссылки на раздел Соглашения о синтаксическом обозначении в Transact-SQL

Синтаксис

DBCC CHECKDB 
[
    [ ( database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
        ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

Аргументы

database_name | database_id | 0
Имя или идентификатор базы данных, для которой необходимо выполнить проверку целостности. Если значение не указано или указано значение 0, используется текущая база данных. Имена баз данных должны соответствовать правилам идентификаторов.

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

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Указывает, что инструкция DBCC CHECKDB должна исправить обнаруженные ошибки. Для применения описанных ниже параметров исправления указанная база данных ** должна находиться в однопользовательском режиме.

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

REPAIR_FAST
Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.

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

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

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

ALL_ERRORMSGS
Отображает все сформированные для объекта ошибки. В SQL Server 2005 с пакетом обновления 3 (SP3) по умолчанию отображаются все сообщения об ошибках. Указание или пропуск этого параметра не имеют значения. В более ранних версиях SQL Server, если аргумент ALL_ERRORMSGS не указан, будут отображаться лишь первые 200 сообщений об ошибках для каждого объекта. Сообщения об ошибках, за исключением сообщений, формируемых базой данных empdb, сортируются по идентификатору объекта.

В среде SQL Server Management Studio максимальное число возвращаемых сообщений об ошибках равно 1000. В случае если задан параметр ALL_ERRORMSGS, то при использовании среды Management Studio может возникнуть необходимость в неоднократном выполнении команды DBCC CHECKDB для получения полного списка ошибок. Команду DBCC рекомендуется выполнять с помощью программы sqlcmd или с помощью планирования задания агента SQL Server для выполнения этой команды с последующим перенаправлением результатов в файл. Использование любого из этих методов обеспечит однократное выполнение команды и включение в отчет всех сообщений об ошибках.

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

TABLOCK
Указание значения аргумента приводит к получению инструкцией DBCC CHECKDB блокировок вместо использования моментального снимка внутренней базы данных. Это включает краткосрочное использование монопольной блокировки (X) на базу данных. Аргумент TABLOCK позволит инструкции DBCC CHECKDB быстрее выполняться на базе данных, находящейся под интенсивной нагрузкой, однако уменьшит возможности одновременной работы пользователей с базой данных во время выполнения инструкции DBCC CHECKDB. Дополнительные сведения о блокировке см. в разделе Режимы блокировки.

Аргумент TABLOCK ограничивает выполняемые проверки; инструкция DBCC CHECKCATALOG не выполняется в базе данных, а данные компонента Service Broker останутся непроверенными.

ESTIMATEONLY
Отображает оценочный объем места в базе данных tempdb, необходимый для запуска инструкции DBCC CHECKDB со всеми остальными заданными параметрами. Сама проверка базы данных не выполняется.

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

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

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

Если указан аргумент PHYSICAL_ONLY, проверка целостности значений в столбцах не выполняется.

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

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

Инструкция DBCC CHECKDB возвращает следующий результирующий набор. Значения могут различаться, кроме случаев, когда указаны параметры ESTIMATEONLY, PHYSICAL_ONLY или 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 возвращает следующий результирующий набор (сообщение) при указании атрибута NO_INFOMSGS:

The command(s) completed successfully.

Инструкция DBCC CHECKDB возвращает следующий результирующий набор при указании атрибута 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 возвращает следующий результирующий набор при указании атрибута 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.

Замечания

В предыдущих версиях SQL Server, счетчики строк и страниц по таблицам и по индексам могли принимать неверные значения. В некоторых обстоятельствах одно или несколько значений могли даже становиться отрицательными. В SQL Server 2005 эти значения всегда обслуживаются правильно. Поэтому базы данных, созданные в SQL Server 2005, не должны содержать неправильных счетчиков, а базы данных, обновленные до версии SQL Server 2005, могут их содержать. Это не является повреждением каких-либо данных, хранящихся в базе данных. В инструкцию DBCC CHECKDB добавлена проверка этих счетчиков на отрицательное значение. При обнаружении отрицательных счетчиков выходные данные инструкции DBCC CHECKDB будут содержать предупреждение и рекомендацию о выполнении инструкции DBCC UPDATEUSAGE для решения этой проблемы. Может показаться, что возникновение проблемы связано с обновлением базы данных до SQL Server 2005, но в действительности неправильные счетчики существовали и до обновления.

Инструкция DBCC CHECKDB не анализирует отключенные индексы. Дополнительные сведения об отключенных индексах см. в разделе Отключение индексов.

Если определяемый пользователем тип помечен как упорядоченный по байтам, должна быть выполнена только одна сериализация определяемого пользователем типа. Невыполнение согласованной сериализации упорядоченных по байтам типов, определяемых пользователем, приведет к возникновению ошибки 2537 при запуске инструкции DBCC CHECKDB. Дополнительные сведения см. в разделе User-Defined Type Requirements.

Поскольку база данных Resource доступна для изменения только в однопользовательском режиме, выполнить команду DBCC CHECKDB непосредственно для нее невозможно. Однако при выполнении инструкции DBCC CHECKDB для базы данных master внутренним образом запускается вторая инструкция CHECKDB для базы данных Resource. Поэтому инструкция DBCC CHECKDB может вернуть дополнительные результаты. Эта инструкция возвратит дополнительные результирующие наборы, если не указано параметров или указан один из параметров PHYSICAL_ONLY или ESTIMATEONLY.

В версиях SQL Server 2005, предшествующих пакету обновления 2 (SP2), выполнение команды DBCC CHECKDB очищает кэш планов для экземпляра SQL Server. Очистка кэша планов становится причиной перекомпиляции всех последующих планов выполнения и может приводить к непредвиденному временному снижению производительности обработки запросов. В версии с пакетом обновления 2 (SP2) выполнение DBCC CHECKDB кэш планов не очищает.

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

Инструкция DBCC CHECKDB использует моментальный снимок внутренней базы данных для обеспечения согласованности транзакций, необходимой для выполнения данных проверок. Тем самым предотвращаются проблемы блокировки и параллелизма при выполнении этих команд. Дополнительные сведения см. в разделе Основные сведения о размере разреженных файлов в моментальных снимках базы данных, а также в подразделе «Использование моментальных снимков внутренней базы данных в командах DBCC» раздела DBCC (Transact-SQL). При невозможности создать моментальный снимок или при указании аргумента TABLOCK инструкция DBCC CHECKDB получает блокировки для обеспечения требуемой согласованности данных. В таком случае для проверки выделенных ресурсов необходима монопольная блокировка базы данных, а для проверки таблиц — разделяемая блокировка таблицы.

Инструкция DBCC CHECKDB завершается со сбоем при обработке базы данных master, если не удается создать внутренний моментальный снимок базы данных.

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

Наиболее оптимальные методы

В SQL Server 2005 выполнение инструкции DBCC CHECKDB без параметров может занять значительно больше времени, чем в предыдущих версиях. Это происходит по следующим причинам.

Выполняются более полные и исчерпывающие логические проверки.
Усложнился ряд базовых структур, нуждающихся в проверке.
Добавлены многие новые проверки для поддержки новых возможностей SQL Server 2005.

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

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

По умолчанию инструкция DBCC CHECKDB выполняет параллельную проверку объектов. Степень параллелизма определяется автоматически обработчиком запросов. Максимальная степень параллелизма настраивается так же, как и в параллельных запросах. Чтобы ограничить максимальное число процессоров, доступных для проверки DBCC, используется процедура sp_configure. Дополнительные сведения см. в разделе Параметр max degree of parallelism. Параллельная проверка может быть отключена с помощью флага трассировки 2528. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).

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

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

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

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

В SQL Server 2005 с пакетом обновления 1 (SP1) всякий раз при обнаружении командой DBCC CHECKDB ошибки повреждения данных в папке «LOG» SQL Server создается дамп файл (SQLDUMPnnnn.txt). Если для экземпляра SQL Server включены функции сбора данных об использовании компонентов и отчетов об ошибках, этот файл автоматически отправляется корпорации Майкрософт. Собранные данные используются для улучшения функциональности SQL Server. Дополнительные сведения см. в разделе Параметры отчетов об ошибках и использовании.

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

Разрешение ошибок

Если инструкция DBCC CHECKDB сообщает об ошибках, вместо выполнения REPAIR с каким-либо из параметров REPAIR рекомендуется восстановить базу данных из резервной копии. Если резервной копии базы данных не существует, выполнение параметра REPAIR приведет к исправлению обнаруженных ошибок. В конце списка ошибок указано, какой из параметров REPAIR следует использовать. Однако при исправлении ошибок с использованием параметра REPAIR_ALLOW_DATA_LOSS может потребоваться удаление некоторых страниц и некоторых данных.

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

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

Разрешение ошибок в аварийном режиме базы данных

Если база данных переведена в аварийный режим с помощью инструкции ALTER DATABASE, инструкция DBCC CHECKDB может выполнять некоторые специальные действия по восстановлению базы данных с указанным параметром REPAIR_ALLOW_DATA_LOSS. Эти действия по восстановлению могут позволить вывести обычно невосстановимые базы данных обратно в оперативный режим в физически согласованном состоянии. Эти действия должны использоваться только в исключительных случаях и только когда восстановление базы данных из резервной копии невозможно. Если база данных переведена в аварийный режим, она помечается как находящаяся в режиме READ_ONLY, ведение журнала отключается, а доступ разрешен лишь для членов фиксированной серверной роли sysadmin.

Примечание.
В аварийном режиме невозможно выполнить инструкцию DBCC CHECKDB в пользовательской транзакции и выполнить откат транзакции после выполнения.

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

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

Если инструкция DBCC CHECKDB выполнена успешно, значит, база данных находится в физически согласованном состоянии и переведена в режим ONLINE. Однако база данных может содержать одну или больше противоречивых транзакций. Рекомендуется выполнить инструкцию DBCC CHECKCONSTRAINTS, чтобы обнаружить дефекты бизнес-логики и незамедлительно создать резервную копию базы данных.

Если выполнение инструкции DBCC CHECKDB завершилось неудачей, база данных не может быть восстановлена.

Выполнение инструкции DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS для реплицируемых баз данных

Выполнение инструкции DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS может затронуть используемые репликацией пользовательские базы данных (базы данных подписок и публикаций) и базу данных распространителя. Базы данных подписки и публикации включают опубликованные таблицы и таблицы метаданных репликации. Учитывайте следующие возможные проблемы при работе с этими базами данных.

Опубликованные таблицы. Действия, выполненные процессом CHECKDB по восстановлению пользовательских данных, могут быть не реплицированы.
- При репликации слиянием используются триггеры, чтобы отследить изменения в опубликованных таблицах. Если процессом CHECKDB были вставлены, обновлены или удалены строки, триггеры не сработают; поэтому изменения не будут реплицированы.
- При репликации транзакций используется журнал транзакций, чтобы отследить изменения в опубликованных таблицах. Затем агент чтения журнала перемещает эти изменения в базу данных распространителя. Некоторые операции восстановления DBCC не могут быть реплицированы агентом чтения журнала, несмотря на то, что журналируются. Например, если страница данных освобождена процессом CHECKDB, агент чтения журнала не преобразует это действие в инструкцию DELETE; поэтому изменение не будет реплицировано.
Таблицы метаданных репликации. Действия, выполняемые процессом CHECKDB по восстановлению поврежденных таблиц метаданных репликации, требуют удаления и повторной настройки репликации.

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

Приостановите систему: остановите выполнение операций с базой данных и со всеми другими базами данных, которые участвуют в топологии репликации, а затем попытайтесь синхронизировать все узлы. Дополнительные сведения см. в разделе How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
Выполните инструкцию DBCC CHECKDB.
Если отчет инструкции DBCC CHECKDB включает действия по восстановлению каких-либо таблиц в базе данных распространителя или таблиц метаданных репликации в пользовательской базе данных, удалите и заново настройте репликацию. Дополнительные сведения см. в разделе Удаление репликации.
Если отчет инструкции DBCC CHECKDB включает действия по восстановлению каких-либо реплицируемых таблиц, выполните проверку данных, чтобы определить, имеются ли различия между данными в базах данных подписки и публикации. Дополнительные сведения см. в разделе Несовпадение данных на издателе и подписчике.

Разрешения

Необходимо членство в фиксированной серверной роли sysadmin или фиксированной роли базы данных db_owner.

Примеры

А. Проверка текущей базы данных и базы данных AdventureWorks

Следующий пример выполняет инструкцию DBCC CHECKDB для текущей базы данных и для базы данных AdventureWorks.

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks, NOINDEX);
GO

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

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

DBCC CHECKDB WITH NO_INFOMSGS;
GO

См. также

Журнал изменений

Версия	Журнал
17 ноября 2008 г.	Добавления В определении ALL_ERRORMSGS описаны новые функции в пакете обновления 3 (SP3).
12 декабря 2006 г.	Добавления В раздел «Примечания» добавлены сведения о том, что при выполнении команды DBCC CHECKDB очищается кэш планов.
17 июля 2006 г.	Добавления Добавлены сведения о том, как получить все сообщения об ошибках при задании параметра ALL_ERRORMSGS.
14 апреля 2006 г.	Добавления Добавлен раздел «Отчет об ошибках». В этом разделе описаны новые функциональные возможности пакета обновления 1(SP1). Добавлен раздел «Разрешение ошибок в аварийном режиме базы данных».
5 декабря 2005 г.	Добавления Добавлены сведения об ошибке 2537 для побайтно упорядоченных определяемых пользователем типов. Добавлен раздел «Выполнение инструкции DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS для реплицируемых баз данных». Добавлен раздел «Основные сведения о сообщениях об ошибках DBCC». Изменения Исправлен синтаксис. Исправлено определение аргумента REPAIR_FAST. Этот параметр не выполняет действий по восстановлению. Исправлено определение TABLOCK путем добавления операций, которые не выполняются, если указан этот параметр.