Назад | Перейти на главную страницу

Ошибка MSSQL: ошибка ввода-вывода на основе согласованности - может ли она быть вызвана проблемой MSSQL или ОС?

Вот что я увидел в журнале ошибок Windows:

SQL Server обнаружил ошибку ввода-вывода на основе логической согласованности: неверная контрольная сумма (ожидаемая: 0x19fedd20; фактическая: 0x19fed5e3). Это произошло во время чтения страницы (1: 1764) в базе данных с идентификатором 6 по смещению 0x00000000dc8000 в файле 'D: \ mssql \ local_repository_pbdiffimport.mdf'. Дополнительные сообщения в журнале ошибок SQL Server или журнале системных событий могут содержать более подробную информацию. Это серьезная ошибка, угрожающая целостности базы данных, и ее необходимо немедленно исправить. Выполните полную проверку целостности базы данных (DBCC CHECKDB). Эта ошибка может быть вызвана многими факторами; Дополнительные сведения см. в электронной документации по SQL Server.

Я побежал

dbcc checkdb

который сказал мне, что я должен восстановить с опцией REPAIR_ALLOW_DATA_LOSS, поэтому я в конечном итоге запустил

DBCC CHECKDB (my_db_name, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS

Но это привело к потере около 2000 строк. Я восстановил резервную копию, но теперь боюсь, что это повторится снова, поскольку около 2 недель назад у нас уже была проблема согласованности в той же базе данных, но затем это произошло в индексе (воссозданные индексы решили проблему).

Мы исследовали диски - RAID5 выглядит хорошо, ошибок нет, а также ни одна из утилит проверки диска не выявила никаких проблем с оборудованием.

Может ли это быть вызвано ОС (Windows Server 2003) или MSSQL (MSSQL Server 2005)?

Согласованность может быть вызвана любым из факторов, аппаратным или программным. Посмотрите журналы SQL, чтобы выяснить, что потенциально могло вызвать проблему.

Мои предложения:

  • Убедитесь, что для параметра базы данных Page_Verify установлено значение CHECKSUM. Это проверяет все записи до того, как они произойдут, и является настройкой по умолчанию в SQL Server 2005.
  • Резервное копирование ежедневно или несколько раз в день (в зависимости от необходимости)
  • Настройте планы обслуживания, чтобы ежедневно проверять целостность базы данных
  • Обновляйте свой Windows Server и Sql Server с помощью патчей, в том числе и третьего программного обеспечения.
  • Читать "Основные советы по эффективному обслуживанию базы данных"поскольку он объясняет большинство моих предложений более подробно.

Я очень рекомендую эту статью, потому что она была написана для помощи системным администраторам, которые не знают, как управлять сервером базы данных.

Вероятно, в журнале системных событий есть сообщения об аппаратных событиях, вам следует изучить их.

Запустите SQLIOSIM, чтобы разгрузить диск на +24 часа. Если SQLIOSIM сообщает об ошибке, вам придется обратиться к поставщику оборудования для расследования. Это может быть с диска, с RAID-массива, с драйверов. ОС и SQL - наименее вероятные виновники.

Видеть Как использовать служебную программу SQLIOSim для имитации активности SQL Server в дисковой подсистеме.

Определенно не проблема SQL Server (ну, очень-очень-очень маловероятно). ТАКЖЕ маловероятно, что это проблема ОС - просто потому, что запись мусора слишком очевидна, чтобы выжить в качестве ошибки.

Это серьезно указывает на аппаратное обеспечение. ОЗУ (вы используете ECC?) - возможный виновник, как и любые другие связанные проблемы (RAID-контроллер? Диски?)