Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Область применения:
SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure
Проверяет логическую и физическую целостность всех объектов в указанной базе данных путем выполнения следующих операций.
Выполнение инструкции DBCC CHECKALLOC для базы данных.
Выполнение инструкции DBCC CHECKTABLE для каждой таблицы и каждого представления в базе данных.
Выполнение инструкции DBCC CHECKCATALOG для базы данных.
Проверка содержимого каждого индексированного представления в базе данных.
Проверка согласованности между файлами и директориями файловой системы и метаданными таблицы на уровне ссылок при хранении данных varbinary(max) в файловой системе с помощью FILESTREAM.
Проверяет данные Service Broker в базе данных.
Это означает, что DBCC CHECKALLOCDBCC CHECKTABLEкоманды или DBCC CHECKCATALOG команды не должны выполняться отдельно от DBCC CHECKDB. Дополнительные сведения о проверках, выполняемых этими командами, см. в описании данных команд.
DBCC CHECKDB поддерживается в базах данных, содержащих оптимизированные для памяти таблицы, но проверка выполняется только в таблицах на основе дисков. Однако в рамках резервного копирования и восстановления CHECKSUM базы данных проверка выполняется для файлов в файловых группах, оптимизированных для памяти.
Так как параметры восстановления DBCC недоступны для оптимизированных для памяти таблиц, необходимо регулярно создавать резервные копии баз данных и тестировать резервные копии. Если возникают проблемы целостности данных таблицы для памяти, необходимо восстановить ее из последней рабочей резервной копии.
Соглашения о синтаксисе Transact-SQL
Синтаксис
DBCC CHECKDB
[ [ ( database_name | database_id | 0
[ , NOINDEX
| , { 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 ]
}
]
]
Аргументы
| database_namedatabase_id | 0
Имя или идентификатор базы данных, для которой выполняются проверки целостности. Если значение не указано или указано значение 0, используется текущая база данных. Имена баз данных должны соответствовать правилам идентификаторов.
NOINDEX
Указывает, что интенсивные проверки некластеризованных индексов для пользовательских таблиц не выполняются. Выбор этого аргумента уменьшает общее время выполнения.
NOINDEX Не влияет на системные таблицы, так как проверки целостности всегда выполняются в системных индексах таблиц.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Указывает, что DBCC CHECKDB исправит обнаруженные ошибки. Используйте параметры REPAIR_* только в качестве последнего средства. Для применения описанных ниже параметров исправления указанная база данных должна находиться в однопользовательском режиме.
REPAIR_ALLOW_DATA_LOSSПытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Предупреждение
Этот
REPAIR_ALLOW_DATA_LOSSпараметр может привести к большей потере данных, чем при восстановлении из последней известной хорошей резервной копии. См. предупреждение об потере данных с помощью REPAIR_ALLOW_DATA_LOSSКорпорация Майкрософт всегда рекомендует пользователю восстановить последнюю известную хорошую резервную копию в качестве основного метода для восстановления от ошибок, сообщаемых
DBCC CHECKDB. ЭтотREPAIR_ALLOW_DATA_LOSSпараметр не является альтернативой для восстановления из известной хорошей резервной копии. Это вариант последней помощи , который рекомендуется использовать только в том случае, если восстановление из резервной копии невозможно.Некоторые ошибки, которые могут быть исправлены только с помощью
REPAIR_ALLOW_DATA_LOSSпараметра, могут привести к освобождению строки, страницы или ряда страниц для очистки ошибок. Любые освобожденные данные больше не доступны или восстанавливаются для пользователя, а точное содержимое освобожденных данных не может быть определено. Таким образом, целостность ссылок может не быть точной после того, как какие-либо строки или страницы освобождены, так как ограничения внешнего ключа не проверяются или поддерживаются в рамках этой операции восстановления. Пользователь должен проверить целостность базы данных (с помощьюDBCC CHECKCONSTRAINTS) после использованияREPAIR_ALLOW_DATA_LOSSпараметра.Перед выполнением восстановления необходимо создать физические копии файлов, принадлежащих этой базе данных. К ним относятся основной файл данных (
.mdf), все вторичные файлы данных (), все файлы журнала транзакций (.ndf.ldf) и другие контейнеры, которые формируют базу данных, включая полнотекстовые каталоги, папки файлового потока, оптимизированные для памяти данные и т. д.Прежде чем выполнить восстановление, попробуйте изменить состояние базы данных в
EMERGENCYрежим и попытаться извлечь столько информации из критически важных таблиц и сохранить эти данные.REPAIR_FASTСинтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.
REPAIR_REBUILDВыполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Этот параметр может включать быстрый ремонт, например восстановление отсутствующих строк в некластеризованных индексах, а также более длительный ремонт, например перестроение индекса.
Этот аргумент не исправляет ошибки, связанные с данными FILESTREAM.
Внимание
Так как DBCC CHECKDB при использовании любого из REPAIR_* параметров полностью регистрируются и восстанавливаются, корпорация Майкрософт всегда рекомендует пользователю использовать DBCC CHECKDB любые REPAIR_* параметры в транзакции (выполнение BEGIN TRANSACTION перед выполнением команды), чтобы пользователь смог подтвердить, что они хотят принять результаты операции. Затем пользователь может выполнить COMMIT TRANSACTION фиксацию всех работ, выполненных операцией восстановления. Если пользователь не хочет принимать результаты операции, он может выполнить ROLLBACK TRANSACTION отмену последствий операций восстановления.
Для устранения ошибок рекомендуется восстановление из резервной копии. Операции восстановления не учитывают какие-либо ограничения, которые могут существовать в таблицах или между ними. Если указанная таблица включена в одно или несколько ограничений, рекомендуется выполнить инструкцию DBCC CHECKCONSTRAINTS после операции восстановления. Если необходимо использовать REPAIR_*, запустите DBCC CHECKDB без параметра восстановления, чтобы найти используемый уровень восстановления. Если вы используете REPAIR_ALLOW_DATA_LOSS уровень, рекомендуется создать резервную копию базы данных перед выполнением DBCC CHECKDB этого параметра.
ALL_ERRORMSGS
Отображает все сформированные для объекта ошибки. Все сообщения об ошибках выводятся по умолчанию. Указание или пропуск этого параметра не приводит к изменениям. Сообщения об ошибках, за исключением сообщений, формируемых базой данных tempdb, сортируются по идентификатору объекта.
EXTENDED_LOGICAL_CHECKS
Если уровень совместимости равен 100, представлен в SQL Server 2008 (10.0.x), этот параметр выполняет логические проверки согласованности для индексированного представления, XML-индексов и пространственных индексов, где присутствует.
Дополнительные сведения см. в разделе "Выполнение логических проверок согласованности индексов " далее в этой статье.
NO_INFOMSGS
Подавляет вывод всех информационных сообщений.
TABLOCK
Причины DBCC CHECKDB получения блокировок вместо использования внутреннего моментального снимка базы данных. Это включает краткосрочное использование монопольной блокировки (X) на базу данных.
TABLOCK приводит DBCC CHECKDB к более быстрому выполнению базы данных под тяжелой нагрузкой, но уменьшает параллелизм, доступный в базе данных во время DBCC CHECKDB выполнения.
Внимание
TABLOCK ограничивает выполняемые проверки; DBCC CHECKCATALOG не выполняется в базе данных, а данные Service Broker не проверяются.
ESTIMATEONLY
Отображает предполагаемое tempdb количество места, которое требуется для выполнения DBCC CHECKDB со всеми другими указанными параметрами. Фактическая проверка базы данных не выполняется.
PHYSICAL_ONLY
Ограничивает проверку лишь проверкой целостности физической структуры страниц и заголовков записей и целостности выделения пространства в базе данных. Эта проверка служит для выполнения проверки физической согласованности базы данных с низкими накладными расходами на выполнение. Она может обнаруживать обрывы страниц, ошибки контрольной суммы и типичные сбои оборудования, которые могут привести к повреждению пользовательских данных.
Полное выполнение DBCC CHECKDB может занять значительно больше времени, чем предыдущие версии. Это происходит по следующим причинам.
- Логические проверки стали более сложными.
- Усложнился ряд базовых структур, нуждающихся в проверке.
- Добавлено много новых проверок для поддержки новых функций.
Поэтому использование PHYSICAL_ONLY параметра может привести к гораздо более короткому времени выполнения для DBCC CHECKDB больших баз данных и рекомендуется для частого использования в рабочих системах. Мы по-прежнему рекомендуем периодически выполнять полный DBCC CHECKDB запуск. Периодичность запуска зависит от факторов, индивидуальных для каждого предприятия и каждой производственной среды.
Этот аргумент всегда подразумевает NO_INFOMSGS и не допускается с одним из вариантов восстановления.
Предупреждение
Указание PHYSICAL_ONLY причин DBCC CHECKDB пропуска всех проверок данных FILESTREAM.
DATA_PURITY
Приводит DBCC CHECKDB к проверке базы данных для значений столбцов, которые не являются допустимыми или устаревшими. Например, DBCC CHECKDB обнаруживает столбцы со значениями даты и времени, которые больше или меньше допустимого диапазона для типа данных datetime ; или столбцы типа данных десятичного или приблизительного числа с недопустимыми значениями масштабирования или точности.
Проверки целостности столбцов включены по умолчанию и не требуют этого DATA_PURITY параметра. Для баз данных, обновленных с более ранних версий SQL Server, проверки значений столбцов по умолчанию не включены до тех пор, пока DBCC CHECKDB WITH DATA_PURITY не будет запущена ошибка в базе данных. После этого инструкция DBCC CHECKDB проверяет целостность данных в столбцах по умолчанию. Дополнительные сведения о том, как CHECKDB может повлиять обновление базы данных из более ранних версий SQL Server, см. в разделе "Примечания" далее в этой статье.
Предупреждение
Если PHYSICAL_ONLY задано, проверки целостности столбцов не выполняются.
Ошибки проверки, сообщаемые этим параметром, не могут быть исправлены с помощью параметров восстановления DBCC. Сведения об исправлении этих ошибок вручную см. в MSSQLSERVER_2570.
MAXDOP
Область применения: SQL Server 2014 (12.x) с пакетом обновления 2 и более поздними версиями
Переопределяет max degree of parallelism параметр конфигурации инструкции sp_configure . Значение MAXDOP может превышать значение, настроенное с sp_configureпомощью . Если MAXDOP превышено значение, настроенное с помощью регулятора ресурсов, sql Server ядро СУБД использует значение регулятора MAXDOP ресурсов, описанное в инструкции ALTER WORKLOAD GROUP. Все семантические правила, используемые с параметром max degree of parallelismMAXDOP конфигурации, применимы при использовании указания запроса. Дополнительные сведения см. в разделе Конфигурация сервера: максимальная степень параллелизма.
Предупреждение
Если MAXDOP задано значение нулю, SQL Server выбирает используемый max degree of parallelism объект.
Замечания
DBCC CHECKDB не проверяет отключенные индексы. Дополнительные сведения об отключенных индексах см. в разделе "Отключение индексов и ограничений".
Если определяемый пользователем тип помечен как упорядоченный по байтам, должна быть выполнена только одна сериализация определяемого пользователем типа. Несоотчетная сериализация определяемых пользователем типов байтов приводит к ошибке 2537 при DBCC CHECKDB запуске. Дополнительные сведения см. в разделе "Создание типов User-Defined — требования".
Так как база данных ресурсов изменяется только в однопользовательском режиме, DBCC CHECKDB команда не может выполняться напрямую. Однако при DBCC CHECKDB выполнении базы данных master секунда CHECKDB также выполняется внутри базы данных ресурсов. Это означает, что DBCC CHECKDB может возвращать дополнительные результаты. Эта команда возвращает дополнительные результирующие наборы, если параметры не указаны или указан один из параметров PHYSICAL_ONLY либо ESTIMATEONLY.
В SQL Server 2005 (9.x) с пакетом обновления 2 и более поздних версий выполнение DBCC CHECKDB больше не очищает кэш планов для экземпляра SQL Server. Перед SQL Server 2005 (9.x) с пакетом обновления 2 (SP2) выполняет DBCC CHECKDB очистку кэша планов. Очистка кэша планов приводит к повторной компиляции всех последующих планов выполнения и может привести к внезапному снижению производительности запросов.
Выполнение проверок логической согласованности индексов
Процедура проверки логической целостности индексов зависит от уровня совместимости базы данных следующим образом.
Если уровень совместимости не менее 100 (представлен в SQL Server 2008 (10.0.x)):
Если не
NOINDEXуказано, выполняет как физические,DBCC CHECKDBтак и логические проверки согласованности для одной таблицы и всех некластеризованных индексов. Однако в XML-индексах, пространственных индексах и индексированных представлениях по умолчанию выполняются только проверки физической целостности.Если указан параметр
WITH EXTENDED_LOGICAL_CHECKS, выполняются проверки логической согласованности в индексированном представлении, XML-индексах и пространственных индексах (при их наличии). По умолчанию проверки физической согласованности выполняются раньше, чем проверки логической согласованности. Если также указан параметрNOINDEX, выполняются только проверки логической согласованности.
Эти проверки логической согласованности проверяют внутреннюю таблицу индекса объекта индекса с помощью пользовательской таблицы, на которую он ссылается. Для поиска выбросов создается внутренний запрос, выполняющий полную проверку пересечения внутренних и пользовательских таблиц. Выполнение этого запроса может существенно повлиять на производительность, и его ход выполнения не может быть отслеживаем. Поэтому рекомендуется указывать параметр WITH EXTENDED_LOGICAL_CHECKS только в тех случаях, когда возможно возникновение проблем с индексированием, не связанных с физическими повреждениями, или при неверных контрольных суммах на уровне страниц, либо же при подозрении на повреждение оборудования на уровне столбцов.
Если индекс является отфильтрованным индексом, выполняет проверки согласованности, чтобы убедиться,
DBCC CHECKDBчто записи индекса удовлетворяют предикату фильтра.Если уровень совместимости равен 90 или меньше, если
NOINDEXон не указан,DBCC CHECKDBвыполняет проверки физической и логической согласованности для одной таблицы или индексированного представления и всех некластеризованных и XML-индексов. Пространственные индексы не поддерживаются.В SQL Server 2016 (13.x) и более поздних версиях дополнительные проверки на сохраненные вычисляемые столбцы, столбцы определяемого пользователем типа и отфильтрованные индексы по умолчанию не выполняются, чтобы избежать дорогостоящих вычислений выражений. Это изменение значительно сокращает продолжительность
CHECKDBбаз данных, содержащих эти объекты. Однако проверка физической согласованности этих объектов проводится всегда. Только приEXTENDED_LOGICAL_CHECKSуказании параметра выполняются вычисления выражений в дополнение к логическим проверкам, которые уже присутствуют в качестве частиEXTENDED_LOGICAL_CHECKSпараметра (индексированного представления, XML-индексов и пространственных индексов).
Сведения о уровне совместимости базы данных
Внутренний моментальный снимок базы данных
DBCC CHECKDB использует внутренний моментальный снимок базы данных для согласованности транзакций, необходимых для выполнения этих проверок. Тем самым предотвращаются проблемы блокировки и параллелизма при выполнении этих команд. Дополнительные сведения см. в разделе "Размер разреженного файла моментального снимка базы данных " и раздела об использовании внутреннего моментального снимка базы данных DBCC в DBCC. Если моментальный снимок не может быть создан или TABLOCK указан, DBCC CHECKDB получает блокировки для получения требуемой согласованности. В таком случае для проверки выделенных ресурсов необходима монопольная блокировка базы данных, а для проверки таблиц — разделяемая блокировка таблицы.
DBCC CHECKDB Завершается сбоем master при запуске базы данных, если не удается создать внутренний моментальный снимок базы данных.
Выполнение DBCC CHECKDB не tempdb выполняет никаких проверок выделения или каталога и должно получать блокировки общих таблиц для выполнения проверок таблиц. Это связано с тем, что по соображениям производительности моментальные снимки базы данных недоступны tempdb. Это означает, что требуемая согласованность транзакций не может быть получена.
Как DBCC CHECKDB создает базу данных внутренних моментальных снимков в SQL Server 2014 и более поздних версий
DBCC CHECKDBсоздает внутреннюю базу данных моментальных снимков.База данных внутренних моментальных снимков создается с помощью физических файлов. Например, для базы данных с
database_id = 10тремя файламиE:\Data\my_DB.mdfE:\Data\my_DB.ndfиE:\Data\my_DB.ldfвнутренними базами данных моментальных снимков создается с помощьюE:\Data\my_DB.mdf_MSSQL_DBCC11иE:\Data\my_DB.ndf_MSSQL_DBCC11файлами. Моментальныйdatabase_idснимок .database_id + 1Кроме того, обратите внимание, что новые файлы создаются в той же папке с помощью соглашения<filename.extension>_MSSQL_DBCC<database_id_of_snapshot>об именовании. Для журнала транзакций разреженный файл не создается.Новые файлы помечаются как разреженные на уровне файловой системы. Размер диска, используемого новыми файлами, увеличивается на основе того, сколько данных обновляется в исходной базе данных во время
DBCC CHECKDBкоманды. Размер новых файлов совпадает с файлом или.mdfфайлом.ndf.Новые файлы удаляются в конце
DBCC CHECKDBобработки. Эти разреженные файлы, созданные с помощьюDBCC CHECKDBнабора атрибутов Delete on Close.
Предупреждение
Если операционная система обнаруживает непредвиденное завершение работы во время DBCC CHECKDB выполнения команды, эти файлы не удаляются. Они занимают место и могут привести к сбоям в будущих DBCC CHECKDB выполнениях. В этом случае эти новые файлы можно удалить после подтверждения того, что DBCC CHECKDB в настоящее время не выполняется команда.
Новые файлы можно просмотреть с помощью обычных служебных программ для работы с файлами, таких как проводник.
Примечание.
До SQL Server 2014 (12.x) вместо этого использовались именованные потоки файлов для создания внутренних файлов моментальных снимков. Именованные потоки файлов использовали формат filename.extension<>:MSSQL_DBCC<database_id_of_snapshot>. Именованные потоки файлов не отображаются с помощью обычных служебных программ файлов, таких как проводник Windows. Поэтому в SQL Server 2012 (11.x) и более ранних версиях могут возникнуть сообщения об ошибках 7926 и 5030 при выполнении DBCC CHECKDB команды для файлов базы данных, расположенных в томе с форматированием ReFS. Это связано с тем, что потоки файлов нельзя создавать в отказоустойчивой файловой системе (RefS).
Проверка и восстановление данных FILESTREAM
Если для базы данных и таблицы включен режим FILESTREAM, то существует возможность хранения больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе. При использовании базы данных, в которой хранятся DBCC CHECKDB БОЛЬШИЕ двоичные объекты в файловой системе, DBCC проверяет согласованность на уровне ссылок между файловой системой и базой данных.
Например, если таблица содержит столбец varbinary(max), использующий атрибут FILESTREAM, проверяет, DBCC CHECKDB существует ли сопоставление между каталогами файловой системы и файлами и строками таблиц, столбцами и значениями столбцов.
DBCC CHECKDB Может исправить повреждение, если указать REPAIR_ALLOW_DATA_LOSS этот параметр. Чтобы восстановить повреждение FILESTREAM, DBCC удаляет все строки таблицы, отсутствующие данные файловой системы.
Рекомендации
При частом использовании в системах в рабочей среде рекомендуется указывать параметр PHYSICAL_ONLY. Использование PHYSICAL_ONLY может значительно сократить время выполнения для DBCC CHECKDB больших баз данных. Мы также рекомендуем периодически запускать без DBCC CHECKDB параметров. Насколько часто необходимо это делать, зависит от факторов, индивидуальных для каждого предприятия и каждой рабочей среды.
В Управляемый экземпляр SQL Azure доступное хранилище должно содержать весь файл моментального снимка внутренней базы данных, созданный DBCC CHECKDBнезависимо от того, сколько из него фактически используется данными. Это может привести к сбою выполнения DBCC CHECKDB в очень большой, но разреженной базе данных (размер данных гораздо меньше размера файла базы данных) из-за нехватки места в управляемом экземпляре SQL. Если DBCC CHECKDB во время выполнения используется все доступное дисковое пространство, вы получите следующее сообщение об ошибке:
Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.
Параллельное проверка объектов
По умолчанию DBCC CHECKDB выполняется параллельная проверка объектов. Степень параллелизма определяется автоматически обработчиком запросов. Максимальная степень параллелизма настраивается так же, как и в параллельных запросах. Чтобы ограничить максимальное число процессоров, доступных для проверки DBCC, используйте процедуру sp_configure. Дополнительные сведения см. в разделе Конфигурация сервера: максимальная степень параллелизма. Параллельная проверка может быть отключена с помощью флага трассировки 2528. Дополнительные сведения см. в разделе "Настройка флагов трассировки с помощью DBCC TRACEON".
Примечание.
Эта функция недоступна в каждом выпуске SQL Server. Дополнительные сведения см. в разделе проверки согласованности параллельной согласованности в разделе управляемости RDBMS в выпусках и поддерживаемых функциях SQL Server 2022.
Общие сведения об ошибках DBCC
DBCC CHECKDB После завершения команды сообщение записывается в журнал ошибок SQL Server. Если команда DBCC выполнена успешно, сообщение указывает на успешное завершение и содержит время, в течение которого выполнялась команда. Если команда DBCC была остановлена из-за ошибки до завершения проверки, сообщение указывает на прекращение выполнения команды и содержит значение состояния и время, в течение которого выполнялась команда. В следующей таблице перечислены и описаны значения состояний, которые могут быть включены в сообщение.
| State | Описание: |
|---|---|
0 |
Возникла ошибка с номером 8930. Указывает на повреждение в метаданных, приведшее к завершению команды DBCC. |
1 |
Возникла ошибка с номером 8967. Внутренняя ошибка DBCC. |
2 |
При аварийном восстановлении базы данных произошла ошибка. |
3 |
Указывает на повреждение в метаданных, приведшее к завершению команды DBCC. |
4 |
Обнаружено нарушение доступа или утверждения. |
5 |
Возникла неизвестная ошибка, которая привела к прекращению выполнения команды DBCC. |
SQL Server записывает дату и время выполнения проверки согласованности для базы данных без ошибок (или "очистки" проверки согласованности). Это называется last known clean check. При первом запуске базы данных эта дата записывается в EventLog (EventID-17573) и журнал ошибок в следующем формате:
CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.
Отчеты об ошибках
Дамп стека (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) создается в каталоге SQL Server LOG при обнаружении DBCC CHECKDB ошибки повреждения.
Если для экземпляра SQL Server включены сбор данных об использовании компонентов и функции отчетов об ошибках, файл автоматически перенаправляются в корпорацию Майкрософт. Собранные данные используются для улучшения функциональности SQL Server.
Файл дампа содержит результаты DBCC CHECKDB команды и дополнительные диагностические выходные данные. Доступ ограничен учетной записью службы SQL Server и членами роли sysadmin. По умолчанию роль sysadmin содержит всех членов группы Windows BUILTIN\Administrators и группы локальных администраторов. Команда DBCC не завершается ошибкой, если процесс сбора данных завершается сбоем.
Устранение ошибок
Если сообщается DBCC CHECKDBоб ошибках, рекомендуется восстановить базу данных из резервной копии базы данных, а не использовать DBCC CHECKDB один из REPAIR_* вариантов. Если резервной копии базы данных не существует, выполнение параметра REPAIR приведет к исправлению обнаруженных ошибок. В конце списка ошибок указано, какой из параметров REPAIR следует использовать. Однако исправление ошибок с помощью REPAIR_ALLOW_DATA_LOSS параметра может потребовать удаления некоторых страниц и, следовательно, некоторых данных.
В некоторых случаях значения могут быть введены в базу данных, которая не является допустимой или вне диапазона на основе типа данных столбца.
DBCC CHECKDB может обнаружить значения столбцов, недопустимые для всех типов данных столбцов. Таким образом, при выполнении DBCC CHECKDB параметра DATA_PURITY для баз данных, которые были обновлены с более ранних версий SQL Server, могут возникнуть ошибки с значением столбца. Так как SQL Server не может автоматически исправить эти ошибки, значение столбца должно быть обновлено вручную. Если CHECKDB обнаруживает такую ошибку, возвращает предупреждение, 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пытается восстановить базу данных с помощью обычных методов восстановления на основе журналов.Если восстановление базы данных завершается неудачно из-за повреждения журнала транзакций, то журнал транзакций перестроен. Перестроение журнала транзакций может привести к потере согласованности транзакций.
Предупреждение
Этот REPAIR_ALLOW_DATA_LOSS параметр может привести к большей потере данных, чем при восстановлении из последней известной хорошей резервной копии. См. предупреждение об потере данных с помощью REPAIR_ALLOW_DATA_LOSS
DBCC CHECKDB Если команда выполнена успешно, база данных находится в физическом состоянии, а состояние базы данных — ONLINE. Однако база данных может содержать одно или несколько несоответствий транзакций. Рекомендуется выполнить инструкцию DBCC CHECKCONSTRAINTS, чтобы обнаружить дефекты бизнес-логики и незамедлительно создать резервную копию базы данных.
DBCC CHECKDB Если команда завершается ошибкой, невозможно восстановить базу данных.
Предупреждение об потере данных с REPAIR_ALLOW_DATA_LOSS
Этот REPAIR_ALLOW_DATA_LOSS параметр является поддерживаемой функцией SQL Server. Однако это не всегда может быть лучшим вариантом для подключения базы данных к физическому согласованному состоянию. При успешном выполнении REPAIR_ALLOW_DATA_LOSS этот параметр может привести к потере данных.
На самом деле это может привести к тому, что больше данных потеряно, чем если пользователь будет восстанавливать базу данных из последней известной хорошей резервной копии. Корпорация Майкрософт всегда рекомендует пользователю восстановить последнюю известную хорошую резервную копию в качестве основного метода для восстановления от ошибок, сообщаемых DBCC CHECKDB.
Этот REPAIR_ALLOW_DATA_LOSS параметр не является альтернативой для восстановления из известной хорошей резервной копии. Это вариант последней помощи , который рекомендуется использовать только в том случае, если восстановление из резервной копии невозможно .
После перестроения журнала нет полной гарантии ACID.
После перестроения журнала 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 параметром в пользовательской базе данных или базе данных распространителя:
Приостановите систему: остановите выполнение операций с базой данных и со всеми другими базами данных, которые участвуют в топологии репликации, а затем попытайтесь синхронизировать все узлы. Дополнительные сведения см. в статье Заморозить топологию репликации (программирование репликации на языке Transact-SQL).
Выполните процедуру
DBCC CHECKDB.DBCC CHECKDBЕсли отчет включает восстановление для любых таблиц в базе данных распространителя или любых таблиц метаданных репликации в пользовательской базе данных, удалите и перенастроите репликацию. Дополнительные сведения см. в статье Отключение публикации и распространения.DBCC CHECKDBЕсли отчет включает восстановление для любой реплицированной таблицы, выполните проверку данных, чтобы определить, существуют ли различия между данными в базах данных публикации и подписки.
Результирующий набор
DBCC CHECKDB возвращает следующий результирующий набор. Значения могут отличаться, за исключением указанных ESTIMATEONLYPHYSICAL_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.
Разрешения
Необходимо быть членом предопределенной роли сервера sysadmin или предопределенной роли базы данных db_owner .
Примеры
А. Проверка текущей и другой базы данных
В следующем примере выполняется инструкция DBCC CHECKDB для текущей базы данных и для базы данных AdventureWorks2025.
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO
B. Проверка текущей базы данных, подавление информационных сообщений
Следующий пример проверяет текущую базу данных и подавляет все информационные сообщения.
DBCC CHECKDB WITH NO_INFOMSGS;
GO