Ошибка 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) с NO_INFOMSGS
Но это привело к потере около 2000 строк. Я восстановил резервную копию, но теперь я боюсь, что это повторится снова, поскольку у нас уже была проблема согласованности в той же базе данных около 2 недель назад, но затем это произошло в индексе (воссозданные индексы решили проблему).
Мы исследовали диски - RAID5 выглядит хорошо, ошибок нет, а также ни одна из утилит проверки дисков не выявила никаких аппаратных проблем.
Может ли это быть вызвано ОС (Windows Server 2003) или MSSQL (MSSQL Server 2005)?
3 ответа
Согласованность может быть вызвана любым из факторов аппаратного или программного обеспечения. Посмотрите журналы SQL, чтобы выяснить, что может быть причиной проблемы.
Мои предложения:
- Убедитесь, что для параметра База данных Page_Verify установлено значение CHECKSUM. Это проверяет все записи до того, как они происходят, и является настройкой по умолчанию в SQL Server 2005.
- Резервное копирование ежедневно или несколько раз в день (в зависимости от необходимости)
- Настройка планов обслуживания, чтобы ежедневно проверять вашу базу данных
- Обновляйте ваш Windows Server и Sql Server с помощью исправлений, а также третьего ПО.
- Прочтите " Лучшие советы по эффективному обслуживанию базы данных", так как в нем подробно объясняется большинство моих предложений.
Я очень рекомендую эту статью, потому что она была написана, чтобы помочь системным администраторам, которые не знают, как управлять сервером базы данных.
Вероятно, в вашем системном журнале событий есть сообщения об аппаратных событиях, вам следует их расследовать.
Запустите SQLIOSIM, чтобы нагрузить диск на +24 часа. Если SQLIOSIM сообщает об ошибке, вам необходимо связаться с поставщиком оборудования для расследования. Это может быть с диска, с RAID-массива, с драйверов. ОС и SQL являются наименее вероятными виновниками.
См. Как использовать утилиту SQLIOSim для имитации активности SQL Server в дисковой подсистеме.
Определенно не проблема SQL Server (ну, очень, очень, очень маловероятно). ТАКЖЕ на самом деле вряд ли это проблема ОС - просто потому, что дерьмовые записи слишком очевидны, чтобы выжить до ошибки.
Это серьезно указывает на аппаратное обеспечение. ОЗУ (вы используете ECC?) Является возможным преступником, как и любые другие виды связанных с этим проблем (RAID-контроллер? Диски?)