Устранение ошибок согласованности базы данных, о чем сообщает 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. Даже если сообщается об ошибках, это сообщение является сообщением уровня информации.

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

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

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

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

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

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

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

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

  • Проверьте журнал системных событий Windows на наличие ошибок, связанных с уровнем системы, драйвером или диском, и обратитесь к производителю оборудования, чтобы устранить их.
  • Запустите любые диагностика, предоставляемые производителями оборудования для компьютера и (или) дисковой системы.
  • Обратитесь к поставщику оборудования или производителю устройства, чтобы убедиться, что:
  • Рассмотрите возможность использования такой программы, как 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 .

Дополнительная информация

Дополнительные сведения о синтаксисе 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 ERRORLOG для сообщения, подобного приведенному ниже, в пользовательской или системной базе данных (это сообщение записывается как сообщение уровня информации в журнале событий приложений Windows с eventID = 17573).

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