Ремонт баз данных

При обращении по поводу ремонта баз данных Firebird (InterBase) Вам нужно предоставить следующую информацию на support@ibase.ru (просьба не присылать базы данных или другие большие файлы без предварительного запроса):
  1. Операционная система на сервере (версия, установленные сервиспаки, для Unix также необходимо указать версию kernel)
  2. Версия используемого сервера (например, Firebird 1.5 for Windows, SuperServer, build 4290). Точную версию сервера (на Windows можно посмотреть на закладке Version, если открыть Properties exe-файла)
  3. Размер файла базы данных и тип файловой системы
  4. Примерную причину повреждения базы данных – отключение питания, падение сервера, и т. п.
  5. Последние 10-20 сообщений в interbase.log (firebird.log)
  6. Log от утилиты IBFirstAid Diagnostician (пункт меню Direct/Direct Diagnose), полученный путем анализа поврежденной базы данных, запакованный zip или rar). Оценить объем повреждений и "ремонтопригодность" БД можно по статье.
  7. В письме обязательно укажите Ваш номер телефона для связи (с кодом города)
 
Ремонт БД
(срок ремонта
 1 день)
минимальная стоимость – 15000 рублей
Ремонт БД от 30 гигабайт и выше
(срок ремонта
– 1 день)
минимальная стоимость – 50000 рублей
Срочный ремонт, в выходные, праздничные дни и ночное время
стоимость определяется отдельно

Далее перечислены типичные повреждения и сообщения об ошибках баз данных InterBase, Firebird, с которыми успешно борется группа наших специалистов. Остальные типы повреждений также ремонтируемы, однако в каждом конкретном случае первоначально определяется объем восстановимых данных.  
N Ошибка Вероятная причина Действия по восстановлению Примерные трудозатраты
1 internal gds software consistency check (cannot find tip page (165)) В результате физического повреждения файла базы данных потеряна страница учета тразакций (TIP) Анализ потерянных страниц, генерация новой страницы учета транзакций вместо потерянной, проверка базы данных и тестовое backup/restore. 1-3 часа
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. 2-4 часа
3 Unknown database I/O error for file "...base.gdb"

Error while trying to read from file
В результате аварийного отключения питания или аварийного завершения работы сервера последние несколько страниц файла базы данных не успевают записаться на диск и при следующем обращении к базе данных сервер не может построить целостный образ базы данных (internal database image) и открыть ее. По оставшимся в базе данных страницам выясняются потерянные ссылки на страницы, их типы и количество. Генерируются новые страницы вместо потерянных. Производится проверка базы данных с помощью gfix и контрольное backup/restore. 2-4 часа
4 ERROR: internal gds software consistency check (decompression overran buffer(179)) Серьезное повреждение базы данных, возможно запорчены системные таблицы. Иногда эта ошибка возникает при переносе базы данных с одной операционной системы на другую через файловую копию. В каждом конкретном случае разбираться нужно конкретно. Анализ цепочек отношений в базе данных, генерация новых страниц, итерационный процесс восстановления. от 2 часов
5 database file appears corrupt ()

-bad checksum

-checksum error on database page XX
Результат физических повреждений. В зависимости от номера страницы ситуация может меняться – это может быть простой случай наподобие 2, а может быть и очень сложный. Анализ проблемной страницы, в зависимости от ее типа, далее восстановление потерянных цепочек. от 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)
Серьезное повреждение базы данных, которое нельзя точно идентифицировать – оно может быть связано как с физическими повреждениями базы данных, так и ошибками в коде сервера, а также некоторыми редкими сочетаниями структур метаданных. Ситуация требует тщательного изучения, обычно решение состоит в поиске и удалении проблемных объектов базы данных, после чего они пересоздаются вновь. Иногда требуется перекачка данных в новую базу данных. от 2 часов
7 internal gds software consistency check (next transaction older than oldest active transaction (266)) Такая ошибка встречается только на серверах InterBase 4.x-5.x, связана с порчей заголовочной страницы. Обычно лечится настройкой подходящих параметров транзакции на заголовочной странице. Номера транзакций рассчитываются исходя из анализа записей на страницах данных (data pages). 1-3 часа
8 База данных (размером менее 4 Гб) не открывается вообще – Interbase или Firebird отказывается ее рассматривать в качестве базы данных. Как минимум, запорчена заголовочная страница. Случай требует тщательного изучения. Регенерация базы данных на основе оставшейся части БД. Процесс сложный, и никто не даст 100% гарантии успеха. от 3 часов
9 База данных размером 4 Гб, на версиях InterBase 4.x-5.x-6.0.x,а также на ранних бета-версиях Firebird 0.9.x не открывается, сервер отказывается ее рассматривать как корректную базу данных и не делает попыток ее открыть. Очень сложный и трудоемкий случай, однако воссстановление вполне возможно с высокими шансами на успех. Причина состоит в том, что в ранних версиях InterBase существовало ограничение на размер файла в 4 Гб (под Windows), потому что для перемещения по файлу используется 32-битная адресация. При превышении размера базы данных в 4 Гб указатель перемещается из конца в начало файла и начинает писать поверх системных страниц. Процесс затирания обычно аварийно прерывается на первых нескольких десятках страниц, и затем базу данных невозможно использовать или вообще открыть с помощью ядра InterBase. Процесс восстановления заключается в генерации новых системных страниц на основе анализа структуры всей оставшейся базы, а также ручной правке связей между страницами. Это длительный итерационный процесс, однако он обычно имеет значительные шансы на успех, так как чаще всего повреждения базы данных локализованы в небольшой области. от 10 часов
10 Во время restore базы данных появляется ошибка вроде Conversion error from string "XXX". Ошибка может быть связана как с ошибочными NULL, которые появились в полях с атрибутом NOT NULL, так и с повреждениями самого файла резервной копии, или еще с чем-то. Каждый раз необходимо исследовать базы данных для постановки диагноза – предварительный диагноз невозможен. Анализ базы данных на потерянные страницы, попытка перекачки базы данных в новую БД с целью выявления проблемных мест. Процесс итерационный и трудоемкий. от 4 часов
Все указанные причины повреждения для описанных ошибок являются приблизительными и выведены на основе статистики, собранной командой iBase в процессе лечения нескольких сотен баз данных. С вероятностью до 70% можно утверждать, что данные ошибки соответствуют описанной причине и потребуют для своего исправления указанное количество часов.

Для всех случаев ремонта соблюдается полная конфиденциальность.

Также, вместо ремонта базы данных нашими специалистами, вы можете приобрести утилиту IBSurgeon FirstAid, которая позволяет ремонтировать в автоматическом режиме до 95% различных видов повреждений баз данных. 

Цены на ПО IBSurgeon
 

Подпишитесь на новости Firebird в России

Подписаться