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

Востриков С М

Давайте рассмотрим утилиту gbak поподробнее. Для того чтобы создать резервную копию базы данных, необходимо воспользоваться следующим образцом запуска gbak: gbak [-B] [options] <база_данных-источник> <файл резервной копии>

Переключатель -В означает, что необходимо выполнить резервное копирование базы данных, путь к которой указан как <база_ланных-источник>, а результаты резервного копирования упаковать в файл, указанный как <файл резервной копии>. Обратите внимание, что -В взято в квадратные скобки. По общепринятому соглашению квадратные скобки означают, что параметр внутри них необязателен. В нашем случае это значит, что gbak без параметров будет делать именно backup базы данных.

Особый интерес представляют опции, с помощью которых можно управлять процессом резервного копирования. Набор дополнительных ключей (опций), представленный предложением [options], описан в таблице 4.4, взятой из [4].

Табл 4.4. Опции gbak, применяемые при создании резервной копии

Опция	Описание
– b[ackup_dafabase]	Осуществить резервное копирование базы данных
Опции, влияющие на процесс создания резервной копии
– cofnvert]	Преобразовать внешние файлы во внутренние таблицы
– e[xpand]	Не производить сжатие резервной копии
– fa[ctor] n	Использовать блокирующий фактор n для ленточного накопителя
– g[arbage_collect]	Не собирать "мусор" во время резервного копирования
– ig[nore]	Игнорировать контрольные суммы
– l[imbo]	Игнорировать "зависшие" двухфазные транзакции (limbo)
– m[etadata]	Произвести резервное копирование только метаданных
– rtf	Создать резервную копию в нетранспортабельном формате
– ol[d_descriptions]	Производить резервное копирование метаданных в формате "старого стиля", т.е. в режиме совместимости со старыми базами данных
– pas[sword]text	Пароль пользователя, подключающегося к базе данных для резервного копирования
– role name	Подсоединиться с использованием роли name
– se[rvice] servicename	Создать резервную копию на том же компьютере, где находится "база данных-источник". Для этого вызывается Service Manager на компьютере-сервере, причем формат вызова отличается для различных сетевых протоколов: TCP/IP hostname:service_mgr; SPX hostname@service_mgr; Named pipes \\hostname\service_mgr; Local service_mgr
– t[ransportable]	Создавать транспортабельную (переносимую) резервную копию - этот параметр включен по умолчанию
– u[ser] name	Имя пользователя, который подключается к базе данных для резервного копирования
– v[erbose]	Включить показ подробного протокола действий gbak во время backup
– y [file | suppress_output]	Направлять сообщения в файл (файла с таким именем не должно существовать) или подавить вывод сообщений
– z	Показать версию gbak и версию ядра InterBase-сервера

Давайте рассмотрим основные ключи, влияющие на процесс резервного копирования.

Во-первых, это ключи -t и -nt, которые определяют, является ли создаваемая резервная копия транспортабельной, т. е. переносимой с одной платформы на другую. По умолчанию (т. е. если не указывать ничего) создается транспортабельный backup, как при использовании ключа -t.

Во-вторых, это ключ -ig[nore], появление которого заставляет gbak не проверять контрольные суммы страниц базы данных, в результате чего в резервную копию могут попасть поврежденные страницы. Если этого ключа нет, то gbak при обнаружении страницы с запорченной контрольной суммой прекратит резервное копирование и выдаст соответствующую ошибку. Обычно ключ -ignore используют, когда производят починку базы данных (см. ниже главу "Починка базы данных").

В-третьих, переключатель-g[arbage_collect], который отключает сборку "мусора" во время резервного копирования. Как известно, InterBase хранит версии записей, измененных различными транзакциями. Это приводит к тому, что на страницах данных накапливается "мусор" - записи старых версий, которые никому не нужны. "Мусор" старых версий собирается, когда производится чтение самой "свежей", актуальной версии записи (подробнее о версиях и сборке "мусора" см. главу "Транзакции. Параметры транзакций" (ч. 1)). Так как резервное копирование - это чтение всех данных в базе данных, которое считывает каждую запись в каждой таблице, то backup также является инициатором крупномасштабного "субботника" - сборки "мусора" по всей базе данных. Надо сказать, что сборка "мусора" является хоть и полезным, но достаточно ресурсоемким

