Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

Восстанавливать или создавать?

Понятие "восстановление базы данных" при ее перезаписывании родилось в годы, когда дисковое пространство было дороже, чем прием на работу эксперта по реконструкции разрушенной базы данных или формирование группы персонала по данным для восстановления системы компании по бумажным носителям.

Короче говоря, перезаписывание базы данных, чья жизнеспособность вас сильно волнует, не рекомендуется ни при каких условиях. Поразмышляйте о таких тягостных фактах:

* если восстановление завершается с ошибкой, переписываемая база данных навсегда умрет- и дела пойдут плохо при любом восстановлении;

* восстановление поверх существующей базы данных, которая находится в использовании, приведет к ее разрушению;

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

! ! !

СОВЕТ. "Горячее" копирование - нормально. "Горячее" восстановление - большая глупость.

. ! .

Если вы все-таки, несмотря на риск, решили использовать -r[epiace_database], то вы можете делать это, если при соединении будете предоставлять учетные данные владельца базы данных или пользователя SYSDBA. Любой пользователь, описанный на сервере, может восстановить базу данных с использованием режима -c[reate]. Рассмотрите последствия этого факта и примите соответствующие меры предосторожности, чтобы уберечь ваши копии от чужих рук.

Объекты, определенные пользователем

При восстановлении копии на сервер, отличный от того, с которого были сделаны копии, вы должны обеспечить существование на новом сервере наборов символов и порядков сортировки, на которые ссылается копия. Копия не может быть восстановлена, если отсутствуют языковые объекты.

Библиотеки внешних функций и фильтров BLOB, на которые ссылаются объявления в базе данных, точно гак же должны присутствовать, чтобы работа происходила без ошибок.

Восстановление в один файл

Следующая команда выполняет простое восстановление из одного файла копии в один файл базы данных:

gbak -с d:databackupsourdata.fbk d:dataourdata_trial.fdb

Многофайловое восстановление

Один или несколько файлов копии могут быть восстановлены в одно- или многотомные файлы базы данных. Не существует требования соответствия один к одному между томами файлов копии и томами файлов базы данных.

При восстановлении из многофайловой копии вы должны указать все файлы копии в том порядке, в котором они создавались, gbak громко пожалуется, если получит список в неправильном порядке или какой-нибудь том будет отсутствовать.

Для файлов базы данных вы должны задать параметр размера для каждого файла за исключением последнего. Минимальное значение- 200 страниц базы данных. Размер последнего файла всегда увеличивается до размера, необходимого для заполнения доступного пространства.

Восстановление однотомной копии в многотомную базу данных

POSIX:

./gbak -с /backups/stocks.fbk /data/stocks_trial.fdb -user SYSDBA -password mlllpOnd

-v -y /logs/backups/stocks_r.20040703.log

Windows:

gbak -c e:backupsstocks.fbk d:datastocks_trial.fdb -user SYSDBA -password mlllpOnd

-v -y d:databackuplogsstocks_r.20040703.log

Если вы зададите несколько файлов базы данных, но имеющих небольшой объем данных, то размер файлов будет достаточно мал - приблизительно 800 Кбайт для первого файла и 4 Кбайт для последующих. В процессе заполнения данными они будут последовательно увеличиваться в размерах до заданной величины.

Восстановление многотомной копии в однотомную базу данных

POSIX:

/gbak -с /backups/accounts.fbl /backups2/accounts.fb2

/backups3/accounts.fb3 /data/accounts_trial.fdb

-user SYSDBA -password mlllp0nd

-v -y /logs/backups/accounts.20040703.log

Windows:

gbak -c e:backupsaccounts.fbl f:backups2accounts.fb2

g:backups3accounts.fb3 d:dataaccounts_trial.fdb

-user SYSDBA -password mlllpOnd

-v -y d:databackuplogsaccounts.20040703.log

Восстановление нескольких файлов из нескольких файлов

POSIX:

/gbak -с /backups/accounts.fbl /backups2/accounts.fb2

/backups3/accounts.fb3 /data/accounts_trial.fdl 500000

/data/accounts_trial.fd2

-user SYSDBA -password mlllpOnd

-v -y /logs/backups/accounts.20040703.log

Windows:

gbak -c e:backupsaccounts.fbl f:backups2accounts.fb2

g:backups3accounts.fb3 d:dataaccounts_trial.fdb 500000

