Восстановление поврежденной базы данных Interbase или Firebird

ВАЖНО! Перед началом восстановления убедитесь что все пользователи отключены от сервера и сделайте копию файла базы данных. Если нет доступа ко всем компьютерам в сети на которых запущены приложения подключенные к базе данных, то на сервере запретите (сделайте неактивным) сетевое подключение или просто достаньте сетевой кабель из розетки на системном блоке. Подождите несколько минут пока сервер не закроет все неактивные коннекты и перезагрузите операционную систему.

Войдите в каталог Bin в папке, куда был установлен сервер Interbase/Firebird/Yaffil. Для того, чтобы не работать с "голым" окном командной строки, рекомендуется использовать любую файловую утилиту вроде Far или Total Commander.

Проверим базу данных на наличие повреждений:

gfix -v -full -user SYSDBA -pas masterkey database.gdb

вместо gdbase.gdb укажите полный путь к своему файлу базы данных (хорошая идея: для того чтобы не обременять себя вводом длинного пути, скопировать файл базы данных непосредственно в каталог BIN). Имя сервера указывать не надо!

Если утилита отработала и не выдала ничего на экран, то с базой все нормально.

Если есть повреждения, то попытаемся исправить их:

gfix -mend -full -ignore -user SYSDBA -pas masterkey database.gdb

Проверим, исправились ли все повреждения:

gfix -v -full -user SYSDBA -pas masterkey database.gdb

Если повреждения остались, то запишем информацию в Bak-файл, а потом восстановим в другой новой базе данных. Для этого последовательно выполним команды:

gbak -b -v -ig -g -user SYSDBA -pas masterkey server:database.gdb database.gbk

Здесь применены следующие ключи:

• -b -- создавать архивную копию базы;
• -v -- выводить на экран подробный лог;
• -ig -- игнорировать ошибки в данных;
• -g -- запретить сборку мусора при чтении из базы.

gbak -c -v -user SYSDBA -pas masterkey database.gbk server:new.gdb

Обратите внимание, что при указании имени базы данных необходимо указать имя сервера и через двоеточие полный путь к файлу базы данных на сервере (обратите внимание, что если вы даже скопировали файл базы данных в одну папку с утилитой резервного копирования все равно необходимо указать полный путь к файлу). При указании имени архива следует указать только полный путь к файлу без указания имени сервера.

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

Спасти базу можно следующим образом: сначала восстановить ее без внешних ссылок (индексов) с помощью команды:

gbak -c -i -user SYSDBA -pas masterkey database.gbk server:new.gdb

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

Если база повреждена настолько, что одной деактивации индексов недостаточно, то можно попробовать ключи -n (отключение проверок целостности данных) и -o (комит данных после каждой таблицы при восстановлении).

Пример команды с вышеупомянутыми ключами:

gbak -c -i -n -o -user SYSDBA -pas masterkey database.gbk server:new.gdb

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

См. также

• Пример ремонта поврежденной БД