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

• При уровне совместимости 100 (SQL Server 2008) и выше.
  
  • Если не указан параметр NOINDEX, инструкция DBCC CHECKDB выполняет как физические, так и логические проверки целостности отдельной таблицы и всех ее некластеризованных индексов. Однако в XML-индексах, пространственных индексах и индексированных представлениях по умолчанию выполняются только проверки физической согласованности.
    
  • Если указан параметр WITH EXTENDED_LOGICAL_CHECKS, выполняются логические проверки в индексированных представлениях, XML-индексах и пространственных индексах (при их наличии). По умолчанию проверки физической согласованности выполняются раньше, чем проверки логической согласованности. Если также указан параметр NOINDEX, выполняются только проверки логической согласованности.
    Они проверяют согласованность внутренней индексированной таблицы или объекта индекса с пользовательской таблицей, на которую он указывает. Для поиска выбросов создается внутренний запрос, выполняющий полную проверку пересечения внутренних и пользовательских таблиц. Выполнение этого запроса может крайне отрицательно сказаться на производительности, а ход его выполнения невозможно отследить. Поэтому рекомендуется указывать параметр WITH EXTENDED_LOGICAL_CHECKS только в тех случаях, когда возможно возникновение проблем с индексированием, не связанных с физическими повреждениями, или при неверных контрольных суммах на уровне страниц, либо при подозрении на повреждение оборудовании на уровне столбцов.
    
  • Если это отфильтрованный индекс, DBCC CHECKDB выполняет проверку согласованности, чтобы убедиться, что записи индекса удовлетворяют условию предиката фильтра.
    
• Если уровень совместимости меньше либо равен 90 и не указан параметр NOINDEX, инструкция DBCC CHECKDB выполняет как физические, так и логические проверки целостности отдельной таблицы или индексированного представления и всех его некластеризованных и XML-индексов. Пространственные индексы не поддерживаются.
  

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

• Как просмотреть или изменить уровень совместимости базы данных (SQL Server Management Studio)
  

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

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

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

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

Например, если столбец таблицы типа varbinary(max) использует атрибут FILESTREAM, инструкция DBCC CHECKDB проверит, что файлы и каталоги файловой системы находятся в сопоставлении «один к одному» со столбцами, строками и значениями строк таблицы. Инструкция DBCC CHECKDB может исправить повреждения при указании параметра REPAIR_ALLOW_DATA_LOSS. При восстановлении повреждений FILESTREAM инструкция DBCC удаляет все строки таблиц, в которых отсутствуют данные файловой системы, а также все каталоги и файлы, которые не сопоставлены строкам, столбцам и значениям столбцов в таблицах.

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

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

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

Всякий раз при обнаружении командной инструкцией DBCC CHECKDB ошибки повреждения данных в каталоге SQL Server LOG создается файл дампа (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 не может автоматически исправить эти ошибки, значения в столбцах необходимо обновить вручную. Если инструкция 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 может затронуть используемые репликацией пользовательские базы данных (базы данных подписок и публикаций) и базу данных распространителя. Базы данных подписки и публикации включают опубликованные таблицы и таблицы метаданных репликации. Учитывайте следующие возможные проблемы при работе с этими базами данных.

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

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

1. Приостановите систему: остановите выполнение операций с базой данных и со всеми другими базами данных, которые участвуют в топологии репликации, а затем попытайтесь синхронизировать все узлы. Дополнительные сведения см. в разделе Как заморозить топологию репликации (программирование репликации на языке Transact-SQL).
   
2. Выполните инструкцию DBCC CHECKDB.
   
3. Если отчет инструкции DBCC CHECKDB включает действия по восстановлению каких-либо таблиц в базе данных распространителя или таблиц метаданных репликации в пользовательской базе данных, удалите и заново настройте репликацию. Дополнительные сведения см. в разделе Удаление репликации.
   
4. Если отчет инструкции DBCC CHECKDB включает действия по восстановлению каких-либо реплицируемых таблиц, выполните проверку данных, чтобы определить, имеются ли различия между данными в базах данных подписки и публикации. Дополнительные сведения см. в разделе Несовпадение данных на издателе и подписчике.
   

Следующий пример выполняет инструкцию 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