Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
Опции options, применяющиеся для того, чтобы повлиять на процесс восстановления, описаны в таблице 4.5.
Табл 4.5. Опции gbak при восстановлении из резервной копии
| Опция | Описание |
| – c[reate_database] | Восстанавливает базу данных из резервной копии |
| – buffers] | Устанавливает размер буфера базы данных |
| – i[nactive] | Делает индексы неактивными после восстановления |
| – k[ill] | Не создает shadow-копий, которые были определены для базы данных ранее |
| – mo[de] [read_write | read_only} | Устанавливает |
| – n[o_validity] | Удаляет ограничения ссылочной целостности из восстанавливаемой базы данных, что позволяет восстанавливать те данные, которые не удовлетворяют этим ограничениям |
| – o[ne_at_a_time] | Восстанавливает одну таблицу зараз - это бывает полезным для частичного восстановления базы данных, которая содержит поврежденные данные |
| – p[age_slze] n | Устанавливает размер страницы восстанавливаемой базы данных в n байт. Доступны значения 1024, 2048, 4196 или 8192; По умолчанию размер страницы - 1024 байта |
| – pas[sword] text | Пароль пользователя, подключающегося к базе данных для восстановление из резервной копии |
| – r[eplace_database] | Восстанавливать базу данных в новый файл, а если такой файл уже существует, то перезаписать поверх |
| – se[rvice] servicename • | Восстановить базу данных на том же компьютере, где находится база данных-оригинал. Для этого вызывается Service Manager на компьютере-сервере, причем формат вызова отличается для различных сетевых протоколов: TCP/IP hostname:service_mgr; SPX hostname@service_mgr; Named pipes \\hostname\service_mgr; Local service_mgr |
| – u[ser] name | Имя пользователя, который подключается к базе данных для восстановлениям |
| – use_[all_space] | Восстанавливает базу данных со 100 %-ным заполнением каждой страницы данных, вместо 80 %-ного заполненния по умолчанию |
| – v[erbose] | Включить показ подробного протокола действий gbak во время restore |
| – y [file | suppress_output] | Направлять сообщения в файл (файла с таким именем не должно существовать) или подавить вывод сообщений |
| – z | Показать версию gbak и версию ядра InterBase-сервера |
Коротко рассмотрим некоторые важные ключи процесса восстановления. Во- первых, ключ -p[age_size] n, который устанавливает размер страницы создаваемой базы данных. Выполнить восстановление с этой опцией - это единственный способ изменить размер страницы базы данных.
Во-вторых, сочетание ключей -use_[all_space] и -mo[de] read_only позволяет создать базу данных только для чтения, с максимальным заполнением страниц данных. Это полезно при создании баз данных-справочников, распространяемых на компакт-дисках.
В-третьих, ключи -i[nactive] (деактивация индексов) и -n[o_validity] (удаление ограничений ссылочной целостности) часто применяются при восстановлении поврежденных баз данных (см. ниже главу "Починка базы данных" (ч. 4)).
Восстановление из резервных копий многофайловых баз данных
Из-за ограничения на размер одного файла базы данных в 2 (иногда 4) Гбайт, базы данных большего размера размещаются в нескольких файлах (так же как и резервные копии). Для восстановления многофайловой базы данных из многофайлового backup следует воспользоваться командой
gbak {-C|-R} [options] <файл_резервной_копии1>
<файл_резервной_копии2> [<файл_резервной_копииЗ ...]
<файл создаваемой базы данных1> <размер базы данных1>
<файл создаваемой базы данных2> <размер базы данных2>
[<файл создаваемой базы данных3> <размер базы данных3> ..]
Здесь <файл_резервной_копии N> - это N-й файл резервной копии. Восстановление будет производиться начиная с <файл_резервной_копии1>, затем будет обработан <файл_резервной_копии2>. База данных будет содержать несколько файлов начиная с <файл создаваемой БД1>, затем <файл создаваемой БД2> и т. д. После имени файла базы данных идет размер этого файла. Обратите внимание, что размер файлов исчисляется в страницах! Поэтому необходимо следить за тем, чтобы размер файла не вышел за обозначенные пределы в 2(4) Гбайт. Минимальный размер восстанавливаемого файла базы данных составляет 200 страниц. Также следует помнить о том, что не надо указывать размер последнего файла, - он увеличивается автоматически,
Как и в случае с резервным копированием больших многофайловых баз данных для ускорения процесса восстановления лучше всего воспользоваться запуском gbak в режиме сервиса.
Владелец базы данных
Резервное копирование базы данных может быть выполнено либо владельцем базы данных (owner), либо системным администратором (SYSDBA). Но восстановление базы данных может быть выполнено любым пользователем (исключая ситуацию, когда нужно восстановить базу данных поверх существующего файла, - это может осуществить только системный администратор SYSDBA или владелец). Восстановленная база данных принадлежит пользователю, который осуществил процесс восстановления т. е., он становится владельцем (owner) базы данных. Таким образом, процесс backup/restore является средством смены владельца базы данных.
Заключение
Процесс backup/restore дает возможность обновить вашу базу данных, очистить ее от "пепла" старых версий и пересоздать индексы. Чтобы уберечь данные от потери, необходимо регулярное резервное копирование, а для нормального функционирования базы данных надо периодически производить полное пересоздание базы данных с помощью восстановления ее из резервной копии.
Миграция
Под миграцией базы данных InterBase понимается несколько разных вещей - это и перенос существующей базы данных между различными версиями InterBase (например, с 4.x на 6.x), и смена ОС, под управлением которой функционирует сервер, и смена диалекта базы данных. Мы рассмотрим в этой главе все эти типы миграции и предоставим рекомендации по их безопасному осуществлению. Также будут рассмотрены варианты отката (обратной миграции) с новых версий InterBase на предыдущие.
Почему необходима миграция
Собственно, почему? Если вы любите эксперименты, то наверняка пробовали подключаться к базе данных от InterBase 5.x с помощью какого-нибудь клона 6.x и заметили, "старые" базы данных могут работать под управлением новых версий InterBase. Действительно, между версиями серверов существует совместимость "снизу вверх", когда старшая версия (например, 6.x) умеет работать с базами данных, созданных в предыдущей версии (например, 5.x), однако возможности такого взаимодействия ограничены. Например, нет совместимости при переносе базы данных между различными ОС и платформами - попробуйте скопировать файл базы данных с компьютера, на котором работает InterBase под Linux, на компьютер, где установлена Windows и соответствующая версия InterBase под Windows, а затем попытайтесь подключиться к этому файлу. База данных будет в большинстве случаев повреждена (не проводите таких экспериментов над рабочими базами данных!). Также не получится просто скопировать баз\ данных с системы на базе платформы Intel на систему SPARC и наоборот
Дело в том, что база данных, созданная с использованием определенной версии сервера InterBase, который выполняется под управлением какой-либо ОС, имеет в своей структуре привязки к версии InterBase -сервера и к ОС.
База данных имеет различные версии ODS (On-disk structure) в зависимости от того, с помощью какой версии InterBase она была создана. ODS определяет, какова внутренняя структура файлов базы данных InterBase (подробнее об ODS см. главу "Структура базы данных InterBase"). При переходе от одной версии сервера к другой ODS может меняться, при этом включаются дополнительные возможности, которые задействованы в новых версиях InterBase. Хотя новые версии InterBase ради совместимости позволяют работать с ODS от предыдущих версий, но при этом новые возможности будут недоступны.
Чтобы использовать возможности, предоставляемые новыми версиями InterBase, необходимо обязательно осуществить миграцию базы данных, созданной в предыдущей версии, к соответствующей ODS.
При переходе от одной ОС к другой возникает более очевидная ситуация: либо InterBase просто откажется работать с базой данных, пришедшей (читай - переписанной) с другой ОС, либо выдаст множество ошибок, связанных с несовместимостью представления данных в разных ОС. Дело в том, что в каждой ОС существует собственная реализация некоторых типов данных и при попытке работать с базой данных на другой платформе неверно интерпретируются значения, хранящиеся в базой данных. Миграция просто необходима при смене ОС, если вы желаете сохранить свою баз> данных в целости и сохранности.
Аначогичная ситуация складывается при переходе с одной аппаратной платформы на другую - например, при переходе Intel->Sparc. Миграция необходима для корректной модификации тех данных в базе данных, которые зависят от аппаратной платформы.
Сущность процесса миграции
Миграция - это перенос баз данных между различными версиями InterBase, а также платформами и ОС. Миграция заключается в том, что в системе- источнике (где система - это уникальное сочетание версии InterBase-сервера, ОС и аппаратной платформы, например InterBase 5.6 +Windows NT+Intel) данные из базы данных "складываются" в некоторый универсальный формат, из которого затем они разворачиваются в базу данных в системе-приемнике с учетом ее особенностей. Универсальный формат должен "пониматься" всеми модификациями InterBase, конечно, с ограничениями на переносимость между старыми и новыми версиями.