Устранение ошибок с согласованностью базы данных, обнаруженных командой DBCC CHECKDB

  • Статья

В этой статье объясняется, как устранять ошибки, сообщаемые командой DBCC CHECKDB .

Исходная версия продукта: SQL Server
Исходный номер базы знаний: 2015748

Симптомы

При выполнении DBCC CHECKDB (или других аналогичных команд, таких как DBCC CHECKTABLE), сообщение, например следующее, записывается в журнал ошибок SQL Server:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

В этом сообщении показано, сколько ошибок согласованности базы данных было найдено и сколько исправлено, если использовался параметр восстановления. Это сообщение также записывается в журнал событий приложения Windows в виде сообщения уровня информации с EventID=8957. Даже если сообщается об ошибках, это сообщение является сообщением уровня информации.

Сведения в сообщении, начиная с "внутреннего моментального снимка базы данных..." Отображается только в том случае, если DBCC CHECKDB он запущен в сети, в котором база данных не в режиме SINGLE_USER . Это связано с тем, что для сетевого DBCC CHECKDBснимка базы данных используется для представления согласованного набора данных для проверки.

В этой статье не рассматриваются способы устранения каждой конкретной ошибки, сообщаемой DBCC CHECKDB , а общий подход при обнаружении ошибок. Любая ссылка на CHECKDB эту статью также относится к DBCC CHECKTABLE DBCC CHECKFILEGROUP, если не указано.

Причина

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

Причина этих проблем может быть связана с повреждением файловой системы, проблемами системы оборудования, проблемами драйвера, поврежденными страницами в памяти или кэше хранилища или проблемами с SQL Server. Сведения о том, как определить первопричину сообщаемых ошибок, см. в статье "Исследование первопричины".

Разрешение

  1. Устраните все базовые проблемы, связанные с оборудованием в системе, прежде чем продолжить восстановление резервной копии или восстановление базы данных. Примените любые обновления драйвера устройства, встроенного ПО, BIOS и операционной системы, относящиеся к пути ввода-вывода. Обратитесь к администратору полного пути ввода-вывода (локальный компьютер, драйверы устройств, сетевые адаптеры хранилища, SAN, серверное хранилище и кэш), чтобы изолировать и устранить любые проблемы. Примеры включают обновление драйверов устройств и проверку конфигурации всего пути ввода-вывода. Дополнительные сведения о проверке первопричины см. в статье "Исследование первопричины".

  2. Если DBCC CHECKDB сообщает об ошибках постоянной согласованности, лучше всего будет восстановить данные из известной хорошей резервной копии. Дополнительные сведения см. в разделе "Восстановление и восстановление".

  3. Примените последнюю версию накопительного обновления SQL Server или пакет обновления, чтобы убедиться, что вы не работаете с известными проблемами. Ознакомьтесь с документацией по накопительным обновлениям или пакету обновления для всех известных проблем, связанных с повреждением базы данных (ошибками согласованности) и применением любых соответствующих исправлений. Одно центральное расположение, где можно найти все исправления для определенной версии, если подробные списки исправлений для SQL Server 2022, 2019, 2017.

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

  5. Если восстановление из резервной копии невозможно, CHECKDB функция для восстановления ошибок, которые можно использовать. Существует два уровня ремонта:

    • REPAIR_REBUILD — выполняет восстановление без возможности потери данных.
    • REPAIR_ALLOW_DATA_LOSS — выполняет восстановление, которое имеет возможность потери данных.

    Дополнительные сведения см . в документации по DBCC CHECKDB.

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

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

    CHECKDB обнаружил 0 ошибок выделения и 15 ошибок согласованности в базе данных mydb.
    REPAIR_ALLOW_DATA_LOSS — это минимальный уровень восстановления для ошибок, обнаруженных ( DBCC CHECKDB mydb).

    Рекомендация по восстановлению — это минимальный уровень восстановления для устранения всех ошибок CHECKDB. Минимальный уровень восстановления не означает, что этот параметр восстановления исправляет все ошибки. Некоторые ошибки просто не могут быть исправлены. Кроме того, может потребоваться выполнить процесс восстановления более одного раза. Не все сообщаемые ошибки требуют разрешения этого уровня восстановления. Это означает, что не все исправления CHECKDB при REPAIR_ALLOW_DATA_LOSS этом приводят к потере данных. Необходимо выполнить восстановление, чтобы определить, приводит ли разрешение ошибки к потере данных. Один из способов сузить уровень восстановления для каждой таблицы — использовать DBCC CHECKTABLE для любой таблицы, сообщая об ошибке. Это показывает минимальный уровень восстановления для данной таблицы.

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

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

  6. Попробуйте выполнить скрипт схемы базы данных. Используйте скрипт для создания новой базы данных, а затем используйте средство, например BCP или мастер экспорта и импорта служб SSIS, чтобы экспортировать столько данных из поврежденной базы данных в новую базу данных. Экспорт данных из поврежденной таблицы, скорее всего, завершится ошибкой. В таких случаях пропустите эту таблицу, перейдите к следующей таблице и сохраните то, что можно.

  7. Ознакомьтесь со следующими статьями о конкретных ошибках, созданных DBCC CHECKDB и выполните указанные ниже действия (если таковые есть). Далее приводятся некоторые примеры.

Изучение первопричин ошибок согласованности базы данных

Чтобы определить первопричину ошибок согласованности базы данных, рассмотрим следующие методы:

  • Проверьте журнал событий системы Windows для любых системных ошибок, драйверов или дисков, а также обратитесь к изготовителю оборудования, чтобы устранить их.
  • Запустите любой диагностика, предоставляемый вашими производителями оборудования для компьютера и (или) дисковой системы.
  • Обратитесь к поставщику оборудования или производителю устройств, чтобы убедиться, что:
    • Аппаратные устройства и конфигурация подтверждают требования ядро СУБД Microsoft SQL Server входных и выходных данных.
    • драйверы устройств и другие программные компоненты, поддерживающие все устройства в пути ввода-вывода, обновлены.
  • Рекомендуется использовать программу, например SQLIOSim на диске, в которой находятся базы данных, сообщающие об ошибках согласованности. SQLIOSim — это средство независимо от ядра SQL Server для проверки целостности операций ввода-вывода для дисковой системы. SQLIOSim поставляется с SQL Server и не требует отдельной загрузки. Его можно найти в папке \MSSQL\Binn .
  • Ознакомьтесь с документацией по накопительным обновлениям или пакету обновления для всех известных проблем, связанных с повреждением базы данных (ошибками согласованности) и применением любых соответствующих исправлений. Одно центральное расположение, где можно найти все исправления для определенной версии, если подробные списки исправлений для SQL Server 2022, 2019, 2017.
  • Проверьте наличие других ошибок, сообщаемых SQL Server, таких как нарушения доступа или утверждения. Активность в поврежденных базах данных часто приводит к исключениям нарушений доступа или ошибкам утверждения.
  • Убедитесь, что базы данных используют этот PAGE_VERIFY CHECKSUM параметр. Если сообщается об ошибках контрольной суммы, это означает, что ошибки согласованности произошли после того, как SQL Server написал страницы на диск. Таким образом, подсистема ввода-вывода должна тщательно проверяться. Дополнительные сведения об ошибках контрольной суммы см. в статье "Устранение неполадок Msg 824 в SQL Server".
  • Найдите ошибки сообщения 832 в ERRORLOG. Эти ошибки могут указывать на то, что страницы могут быть повреждены во время их хранения в кэше перед записью на диск. Дополнительные сведения см. в разделе "Устранение неполадок Msg 832 в SQL Server".
  • В другой системе попробуйте восстановить резервную копию базы данных, которую вы знаете, что "чистая" (без ошибок из CHECKDB) за которой следует резервные копии журналов транзакций, охватывающие время создания ошибки. Если вы можете "повторно создать" эту проблему, восстанавливая резервную копию базы данных "очистки" и резервную копию журнала транзакций, обратитесь в службу технической поддержки Майкрософт для получения помощи.
  • Ошибки чистоты данных могут быть проблемой при вставке или обновлении недопустимых данных в таблицы SQL Server. Дополнительные сведения об устранении ошибок очистки данных см. в статье об устранении неполадок с ошибкой DBCC 2570 в SQL Server 2005.
  • Проверьте целостность файловой системы с помощью команды chkdsk . Не выполняйтесь chkdsk во время выполнения SQL Server. Он может сообщать об ошибках временных файлов, если SQL Server записывает данные в проверяемые файлы. Кроме того, переключатели, такие как /r или /f могут перемещать байты файлов в другое расположение на диске, и такое перемещение может привести к повреждению, если SQL Server также записывает в эти файлы или считывает их. Поэтому перед выполнением chkdsk команды обязательно остановите SQL Server. Кроме того, следует соблюдать осторожность при использовании таких вариантов восстановления, как /r и /f. Перед выполнением восстановления убедитесь, что у вас есть резервная копия баз данных, так как эти параметры могут повредить файлы, если обнаружены ошибки chkdskдиска.

Дополнительные сведения

Дополнительные сведения о синтаксисе и параметрах или параметрах DBCC CHECKDB выполнения команды см. в разделе DBCC CHECKDB (Transact-SQL).

При обнаружении ошибок с помощью CHECKDBдругих сообщений, аналогичных следующему сообщению, передаются в ERRORLOG в целях создания отчетов об ошибках:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Сведения об ошибках отправлены в отчеты об ошибках Вотсона.

Файлы, используемые для создания отчетов об ошибках, включают файл SQLDump<nnn>.txt . Этот файл может быть полезен для исторических целей, так как он содержит список ошибок, CHECKDB обнаруженных в формате XML.

Чтобы узнать время DBCC CHECKDB последнего выполнения без ошибок, обнаруженных для базы данных (последняя известная очистка CHECKDB), проверьте журнал ОШИБОК SQL Server. Найдите следующее сообщение для пользовательской или системной базы данных. Это сообщение записывается как сообщение уровня информации в журнале событий приложения Windows с eventID = 17573, а также):

Date/Time spid7s CHECKDB для базы данных master завершен без ошибок в date/Time22:11:11.417 (локальное время). Это только информационное сообщение; никаких действий пользователя не требуется