Re: Что делать если не проходит Backup/Restore
Первое, самое надежное и наиболее верное решение – взять последнюю резервную рабочую копию базы данных и начать работу на ней. При условии создании регулярных резервных копий БД (через Backup/Restore) вы потеряете минимум информации и будете достоверно знать что именно пропало из БД – результаты работы последних дней. Их и придется восстановить. Подчеркну, что это самый рекомендуемый и предсказуемый способ, и полностью зависит о вас.
Ну а что делать если резервной копии нет, в БД много наработок, или просто нужно попытаться получить отчет по тому что же делалось в последнее время чтобы попробовать восстановить информацию. Есть платные услуги сторонних фирм по восстановлению баз http://www.ibase.ru, хотя насколько они помогут не известно никому. Здесь будет описан путь по которому нужно пройти чтобы восстановить базу и что в результате можно будет получить.
Итак шаг 1. Нужно получить Backup. Этот шаг можно пропустить если у вас есть уже копия Backup с которой вы просто не можете сделать Restore, но это как раз наихудшая ситуация, когда из рабочей базы данных не удается сделать даже Backup – это означает что были какие то сбои в работе сервера БД (подробности на http://www.ibase.ru/devinfo/db_repair.htm ).
Итак, для начала проверяем БД на ошибки запускаю из командной строки утилиту Interbase ( она должна лежать там где установлен Interbase в папке Bin, например "C:\Program Files\InterBase Corp\InterBase\bin\gfix.exe ")
gfix -v -full database.gdb
при этом выдадутся имеющиеся ошибки в структуре БД. Не знаю насколько будет полезна полученная при этом информация, кроме того что ошибки есть и их надо чинить, но в итоге надо запустить туже утилиту с попыткой исправить ошибки
gfix -mend -ignore database.gdb
в данном случае эта утилита фактически выкусывает ошибочные страницы из БД. От того, что лежит на этих страницах будет все и зависеть. Если там лежали индексы – то ничего страшного, они будут перестроены и вы ничего не потеряете. Если ваши данные – то вы их потеряли, и скорей всего то, что на них ссылалось. Например если в сбойных страницах хранилась номенклатура, то вы потеряете часть справочника номенклатуры (какую сказать сложно, придется выверять весь справочник) и, например, если эта номенклатура использовать в спецификациях, то придется удалить эти строчки из спецификации (хотя тут можно будет уже уточнить какие именно спецификации были повреждены, а по ним, возможно, и потерянную номенклатуру). Бывает что удается отделать таким мелочами и получить рабочую базу, но это возможно не всегда :(. Ну а если в сбойных страницах лежали системные таблицы то результат сильно не предсказуемый. Это как объяснение того, что происходит, думать о нем пока рано, а потому двигаемся далее.
Проверяем снова на ошибки и надеемся что теперь все пройдет (что бывает не всегда)
gfix -v -full database.gdb
Если ошибки были, можно наверное повторить исправление, но видимо вряд ли удастся. Пробуем сделать Backup (как рекомендуют в статье отключив сборку мусора http://www.ibase.ru/devinfo/db_repair.htm)
gbak -b -v -ig -g database.gdb database.gbk
если бакап получить так и не удалось, то сделать с этой базой видимо ничего уже нельзя. [/ul]
Шаг 2. Итак мы имеем Backup, которые не восстанавливается, или который нужно восстановить после Шага 1. Делаем Restore БД командой
@echo off rem -------------------------------------------------------------------- rem -b[ackup_database] Back up database to file or device. rem -e[xpand] Do not create a compressed back up. rem -fa[ctor] n Use blocking factor n for tape device. rem -g[arbage_collect] Do not garbage collect during backup. rem -ig[nore] Ignore checksums during backup. rem -l[imbo] Ignore limbo transactions during backup. rem -m[eta_data] Back up metadata only, no data. rem -ol[d_descriptions] Back up metadata in old-style format. rem -pa[ssword] text Check for password text before accessing a database. rem -t[ransportable] Create a transportable back up (useful for copying a database to different operating systems). rem -u[ser] name Check for user name before accessing remote database. rem -v[erify] Show what gbak is doing. rem -y [file | suppress_output] rem Direct status messages to file or suppress output messages. rem Suppresses messages if file is omitted. rem -------------------------------------------------------------------- gbak.exe -create_database -kill -page_size 4096 -user SYSDBA -password masterkey -verify Restore.msg database.gbk databaseNew.gdb
и с нетерпением ждем. Если все прошло – значит проблем уже больше нет (видимо на Шаге 1 мы удалили сбойные страницы индексов, и при restore они восстановились). Ну скорей всего ошибки есть. Полученный в результате этой работы лог Restore.msg обязательно сохраняем где-нибудь с пометкой – restore не проходил с таким сообщением – он бывает очень полезен.
Шаг 3. Пробуем восстановить базу данных с дополнительными ключами
gbak.exe -create_database -kill -page_size 4096 –inactive -one_at_a_time -user SYSDBA -password masterkey -verify -y Restore.msg database.gbk databaseNew.gdb
Теперь мы пытаемся восстановить БД без индексов и по одной таблицы. Возможно теперь нам удастся получить хоть часть данных,(но часть будет точно потеряна). Если restore не прошел и в этом случае – то видимо дело совсем плохо и сделать с этой базой ничего уже нельзя :(. Ну а если мы получили успешный restore то переходим к следующему шагу.
Шаг 4. Итак мы имеем хоть как то восстановленную БД. Работать с этой БД нельзя ни в коем случае!!! Берем утилиту CSDNBackup.exe из дистрибутива TechnologiCS (эта утилита предназначена в первую очередь для перехода между платформами, но она поможет так же и в данном случае). Итак запускаем ее, указываем путь к нашей восстановленной базе и говорим сделать Backup. Эта утилита вытаскивает все данные из вашей БД и складывает их в файле с расширением cbk. Если она в процессе работы выдала ошибку, значит скорей всего в БД серьезные ошибки (видимо были повреждены системные таблицы) и восстановить БД будет невозможно, только отдельные таблицы, но такая информация вряд ли будет полезной. В любом случае сохраните лог выданный этой программой, и вместе с логом полученным при restore вышлите в службу техподдержки ( technologics@csoft.ru ), но работа с этой базой данных скорей всего будет невозможна.
Шаг 5. Если мы получили backup сделанный программой CSDNBackup.exe, то теперь следует запустить ее снова и Restore в новую БД. Программа работает таким образом, что пропускает ошибки создание индексов и выводит их конце работы с программой. В этом случае она пишет что работа завершена успешно, и выдает протокол работы. Это значит мы получили более менее работоспособную копию БД.
Шаг 6. Теперь нужно взять лог созданный при restore Interbase-ом (restore.msg он назывался у нас), взять лог созданный при Restore программой CSDNBackup (называется CSDNRestore.log обычно), запустить программу CSDNUpdate из дистрибутива TechnologiCS, снять в ней скрипты с БД (там есть такая команда отдельно), взять все содержимое папки REPORT созданной при этом, выслать все это в службу техподдержки и ждать результата. Сразу скажу что мгновенного результата не будет, так как требуется проанализировать все протоколы, по ним сделать вывод о возможности не возможности дальнейшей работы с базой, после чего начнется процесс постепенного! выявления потерянных данных ( по времени довольно непредсказуемый с учетом дистанционного общения ) . Результатом этого станет скрипт исправления ошибок в БД, выполнение которого через программу CSDNUpdate даст работоспособную БД, по возможности с указанием всех мест где имеют место ошибки. После чего на полученной БД нужно сделать Backup/Restore средствами самого Interbase и продолжать работу.
Ну вот пожалуй и все. Напомню что расписанный здесь процесс сильно затянут во времени и его результат довольно непредсказуем. Поэтому лучшим способом будет постоянное резервное копирование БД, и в случае проблем возврат к последней резервной копии ( см. начало статьи) .
PS. Все вышеперечисленные программы относятся к версии 2.9.5.0 (название и состав в других версиях может измениться).
PPS. Так же эта инфомация не относится к случаю, когда Backup/Restore перестают проходить после процедуры обновления БД (а до обновления все проходило нормально). В этом случае считается что не прошло обновление, и требуется выслать содержимое папки REPORT в службу техподдержки.