<br />
<b>Notice</b>:  Undefined index: translationlc in <b>/home/a4on.tv/wiki/lib/plugins/translation/action.php</b> on line <b>237</b><br />
Восстановление поврежденной базы данных Firebird

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


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

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

**''gfix -v -full -user SYSDBA -pas masterkey a4on_db.fdb''**

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

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

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

**''gfix -mend -full -ignore -user SYSDBA -pas masterkey a4on_db.fdb''**

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

''gfix -v -full -user SYSDBA -pas masterkey a4on_db.fdb''

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

''gbak -b -v -ig -g -user SYSDBA -pas masterkey a4on_db.fdb db.fbk''

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

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

''gbak -c -v -user SYSDBA -pas masterkey db.fbk a4on_new.fdb''

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

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

''gbak -c -i -user SYSDBA -pas masterkey db.fdb a4on_new.fdb''

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

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

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

''gbak -c -i -n -o -user SYSDBA -pas masterkey db.fdb a4on_new.fdb''

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

Дополнительно о восстановлении базы можно почитать на сайте IBase.ru [[http://www.ibase.ru/devinfo/db_repair.htm|Как починить базу данных Interbase или Firebird]]