Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
gfix -mend corruptbase. gdb-user SYSDBA-password <ваш_пароль>
После выполнения этой команды следует проверить, остались ли ошибки в базе данных, для чего необходимо вновь запустить gfix с опциями -v -full, а после того, как он отработает, произвести резервное копирование базы данных:
gdak -b -v -ig user SYSDBA -password <ваш_пароль> corruptbase.gdb corruptbase.gbk
Эта команда произведет резервное копирование базы данных (об этом говори: опция -b при этом будут выводиться подробные сведения о ходе backup (опция -v), причем ошибки, связанные с контрольными суммами, будут игнорироваться (опция -ig). Подробнее об опциях инструмента командной строки gbak можно посмотреть в главе "Резервное копирование и извлечение базы данных из резервной
В случае ошибок с backup следует запустить его в другой конфигурации:
gbak -b -v -ig -g user SYSDBA -password <ваш_пароль>
corruptbase.gdb corruptbase.gbk
где опция -g запретит сборку мусора во время резервного копирования. Часто это помогает решить проблему с backup. Но бывает, что и такого сочетания опций недостаточно для успешного завершения процесса backup. Тогда следует добавить в команду резервного копирования опции -inactive и -one_at_a_time, которые де- активируют индексы в создаваемой из backup-копии базы данных и производят подтверждение (commit) данных для каждой таблицы соответственно.
Также бывает возможным сделать резервную копию базы данных, если перед этим предварительно перевести базу данных в режим "только чтени" (read-only). Такой режим препятствует записи любых изменений а базу данных и иногда помогает осуществить backup поврежденной базы данных. Для перевода базы данных в режим "только чтение" следует воспользоваться следующей командой:
gfix -m read_only -user SYSDBA -password masterkey Disk:\Path\file.gdb
После этого необходимо вновь попытаться сделать backup базы данных с приведенными выше параметрами.
Спасение данных из поврежденной базы данных
Возможно, что все вышеприведенные действия не приведут к восстановлению базы данных. Это означает, что база серьезно повреждена и либо совсем не подлежит восстановлению как единое целое, либо для ее восстановления понадобится приложить значительное количество усилий Например, можно вручную осуществить модификацию системных метаданных, воспользоваться недокументированными функциями и т. д. Это очень тяжелая, длительная и неблагодарная работа с сомнительными шансами на успех, поэтому по возможности надо избегать ее и пользоваться другими способами. Если поврежденная база данных открывается и позволяет производить операции чтения и модификации хотя бы над частью данных, то нужно воспользоваться этой возможностью и спасать данные путем перекачки их в новую базу, а со старой базой распрощаться навсегда.
Итак, чтобы приступить к переносу данных из старой базы данных, надо сначала создать базу-приемник. Если база данных устоявшаяся (метаданные давно не менялись), то для создания базы данных-приемника можно воспользоваться какой-нибудь старой backup-копией, из которой можно извлечь метаданные (для этого лучше всего воспользоваться какой-нибудь утилитой администрирования). На основе этих метаданных необходимо создать базу данных-приемник и приступить к перекачиванию данных. В принципе главное - это вытащить данные из поврежденной базы данных, а размещение этих данные в новой базе является задачей менее трудоемкой и сложной, даже если придется восстанавливать структуру базы данных "по памяти".
При извлечении данных из таблиц следует пользоваться следующим алгоритмом действий:
* Сначала нужно попытаться выполнить SELECT * FROM tableN. Если это прошло нормально, то вы можете сохранить полученные данные во внешнем источнике. Для этой цели хорошо подходит сохранение данных в скрипт (такую функцию предоставляют почти все графические утилиты администрирования), если только таблица не содержит BLOB-полей. Если в таблице есть BLOB-поля, то данные из них необходимо сохранять в другую базу данных с помощью программы-клиента, которая будет исполнять роль посредника. Возможно, вам придется написать эту тривиальную программу специально для целей восстановления данных.
* Если запрос на выборку всех данных "не прошел", то необходимо удалить все индексы и повторить запрос. В
* Если после удаления индексов не удается прочитать все данные из таблицы, то можно попробовать делать выборки с интервалами по первичному ключу, - т. е. выбирать определенные диапазоны данных, например:
SELECT * FROM tableN WHERE field_PK>=0 and field_PK <=10000
Здесь field_PK - поле, которое исполняет роль первичного ключа. Так как InterBase имеет страничную организацию данных, то выборка диапазонов значений может оказаться достаточно эффективной, хотя это и кажется чем-то вроде шаманства. Тем не менее это работает, поскольку при этом мы можем исключить из выборки данные с поврежденных страниц, а остальные успешно прочитать. Вы можете вспомнить наш тезис о том, что в SQL нет определенного порядка хранения записей. Да, действительно, никто не гарантирует, что неупорядоченная выборка при повторных запусках вернет нам записи в одинаковом порядке, но тем не менее физически записи хранятся внутри базы данных в определенном внутреннем порядке. Очевидно, что сервер не станет "перетасовывать" записи просто ради следования букве SQL-стандартов. Этим внутренним порядком можно попытаться воспользоваться, извлекая данные из поврежденной базы данных (подробнее о страницах данных и их взаимосвязях см. ниже в главе "Структура базы данных InterBase"). Виталий Бармин, один из опытных российских InterBase-разработчиков, сообщал о том, что таким образом ему удалось извлечь из сильно попорченной базы данных, в которой было множество поврежденных страниц, до 98% информации!
Таким образом, данные из поврежденной базы данных необходимо перенести в новую базу или же просто во внешние источники данных, наподобие sql- скриптов. При копировании данных обратите внимание на значения генераторов в поврежденной базе - их необходимо сохранить для возобновления корректной работы в новой базе данных. Если у вас отсутствует полная копия метаданных, то необходимо, хотя бы частично, извлечь из поврежденной базы данных тексты хранимых процедур, триггеров, ограничений и определения индексов.
Восстановление "безнадежных" баз данных. InterBase Surgeon
В общем, восстановление базы данных может быть очень хлопотным и тяжелым делом, поэтому никогда не бывает лишним сделать резервную копию базы данных, чтобы не заниматься восстановлением поврежденных данных. Тем не менее, даже если это и случилось, не стоит отчаиваться - выход можно найти даже в самых, казалось бы, безнадежных ситуациях, и сейчас мы рассмотрим два таких случая.
Первый случай представляет собой классическую проблему - это невосстанавливающаяся резервная копия из-за наличия NULL-значений в столбце с ограничениями NOT NULL, которую пустили на восстановление прямо поверх рабочего файла. Рабочий файл затерся, процесс восстановления (restore) прервался из-за ошибки, и мы получили в результате необдуманных действий большой кусок бесполезных данных вместо резервной копии, который лежит на диске и, кажется, не поддается восстановлению. Но выход все же был найден. В той реальной ситуации, в которой мы нашли данное решение, программист сумел вспомнить, на какую именно таблицу и на какой столбец было наложено злополучное ограничение NOT NULL. Файл резервной копии был загружен в шестнадцатеричный редактор, и там путем поиска было найдено сочетание байтов, соответствующее определению этого столбца. После многочисленных экспериментов выяснилось, что ограничение NOT NULL добавляет единичку "где-то рядом" с именем столбца. Прямой правкой в НЕХ-редакторе эта единичка была исправлена на 0, и резервная копия была восстановлена. Программист отделался легким испугом и навсегда запомнил, как правильно организовывать процесс резервного копирования и восстановления из резервной копии.