процессом. Отключение сборки "мусора" приводит к значительному ускорению процесса резервного копирования. Это бывает исключительно полезным в случае очень больших (многогигабайтовых) баз данных. Однако в общем случае не рекомендуется отключать сборку "мусора" во время резервного копирования, за исключением случаев, связанных с починкой баз данных (см. главу "Починка базы данных"). Вкратце упомянем случаи использования других переключателей. Если вам необходимо получить резервную копию пустой базы данных, т. е. только ее метаданных, то воспользуйтесь переключателем -m[etadata]. Если вы используете несколько различных баз данных InterBase и применяете механизм двухфазного подтверждения транзакций, то транзакции, совершаемые сразу в двух базах данных, могут "зависнуть", т. е. получить промежуточное состояние - ни подтвержденное, ни отмененное, так называемое "in-limbo''-состояние (подробнее о транзакциях смотрите главу "Транзакции. Параметры транзакций"). Чтобы игнорировать результаты работы limbo-транзакций, т.е. версии записей, созданные этими транзакциями, применяется опция -l[imbo]. Чтобы в файл резервной копии попали данные, которые хранятся во внешних таблицах (external tables), используйте переключатель -convert, который преобразует внешние файлы во внутренние таблицы и сделает их резервную копию.

Права для выполнения резервного копирования

Вопрос о правах, необходимых для резервного копирования базы данных - очень важный вопрос. Под "правами" имеются в виду самые различные привилегии, которые мы сейчас рассмотрим. Во-первых, это права на уровне InterBase. Только системный администратор или владелец базы может производить резервное копирование базы данных, т.е. "user name" всегда должно быть или SYSDBA, или именем пользователя-владельца. И пароль в опции password соответственно (по умолчанию для SYSDBA пароль задан строкой "masterkey") должен принадлежать данному пользователю.

Во-вторых, пользователь должен обладать правами на уровне ОС ддя осуществления процесса резервного копирования. В случае если компьютер-сервер, на котором функционирует InterBase, работает под управлением Windows NT/2000/XP, то пользователь, права которого серверный процесс InterBase, должен иметь привилегии для чтения и записи файла базы данных. Это совершенно необходимое требование, обычно оно выполняется, так как по умолчанию серверный процесс InterBase пользуется правами доступа системной учетной записи (пользователь "Система"), которая по умолчанию обладает правами доступа ко всему диску.

В-третьих, необходимо отрегулировать права доступа на уровне ОС для пользователей, обращающихся с клиентских компьютеров к InterBase на компьютере- сервере. Если соединение происходит по протоколу TCP/IP, то никаких привилегий для работы с базой данных пользователю, работающему на компьютере- клиенте, давать не надо. Более того, к InterBase-серверу под управлением NT/2000/XP может обращаться любой пользователь, в том числе и не имеющий никаких прав, потому что при соединении по TCP/IP не производится проверки привилегий, специфичных для Windows. Если соединение происходит по протоколу Named Pipes, то пользователь должен иметь права на модификацию каталога и файла базы данных.

Помните, что при соединении по TCP/IP строка соединения имеет вид server_name: <диск>\<путь_на_лиске_сервера_к_база данных>, а при соединении по протоколу Named Pipes -\\sеrver_name\<диск>\<путь_на_диске_сервера_к_база данных>.

Необходимо также обратить ваше внимание на вопрос, связанный с безопасностью совместно используемых ресурсов - так называемых shared folders. Вам не нужно давать никакие права на такие ресурсы при соединении по любому протоколу -для работы с InterBase они совершенно не нужны.

В случае если компьютер-сервер с InterBase работает под управлением Linux, то для выполнения gbak также необходимо, чтобы он работал под учетной записью, имеющей права на модификацию файла базы данных. Также необходимо, чтобы пользователь, запускающий gbak, имел право запускать libgds.so - динамическую библиотеку, которая используется gbak для обращения к InterBase.

Резервное копирование многофайловых баз данных

Хотя база данных InterBase 6.x может иметь размер до 90 Тбайт, однако размер одного файла обычно ограничен размером 2 Гбайт (клоны InterBase 6 - Firebird и Yaffil, а также InterBase 6.5 на NT/2000/XP поддерживают файлы размером до 16 Гбайт). Поэтому необходимо коснуться вопроса о том, как осуществить резервное копирование базы данных InterBase, содержащей несколько файлов. Формат запуска УТИЛИТЫ gbak для резервного копирования многофайловой база данных следующий:

gbak [-B] [options] <база_данных-источник> <файл резервной копии1>

sizel[k|m|g] <файл резервной копии2> [ size2[k|m|g]

Как ви1но. формат команды аналогичен обычному однофайловому backup. Параметр <база_данных-источник> определяет путь к первому файлу базы данных. Информация об остальных файлах базы данных и путь к ним хранится в заголовке первого файла. Параметр <файл резервной копии 1> определяет имя первого файла резервной копии, <файл резервной копии2> - имя второго файла резервной копии и т. д. Так как файлы backup также подчиняются ограничению в 2 (или 4) Гбайт, то при большом размере базы данных необходимо создавать многофайловую резервную копию. Каждому файлу резервной копии поставлен в соответствие параметр "size", определяющий размер этого файла. По умолчанию размер файла указывается в байтах, однако суффикс, следующий сразу за размером, позволяет изменить единицы измерения - k (килобайты), m (мегабайты), g (гигабайты).