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

Можно сказать, что процессы backup и restore - лучшие друзья разработчика и администратора InterBase. Регулярное выполнение backup/restore поддерживает "здоровье" базы данных в прекрасном состоянии, предохраняя данные от порчи и возможных ошибок.

Помимо "лечебных" целей, процесс backup/restore дает возможность изменить многие ключевые характеристики базы данных - например, сменить размер страницы базы данных, установить для базы данных режим "только чтение" (readonly), разбить файл базы данных на несколько частей. Например, смена основных версий ODS (On-Disk Structure) и миграция от одной версии InterBase-сервера к другой происходят только при помощи процесса backup/restore.

Резервное копирование базы данных InterBase

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

Backup - это не просто сохранение базы данных путем простого файлового копирования средствами ОС. Во время backup специальная программа-клиент подключается к базе данных в режиме чтения и считывает все системные и пользовательские данные в файл особого формата, который обычно имеет расширение gbk (groton backup, по всей видимости).

Для экономии дискового пространства часто бывает удобно упаковывать файл резервной копии с помощью архиватора (обычно ZIP), так как это позволяет сжать размер backup в 8-10 раз.

Памятуя о том, что backup базы данных InterBase - это обычное считывание информации из базы данных, выполняемое специальной программой в режиме клиентского доступа, перечислим следующие особенности резервного копирования:

* Backup базы данных InterBase может осуществляться одновременно с работой обычных клиентских программ.

* Backup базы данных InterBase содержит данные, которые находились в базе данных на момент начала подключения программы, осуществляющей резервное копирование. Все изменения, проводимые выполняющимися параллельно процессу резервного копирования клиентскими программами, в резервную копию не попадут.

* Во время backup происходит считывание каждой записи из каждой таблицы в базе данных. Таким образом, происходит сборка "мусора" в базе данных (garbage collection): версии записей или их фрагменты, которые не являются актуальными, уничтожаются. Место из-под удаленных версий освобождается, и оставшиеся данные переупаковываются. Подробнее о версиях записей и сборке "мусора" смотрите главу "Транзакции. Параметры транзакций" (ч. 1).

* В процессе резервного копирования во время посещения всех записей происходит пересчет статистики по индексам, что улучшает производительность операций, которые используют эти индексы.

Осуществить резервное копирование базы данных InterBase можно двумя основными способами - с помощью специальной утилиты gbak из комплекта поставки InterBase или воспользовавшись Services API (на тех версиях сервера, которые поддерживают это API). Помимо этих двух штатных способов, можно также написать собственную программу, которая будет производить backup/restore в каком-либо формате, однако этот трудоемкий способ мы рассматривать не будем, так как штатные средства удовлетворяют потребностям почти всех пользователей InterBase.

Инструмент командной строки gbak

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

Надо заметить, что в случае использования для работы баз данных, чьи версии не совпадают с версией gbak. действует принцип "обратной совместимости". Это значит, что более "старшие" версии gbak могут работать с серверами и базами данных, созданными и функционирующими под управлением "младших" версий (например, gbak от 5.x может сделать backup базы данных, которая была создана в 4 х). Однако gbak от 4.x не сможет работать с базами данных, которые созданы в 5.x и старше, и также не сумеет распаковать резервные копии от старших версий. Единственным исключением является случай, когда gbak запускается под управлением "младшего" сервера (например, 5.x), а в качестве источника данных указывает старший сервер (например, 6.x), в этом случае произойдет резервное копирование "наоборот" - данные из формата базы данных старшей версии попадут в формат backup младшей версии. Такой прием применяется при переходе от старших версий сервера на младшие - этот процесс называется "обратной миграцией" (подробности см. ниже в главе "Миграция").

Давайте рассмотрим утилиту 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 [email protected]_mgr; Named pipes \hostnameservice_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 используют, когда производят починку базы данных (см. ниже главу "Починка базы данных").