Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
а затем заменить восстановленной копией ту ISC4.gdb, которая сформировалась по умолчанию в результате установки:
сору C:\isc4.gdb <путь к каталогу с новой версией IB>\isc4.gdb /у
Перед процедурой копирования восстановленной ISC4.gdb на положенное место желательно остановить сервер InterBase.
Восстановление из резервной копии на системе-приемнике
Итак, мы установили новую версию InterBase и перенесли на нее информацию о наших пользователях (т. е. восстановили базу данных ISC4.gdb). Теперь мы готовы восстановить резервную копию рабочей базы данных (созданную на старой системе) в новой версии InterBase. Для этого можно воспользоваться командой, похожей на эту:
gbak -с -user SYSDBA -password <пароль> <путь
<путь2 к базе данных>
Как видите, эта команда аналогична той, которую мы применяли для контрольного восстановления резервной копии. База данных восстановится на новой системе, причем если вы сменили версию сервера (например, с 5.x на 6.x), то во время восстановления базы данных будет создана уже с новой версией ODS, т. е. прямая миграция "назад", на предыдущую версию, будет невозможна.
При восстановлении вы можете изменить владельца базы данных, т. е. можно восстановить база данных от имени какого-либо другого пользователя, а не от SYSDBA. Это бывает полезным в целях повышения безопасности работы с базой данных.
Аналогичный процесс миграции применяется и в случае смены аппаратной платформы и/или ОС - будь то переход на другую платформу (Intel->Sparc) или просто замена оборудования или ОС
Прямая миграция по вышеописанному алгоритму - наиболее простой и частый вид миграции баз данных InterBase. Однако, как вы можете видеть, в таблице 4 6 существуют также миграции, обозначенные как "Особый процесс". Сейчас мы подробно рассмотрим его
Особый процесс, или обратная миграция
Особый процесс выражать такой переход между версиями InterBase, когда обычным методом, через backup/restore, базу данных не удастся "понизить" до младшей версии: gbak от младшей версии откажется работать с базами данных, созданными с использованием старшей версии InterBase.
В целом обратная миграция является недокументированным действием, и потому особых гарантий целостности данных при таком переходе дать нельзя, однако известно достаточно много спешных примеров подобного переноса
Чтобы осуществить обратную миграцию базы данных, необходимо задействовать два компьютера с установленными на них серверами InterBase, один из которых имеет новую версию (источник), а другой - предыдущую (приемник). Последовательность действий такая:
На компьютере-приемнике запускаем инструмент командной строки gbak и даем ему указание создать backup базы данных, находящейся на компьютере- источнике. Например, если компьютер-источник называется source_nt, то команда будет выглядеть примерно так:
gbak -b -user SYSDBA -password <пароль> source_nt:<путь_к_базе
данных_источнику> <Путь к bасkup-приемнику>
При этом gbak подключится к серверу-источнику как клиент (здесь используется возможность обратной совместимости, когда клиент младшей версии может подсоединиться к серверу, имеющему старшую) и произведет чтение всех данных из базы данных-источника, пользуясь возможностями старшей версии сервера. Но backup лой базы данных будет создан с использованием старой версии InterBase-приемника, т. е. полученную резервную копию в дальнейшем можно будет восстановить в полноценную базу данных, соответствующую младшей версии. Естественно, при таком подходе могут быть "подводные камни" - в тех случаях, когда в базе данных используются те свойства новой версии, которые не поддерживаются в старой. При этом возможно несколько исходов процесса обратной миграции: gbak либо проигнорирует новые возможности и попытается закончить резервное копирование без них, либо попытается проинтерпретировать их в стиле своей версии и получить какие-то правдоподобные значения. Конечно, наличие новых свойств в базе данных, которую переводим на младшую версию InterBase, таит в себе ту опасность, что, произведя обратную миграцию, мы окажемся у "разбитого корыта" - с базой данных, наполненной некорректными значениями или вообще нечитабельной. К счастью, gbak достаточно жестко относится к неоднозначностям в процессе backup:
Вот вкратце мы и рассмотрели практически все возможные варианты миграции, приведенные в таблице 4.6. Остался открытым вопрос переводе базы данных InterBase 6.x с диалекта 1 на диалект 3. Мы вернемся к нему чуть позже, а пока рассмотрим поведение и вопросы совместимости клиентов и серверов InteiBase различных версий.
Совместимость клиентов и серверов различных версий
Как известно, клиент-серверное приложение, использующее СУБД InterBase, обычно состоит из двух основных частей - клиентской и серверной. Клиентская часть, обычно состоящая из исполняемого модуля приложения базы данных (как правило, ехе-файла) и динамических библиотек, исполняется на клиентском компьютере. Серверная часть - собственно базы данных и серверные модули InterBase, обслуживающие клиентские запросы, - исполняется на компьютере- сервере (подробнее о составе модулей, образующих клиент и сервер СУБД InterBase, см. ниже главу "Состав модулей InterBase").
То, что в результате переустановки InterBase и миграции базы данных вы смените версию сервера InterBase на компьютере-сервере, не означает, автоматической замены клиентов на всех клиентских компьютерах. Обычно необходимо вручную заменить клиентскую часть InterBase на этих компьютерах. То есть обычно клиенты InterBase должны иметь ту же версию, что и сервер. Однако если вы не замените клиентские части, то можете обнаружить, что клиенты от младшей версии InterBase работают со старшей версией InterBase-сервера. Такая совместимость - вполне нормальная, документированная особенность, которая используется для облегчения процесса миграции. Возможность использования клиентов и серверов InterBase различных версий представлена в таблице 4.7.
Табл 4.7. Совместимость клиентов и серверов различных версий InterBase
| Сервер от версии | Клиент версии | ||
| /диалект БД | InterBase 4.x | InterBase 5.x | InterBase 6.x и клоны |
| InterBase 4 х | Полная | Полная | Полная |
| InterBase 5 х | С ограничениями | " | " |
| InterBase 6 х и его клоны /диалект 1 | Неустойчивая | С особыми свойствами | " |
| InterBase 6.x и его клоны /диалект 3 | " | " | " |
В таблице 4.7 на пересечении версии клиента и версии сервера (для 6.x - с учетом диалекта базы данных) стоит описание их совместимости.
Как видно, совместимость клиентов и серверов InterBase имеет 4 основных разновидности - полную, с ограничениями, с особыми свойствами и неустойчивую.
Полная совместимость возможна в ситуации, когда клиент и сервер имеют одинаковые версии или когда версия клиента старше версии сервера. Полная совместимость означает, что клиент может реализовать всю функциональность, предлагаемую сервером.