А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
gbak -b -user SYSDBA -password <пароль> <путь к базе данных>
<путь к backup>
При этом создастся резервная копия вашей базы данных (подробнее о резервном копировании см. в этой части главу "Резервное копирование базы данных и восстановление из резервной копии"). После этого необходимо проверить правильность этой резервной копии - попытаться восстановить ее на той же самой системе-источнике (но ни в коем случае не поверх базы данных источника!). Для этого выполняем команду:
gbak -с -user SYSDBA -password <пароль> <путь к backup>
<путь2 к базе данных>
Если контрольное восстановление прошло успешно, то сохраняем резервную копию базы данных в надежном месте (переустанавливаемый сервер таким местом обычно не является, скопируйте backup базы данных на другой компьютер или на какое-нибудь устройство резервного копирования) и приступаем к следующему этапу миграции, если нет. то смотрим главу "Починка базы данных" (см. ниже), чиним свою базу данных и вновь приступаем к процессу миграции с самого начала
Сохранение информации о пользователях при миграции
Далее, после получения корректной резервной копии вашей рабочей базы данных, необходимо установить новую версию InterBase. Процесс установки описан в главе "Установка InterBase" (ч 1), и в этой главе мы останавливаться на этом не будем. Но при установке новой версии в рамках миграции вне зависимости от того, куда устанавливается новая версия сервера InterBase - на новый компьютер пли на тот же, где стояла предыдущая версия, необходимо позаботиться о перенесении пользователей InterBase на новый сервер (конечно, если в вашей системе применяются еще какие-то вами созданные пользователи помимо устанавливаемого по умолчанию пользователя SYSDBA). Пользователи хранятся отдельно от вашей базы данных — для их хранения существует база данных ISC4.gdb, которая находится в том же каталоге, где установлен InterBase.
Помните, что, хотя пользователи хранятся в отдельной базе данных ISC4 gdb, вес разрешения и права для них хранятся в той же базе, где и объекты, на которые выдавались разрешения (т.е. в самой рабочей базе данных). Все эти права сохраняются при переходе на новую версию InieiBase (т.е. они не исчезают при backup/restore). Подробнее о пользователях и нравах см ниже главу "Безопасность в ImeiBase пользователи, роли и права"
При переустановке поверх старой версии установщик InterBase очень мудро не затирает существующие ISC4.gdb (а также ISC4.gbk), чтобы ненароком не с тереть информацию о пользователях Однако, несмотря на такую предусмотрительность, могут возникнуть проблемы связанные с тем что новый сервер может не суметь прочитать оставшеюся в наследство ISC4.gdb из-за различия в структурах баз данных новой и старой версии InterBase.
Чтобы избежать потерь информации и других проблем с базой данных пользователей ISC4.gdb при переустановке InterBase, надо сделать следующее:
* до установки новой версии сделать backup ISC4.gdb с использованием старой версии InterBase;
* в случае установки новой версии поверх старой переместить ISC4 gdb из установочного каталога InterBase, чтобы она не помешала установщику InterBase записать туда свою ISC4.gdb, которая создается по умолчанию при новой установке;
* после установки новой версии InterBase надо восстановить базу данных пользователей из созданной резервной копии старой ISC4.gdb и заменить ею ту, которая была создана по умолчанию при установке новой версии.
Рассмофим теперь этот процесс подробнее. Для резервного копирования ISC4.gdb можно воспользоваться командой вроде этой:
gbak -b -user SYSDBA -password <пароль>
C:IBServerisc4.gdb С :isc4.gbk
Для восстановления следует воспользоваться тем, что при установке новой версии всегда создается пользователь SYSDBA (с паролем по умолчанию masterkey) и мы можем восстановить backup старой ISC4.gdb:
gbak -с -user SYSDBA -password masterkey
C:isc4.gbk С:isc4.gdb
а затем заменить восстановленной копией ту ISC4.gdb, которая сформировалась по умолчанию в результате установки:
сору C:isc4.gdb <путь к каталогу с новой версией IB>isc4.gdb /у
Перед процедурой копирования восстановленной ISC4.gdb на положенное место желательно остановить сервер InterBase.
Восстановление из резервной копии на системе-приемнике
Итак, мы установили новую версию InterBase и перенесли на нее информацию о наших пользователях (т. е. восстановили базу данных ISC4.gdb). Теперь мы готовы восстановить резервную копию рабочей базы данных (созданную на старой системе) в новой версии InterBase. Для этого можно воспользоваться командой, похожей на эту:
gbak -с -user SYSDBA -password <пароль> <путь к backup>
<путь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: практически всегда, когда он наталкивается на неизвестную ему особенность, выдается ошибка. Это предохраняет от возможных скрытых ошибок в интерпретации данных. Например, при наличие в базы данных от InterBase 6.x 64-разрядных генераторов при попытке перевода этой базы на InterBase 5.x возникнет ошибка, сигнализирующая о том, что в 5.x нет подобных генераторов. Их придется удалить перед обратной миграцией, а после восстановления базы данных вновь создать.
Вот вкратце мы и рассмотрели практически все возможные варианты миграции, приведенные в таблице 4.6. Остался открытым вопрос переводе базы данных InterBase 6.x с диалекта 1 на диалект 3. Мы вернемся к нему чуть позже, а пока рассмотрим поведение и вопросы совместимости клиентов и серверов InteiBase различных версий.
Совместимость клиентов и серверов различных версий
