А Ковязин - Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil

• Название: Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
• Автор: А Ковязин
• Жанр: Программирование

Добро пожаловать в форум...

Тема: "Мир Interbase.." или "FireBird.." Что выбрать

Здравствуйте, Господа!

Начинаю потихоньку знакомиться с InterBase и решил приобрести книжку (поскольку с монитора читать довольно тяжело). Почитав отзывы, понял, что выбирать придется между «Мир InterBase» (Ковязин, Востриков) и «FireBird. Руководство разработчика баз данных) (Х.Борри). К сожалению, денег на обе не хватит.

В связи с этим вопросы:

·Какая из этих книг доступнее для новичка, только начинающего изучать СУБД и проектирование БД

·В какой степени эти книги, так сказать, взаимозаменяемы. Т.е. насколько знания, полученные из книги про InterBase(например) применимы для работы с FireBird и наоборот.

Заранее всем спасибо за ответы.

С уважением, Londinium

---------

Гаджимурадов Рустам

1. Если ты совсем новичек, то бери первую - в ней доступнее.

2. Если ты новичек только в ИБ, то лучше вторую.

3. Вторую книжку желательно иметь под рукой по-любому - независимо от того, есть ли первая.

4. Важно - во второй нет нихрена (кажется) про библиотеки доступа (IBX, FIBPlus).

5. Знания про InterBase, полученные из первой книги, применимы к FireBird практически в полном объеме.

...

---

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:\IBServer\isc4.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 различных версий.

Совместимость клиентов и серверов различных версий