d:dataaccount_trial.fd2

-user SYSDBA -password mlllp0nd

-v -y d:databackuplogsaccounts.20040703.log

Возвращаемые коды и ответная реакция

Восстановление базы данных, выполняемое под Windows, возвращает код 0 при успешном завершении и 1 при ошибках. Если встретилась ошибка, посмотрите файл firebird.log (interbase.log в версии 1.0.x).

Размер страницы и размер кэша по умолчанию

При восстановлении вы можете изменить размер страницы, включив в команду переключатель -р[age_size], за которым следует целое число, задающее размер в байтах. Допустимые размеры страниц см. в табл. 38.2.

В этом примере gbak восстанавливает базу данных с размером страницы 8192 байт:

gbak -с -р 8192 d:databackupsourdata.fbk d:dataourdata_trial.fdb

Аналогичным образом вы можете использовать восстановление для изменения размера кэша базы данных по умолчанию (в страницах или в "буферах"):

gbak -с -buffers 10000 d:databackupsourdata.fbk d:dataourdata_trial.fdb

Размер страницы и производительность

Размер восстанавливаемой базы данных задается в страницах базы данных. Размер файла базы данных по умолчанию равен 200 страницам. Размер страницы базы данных по умолчанию 4 Кбайт, следовательно, если размер страницы не был изменен, то размер базы данных по умолчанию будет 800 Кбайт. Этого достаточно только для очень маленькой базы данных.

Изменение размера страницы может повысить производительность при определенных условиях.

* Firebird работает лучше, если размер строк много меньше размера страницы. Подумайте об увеличении размера страницы, если база данных содержит часто используемые таблицы с большими строками данных.

* Если база данных содержит большие индексы, то больший размер страницы базы данных уменьшает количество уровней в индексном дереве. Чем меньше глубина индекса, тем быстрее он может быть просмотрен. Подумайте об увеличении размера страницы, если глубина индекса превышает три для любого часто используемого индекса. См. главу 18, особенно разд. "Тема оптимизации" ближе к концу главы и замечания по использованию утилиты gstat для определения того, насколько хорошо выполняются ваши индексы.

* Хранение и отыскание данных BLOB наиболее эффективны, когда целый BLOB располагается на одной странице базы данных. Если приложение хранит множество BLOB, превышающих 4 Кбайт, больший размер страницы сокращает время доступа к данным BLOB.

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

Использование gbak с Менеджером сервисов Firebird

Переключатель -se[rvice_mgr] вызывает Менеджер сервисов на (обычно) удаленном сервере. Это может сэкономить значительный объем времени и сетевого трафика, когда вы хотите создавать файлы копии или базы данных на том же хосте, где размещается база данных.

На сервере Windows с локальным соединением использование Менеджера сервисов не дает никаких преимуществ.

На сервере POSIX это экономит время и трафик - даже при локальном соединении.

Если вы выполняете gbak с переключателем -service, то утилита работает другим образом. Это приводит к тому, что gbak вызывает функции копирования и восстановления Менеджера сервисов Firebird на сервере, где находится база данных.

Вы можете копировать во множество файлов и восстанавливать из множества файлов при использовании Менеджера сервисов.

Переключатель -se получает аргумент, который состоит из имени хоста подключенного сервера с константной строкой service_mgr через специальный символ. Синтаксис этого аргумента варьируется в соответствии с используемым сетевым протоколом:

* TCP/IP: hostname: service_mgrj

* именованные каналы (Named Pipes): \hostnameservice_mgr.

Восстановление в POSIX

Пользователь, который был текущим на сервере, когда был вызван Менеджер серверов для выполнения копирования - root, firebird или interbase - является владельцем файла копии на уровне файловой системы, что позволяет читать его только этим пользователем.

Когда вам нужно восстановить базу данных на сервере POSIX, которая была скопирована с использованием Менеджера сервисов, вы должны или использовать Менеджер сервисов, или соединиться с системой как владелец этого файла.

Когда режим -service не используется, владение файлом копии присваивается тому, кто выполнял gbak.

Эти ограничения не применяются к платформе Windows.

Копирование

В этом примере мы копируем базу данных, находящуюся на диске D: удаленного сервера, в файл копии на диске F: той же самой удаленной машины. Мы направляем подробный отчет об операции в файл протокола в другом каталоге. Как обычно, пример является одной строкой: