Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
Подводя итог, можно сказать, что причин возникновения тех или иных поломок базы данных существует большое количество и всегда следует рассчитывать на худшее, а именно, что база данных по ч ой или иной причине повредится. Значит надо быть готовым ее восстановить и спасти ценную информацию. Далее мы рассмотрим профилактические процедуры, гарантирующие сохранность баз данных InterBase, а также способы починки поврежденных баз данных.
Профилактика повреждений баз данных InterBase
Профилактические действия, которые следует производить для предотвращения поломок баз данных, - это постоянное создание резервных копий (подробно о резервном копировании см. главу "Резервное копирование и восстановление из резервной копии"). Это самый надежный рубеж обороны против повреждений базы данных. Только
Во-первых, резервное копирование должно быть как можно более частым, во-вторых, оно должно быть последовательным, и, в-третьих, резервные копии нужно проверять на возможность восстановления.
Частое резервное копирование означает, что нужно достаточно часто делать резервную копию, например один раз в сутки. Чем меньше промежуток данных между резервным копированием базы данных, тем меньше данных потеряется в результате сбоя.
Последовательность резервного копирования означает, что резервные копии должны накапливаться и храниться как минимум неделю. Если есть возможность, то нужно записывать резервные копии на специальные устройства типа стримера, если нет - то хотя бы скопировать их на другой компьютер. История резервных копий позволит отследить скрытые повреждения и справиться с ошибкой, которая возникла давно, а проявилась, как всегда, неожиданно.
Необходимо проверять, можно ли восстановить без ошибок полученную резервную копию. Проверить это можно только одним способом - через тестовый процесс восстановления (restore). Надо сказать, что процесс восстановления занимает примерно в 3 раза больше времени, чем резервное копирование, и для больших баз проверку на восстановление ежедневно делать затруднительно, так как это может прервать работу пользователей на несколько часов, т. е. ночного перерыва может и не хватить. Конечно, организациям, имеющим базы данных такого большого объема лучше, не экономить "на спичках" и выделить отдельный компьютер для этих целей.
В том случае, если сервер должен функционировать при значительной нагрузке по 24 часа 7 дней в неделю, можно воспользоваться механизмом SHADOW для снятия "моментальных" снимков с базы данных и дальнейших операций по резервному копированию уже с моментальной копией. Подробно процесс резервного копирования и восстановления баз данных описан в главе "Резервное копирование и восстановление базы данных из резервной копии".
При создании резервной копии и затем при восстановлении базы данных из этой копии происходит пересоздание всех данных в базе данных Этот процесс backup/restore, или коротко - b/r) способствует исправлению большинства нефатальных ошибок в базе данных, связанных с повреждениями жесткого диска, выявляет проблемы с целостностью данных в базе, очищает базу данных от "мусора" (старых версий и фрагментов записей, незавершенных транзакций), значительно уменьшает размер базы данных. Можно сказать, что регулярный b/r - залог здоровья базы данных InterBase. Если база данных рабочая, то рекомендуется производить b/r еженедельно. Правда, есть свидетельства о базах данных InterBase, которые интенсивно используются по несколько лет без backup/restore. Тем не менее для собственного спокойствия все-таки желательно производить эту процедуру, тем более что ее легко можно автоматизировать.
Если по каким-то причинам невозможно часто производить процесс backup/restore (особенно restore), то можно воспользоваться инструментом для проверки и восстановления баз данных gfix, который позволяет провести проверку и восстановление многих ошибок без b/r.
Инструмент командной строки gfix
Для проверки и восстановления базы данных используется инструмент gfix. Помимо этого, gfix также может выполнять различные действия по управлению базой данных: менять диалект базы данных, устанавливать и снимать режим работы "только чтение".
Инструмент gfix выполняется в режиме командной строки и имеет следующий синтаксис:
gfix [ options] db_name
Options - это набор опций для выполнения gfix, a db_name - имя базы данных, над которой будут производиться операции, определенные набором опций. В таблице 4.11 представлены опции gfix, относящиеся к "починке"
Табл 4.11. Опции инструмента gfix для восстановления базы данных
| Опция | Описание опции |
| – f[ull] | Используется в сочетании с -v и означает, что необходимо проверять все фрагменты записей |
| – i[gnore] | Заставляет gfix игнорировать ошибки контрольных сумм во время проверки или очистки базы данных |
| – m[end] | Отмечает поврежденные записи как недоступные, в результате чего они удалятся при последующем backup/restore. Опция применяется во время подготовкой поврежденн базы данных к b/r |
| – n[o_update] | Используется в сочетании с -v для read-only-проверки базы данных, без исправления повреждений |
| – password] | Позволяет задать пароль при подключении к базе данных |
| – user name | Позволяет задать имя пользователя при подключении к базе данных |
| – v[alidate] | Задает проверку базы данных, в ходе которой обнаруживаются ошибки в структуре |
| – m[ode] | Устанавливает режим записи для базы данных - только для чтения или чтение/запись. Этот параметр может принимать два значения: read_write или read_only |
| – w[rite] {sync | async} | Включает/выключает режимы синхронной/асинхронной записи (forced writes) в базу данных: sync - включить синхронную запись (FW ON); async - включить асинхронную запись (FW OFF) |
Вот несколько типичных примеров использования gfix:
gfix w sync firstbase.gdb
В этом примере мы устанавливаем для нашей тестовой базы данных firstbase.gdb режим синхронной записи (FW ON).
gfix -v -full firstbase.gdb
В этом примере мы запускаем проверку нашей тестовой базы данных (опция -v), причем указываем, что необходимо проверить также фрагменты записей (-full).
Конечно, назначать различные опции для процесса проверки и восстановления удобнее с помощью какого-нибудь графического инструмента администрирования, но мы будем рассматривать функции восстановления базы данных с точки зрения применения именно инструментов командной строки. Эти инструменты входят в поставку InterBase, и можно быть уверенным, что они буд>т вести себя одинаково во всех ОС, поддерживаемых InterBase. He менее важен тот факт, что они всегда окажутся под рукой. Кроме того, существующие инструменты, позволяющие выполнять администрирование баз данных с клиентского компьклера, используют для этого Services API, которое не поддерживается серверами InterBase с архитектурой Classic. To есть вы сможете использовать сторонние продукты только с серверами архитектуры SuperServer.
Восстановление поврежденной базы данных
Предположим, что наша база данных содержит ошибки и нам необходимо, во-первых, проверить наличие этих ошибок, во-вторых, попытаться исправить эти ошибки. Порядок действий при этом рекомендуется соблюдать следующий.
Останавливаем сервер InterBase, если он еще работает, и делаем копию файла или файлов базы данных. Все действия по восстановлению следует производить только над копией базы данных, так как выбранная стратегия может привести к неудаче и придется начать процедуру восстановления снова - с начального состояния базы данных.
После создания копии произведем полную проверку базы данных (с проверкой фрагментов записей), для чего необходимо выполнить следующую команду:
gfix -v -full corruptbase.gdb - user SYSDBA -password
<ваш_пароль>
В данном случае corruptbase.gdb - это копия поврежденной базы данных. Команда проверит базу данных на предмет повреждения любых структур и выведет список неразрешенных проблем. Если обнаружатся такие ошибки, то нам придется пометить поврежденные данные для удаления и подготовиться к процессу backup/restore, используя следующую команду: