Часто спрашивают в связи с чем и привожу типовые поломки баз данных fdb:
| N | Ошибка | Вероятная причина | Действия по восстановлению | |
| 1 | internal gds software consistency check (cannot find tip page (165)) | В результате физического повреждения файла базы данных потеряна страница учета тразакций (TIP) | Анализ потерянных страниц, генерация новой страницы учета транзакций вместо потерянной, проверка базы данных и тестовое backup/restore. | |
| 2 | database file appears corrupt () wrong page type Page NNN is of wrong type (expected X, found Y) |
В результате физического повреждения нарушена последовательность страниц в файле базы данных или неправильные значения на страницах указателей (Pointer Pages), страницах вершин индексов (Index Root Pages) и т.д. | Анализ последовательности страниц в базе данных, исправление неправильных ссылок в последовательности, возможно — перегенерация запорченных страниц и генерация новых вместо потерянных. Затем проверка базы данных с помощью gfix и контрольное backup/restore. | |
| 3 | Unknown database I/O error for file «...base.gdb» Error while trying to read from file |
В результате аварийного отключения питания или аварийного завершения работы сервера последние несколько страниц файла базы данных не успевают записаться на диск и при следующем обращении к базе данных сервер не может построить целостный образ базы данных (internal database image) и открыть ее. | По оставшимся в базе данных страницам выясняются потерянные ссылки на страницы, их типы и количество. Генерируются новые страницы вместо потерянных. Производится проверка базы данных с помощью gfix и контрольное backup/restore. | |
| 4 | ERROR: internal gds software consistency check (decompression overran buffer (179)) | Серъезное повреждение базы данных, возможно запорчены системные таблицы. Иногда эта ошибка возникает при переносе базы данных с одной операционной системы на другую через файловую копию. В каждом конкретном случае разбираться нужно конкретно. | Анализ цепочек отношений в базе данных, генерация новых страниц, итерационный процесс восстановления. | |
| 5 | database file appears corrupt () — bad checksum — checksum error on database page XX |
В результате физических повреждений. В зависимости от номера страницы ситуация может меняться — это может быть простой случай наподобие 2, а может быть и очень сложный. | Анализ проблемной страницы, в зависимости от ее типа, далее восстановление потерянных цепочек. | |
| 6 | База данных выглядит работоспособной. Но gbak не может сделать backup базы, применение gfix не изменяет ситуацию. Ошибка вроде: gbak: ERROR: internal gds software consistency check (cannot find record back version (291)) gbak: ERROR: gds_$receive failed gbak: Exiting before completion due to errors gbak: ERROR: internal gds software consistency check (can't continue after bugcheck) |
Серъезное повреждение базы данных, которое нельзя точно идентифицировать — оно может быть связано как с физическими повреждениями базы данных, так и ошибками в коде сервера, а также некототорыми редкими сочетаниями структур метаданных. | Ситуация требует тщательного изучения, обычно решение состоит в поиске и удалении проблемных объектов базы данных, после чего они пересоздаются вновь. Иногда требуется перекачка данных в новую базу данных. | |
| 7 | internal gds software consistency check (next transaction older than oldest active transaction (266)) | Такая ошибка встречается только на серверах InterBase 4.x-5.x, связана с порчей заголовочной страницы. | Обычно лечится настройкой подходящих параметров транзакции на заголовочной странице. Номера транзакций рассчитываются исходя из анализа записей на страницах данных (data pages) . | |
| 8 | База данных (размером менее 4Гб) не открывается вообще — Interbase отказывается ее рассматривать в качестве базы данных, а IBSurgeon 1.0 beta 2 не открывает ее. IBSurgeon 1.0 beta 3 при открытии такого файла попросит вручную ввести размер страницы. | Как минимум, запорчена заголовочная страница. Случай требует тащательного изучения. | Регенерация базы данных на основе оставшейся части БД. Процесс сложный и никто не даст 100% гарантии успеха. | |
| 9 | База данных размером 4Гб, на версиях InterBase 4.x-5.x-6.0.x,а также на ранних бета-версиях Firebird 0.9.x не открывается, сервер отказывается ее рассматривать как корректную базу данных и не делает попыток ее открыть. | Очень сложный и трудоемкий случай, однако воссстановление вполне возможно с высокими шансами на успех. Причина состоит в том, что в ранних версиях InterBase существовало ограничение на размер файла в 4Гб (под Windows), потому что для перемещения по файлу используется 32-битная адресация. При превышении размера базы данных в 4Гб указатель перемещается из конца в начало файла и начинает писать поверх системных страниц. Процесс затирания обычно аварийно прерывается на первых нескольких десятяках страниц, и затем базу данных невозможно использовать или вообще открыть с помощью ядра InterBase. | Процесс восстановления заключается в генерации новых системных страниц на основе анализа структуры всей оставшейся базы, а также ручной правке связеймежду страницами. Это длительный, итерационный процесс, однако он обычно имеет значительные шансы на успех, так как чаще всего поврждения базы данных локализованы в небольшой области. | |
| 10 | Во время restore базы данных появляется ошибка вроде Conversion error from string «XXX». |
Ошибка может быть связана как с ошибочными NULL, которые появились в полях с атрибутом NOT NULL, так и с повреждениями самого файла резервной копии, или еще с чем-то. Каждый раз необходимо исследовать базы данных для постановки диагноза — предварительный диагноз невозможен. | Анализ базы данных на потерянные страницы, попытка перекачки базы данных в новую БД с целью выявления проблемных мест. Процесс итерационный и трудоемкий.
|
Взято на http://www.ibase.ru/dbrepair.htm
Popularity: 7%
Связанные записи
Tags: checksum, consistency check, ERROR, firebird, gbak, gds software, gfix, IBSurgeon, поломки баз данных fdb, работа, ремонт, ремонт баз, ремонт баз данных
