DBCC CHECKDB (Transact-SQL)

Мақала
04/26/2023

Применимо к:База данных SQL Server Azure SQL Управляемый экземпляр SQL Azure

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

Выполнение инструкции DBCC CHECKALLOC для базы данных.
Выполнение инструкции DBCC CHECKTABLE для каждой таблицы и каждого представления в базе данных.
Выполнение инструкции DBCC CHECKCATALOG для базы данных.
Проверка содержимого каждого индексированного представления в базе данных.
Проверка согласованности между файлами и директориями файловой системы и метаданными таблицы на уровне ссылок при хранении данных varbinary(max) в файловой системе с помощью FILESTREAM.
Проверка данных компонента Компонент Service Broker в базе данных.

Это означает, что DBCC CHECKALLOCкоманды , DBCC 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 ]
        }
    ]
]

Примечание

Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.

Аргументы

database_name | database_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 получения блокировок вместо использования внутренней базы данных snapshot. Это включает краткосрочное использование монопольной блокировки (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. Дополнительные сведения об устранении этих ошибок вручную см. в статье 923247 базы знаний Майкрософт: Устранение ошибки DBCC 2570 в SQL Server 2005 и более поздних версиях.

MAXDOP

Применимо к: SQL Server 2014 (12.x) с пакетом обновления 2 (SP2) и более поздних версий

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

Предупреждение

Если MAXDOP задано нулевое значение, SQL Server выбирает максимальную степень параллелизма для использования.

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

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

Начиная с SQL Server 2005 (9.x) с пакетом DBCC CHECKDB обновления 2 (SP2), выполнение больше не очищает кэш планов для экземпляра SQL Server. До SQL Server 2005 (9.x) с пакетом обновления 2 при выполнении 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-индексы и пространственные индексы).

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

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

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

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

DBCC CHECKDBПроисходит сбой при выполнении master в базе данных, если не удается создать внутреннюю базу данных snapshot.

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

Как DBCC CHECKDB создает базу данных внутренних моментальных снимков в SQL Server 2014 и более поздних версий

DBCC CHECKDBсоздает внутреннюю базу данных snapshot.
База данных внутренних моментальных снимков создается с помощью физических файлов. Например, для базы данных с тремя файлами , и , внутренняя база данных snapshot будет создана с помощью E:\Data\my_DB.mdf_MSSQL_DBCC11 файлов и E:\Data\my_DB.ndf_MSSQL_DBCC11 .E:\Data\my_DB.ldfE:\Data\my_DB.ndfdatabase_id = 10E:\Data\my_DB.mdf Объект database_id snapshot имеет значение database_id + 1. Также обратите внимание, что новые файлы создаются в той же папке с помощью соглашения <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>об именовании . Для журнала транзакций разреженный файл не создается.
Новые файлы помечаются как разреженные на уровне файловой системы. Размер на диске, используемый новыми файлами, будет увеличиваться в зависимости от объема данных, обновляемых в базе данных-источнике DBCC CHECKDB во время выполнения команды. Размер новых файлов будет таким же, как и .mdf в файле или .ndf .
Новые файлы удаляются в конце DBCC CHECKDB обработки. Для этих разреженных файлов, созданных с помощью DBCC CHECKDB , заданы атрибуты "Удалить при закрытии".

Предупреждение

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

Новые файлы можно просмотреть с помощью обычных служебных программ для работы с файлами, таких как проводник.

Примечание

До SQL Server 2014 г. (12.x) именованные потоки файлов использовались вместо этого для создания внутренних файлов snapshot. Именованные потоки файлов используют формат <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Именованные файловые потоки нельзя просмотреть с помощью обычных служебных программ для работы с файлами, таких как проводник. Поэтому в SQL Server 2012 (11.x) и более ранних версиях при выполнении DBCC CHECKDB команды для файлов базы данных, расположенных на томе с форматом ReFS, могут возникать сообщения об ошибках 7926 и 5030. Это обусловлено тем, что потоки файлов нельзя создать в Resilient File System (RefS).

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

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

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

Параллельная проверка объектов

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

Примечание

Эта функция поддерживается не во всех выпусках SQL Server. Дополнительные сведения см. в разделе Параллельная согласованность проверка в разделе Управляемость RDBMS статьи Выпуски и поддерживаемые функции SQL Server 2022.

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

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

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

Примечание

SQL Server записывает дату и время выполнения не обнаружившей ошибок проверки согласованности для базы данных (она же «чистая» проверка согласованности). Это называется last known clean check. При первом запуске базы данных эта дата записывается в Журнал событий (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) создается в каталоге SQL Server LOG при каждом DBCC CHECKDB обнаружении ошибки повреждения. Если для экземпляра SQL Server включены функции сбора данных об использовании компонентов и отчетов об ошибках, этот файл автоматически отправляется в корпорацию Microsoft. Собранные данные используются для улучшения функциональности SQL Server. Файл дампа содержит результаты команды и дополнительные выходные DBCC CHECKDB данные диагностики. Доступ ограничен учетной записью службы SQL Server и членами роли sysadmin. По умолчанию роль sysadmin содержит всех членов группы Windows BUILTIN\Administrators и группы локальных администраторов. Команда DBCC не завершается ошибкой, если процесс сбора данных завершается сбоем.

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

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

После перестроения журнала не гарантируется полное соблюдение принципа ACID.

После перестроения журнала будет выполнено автоматически и 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 для пользовательской базы данных или базы данных распространителя:

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

Наборы результатов

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.

Разрешения

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

Примеры

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

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

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

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

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

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Бөлісу құралы:

DBCC CHECKDB (Transact-SQL)

Синтаксис

Аргументы

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Комментарии

Выполнение проверок логической согласованности для индексов

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

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

Как DBCC CHECKDB создает базу данных внутренних моментальных снимков в SQL Server 2014 и более поздних версий

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

Рекомендации

Параллельная проверка объектов

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

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

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

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

Запуск DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS в реплицированных базах данных

Наборы результатов

Разрешения

Примеры

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

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

См. также

Кері байланыс

Қосымша ресурстар