Firebird по умолчанию устанавливается с возможностью принудительной записи (forced writes, синхронной записью). Измененные и новые данные записываются на диск немедленно после завершения операции (post).

Возможно конфигурирование базы данных для использования асинхронной записи данных, когда измененные или новые данные сохраняются в памяти кэша и периодически сбрасываются на диск подсистемой ввода/вывода операционной системы. Общий термин для такой конфигурации - отмена принудительной записи. Иногда это значение восстанавливается для улучшения производительности больших пакетных операций.

Сервер платформ Win32 не сохраняет на диск кэш сервера Firebird 1.0.x, пока не будет закрыт сервис Firebird. Не говоря уже о сбое в питании, может много чего плохо- го произойти с сервером Windows. Если он зависнет, система ввода/вывода прекратит работу, и работа вашего пользователя будет потеряна в процессе перезагрузки.

Серьезное предупреждение: не отключайте принудительную запись на сервере Windows, если вы не используете Firebird 1.5 и выше.

Firebird 1.5 по умолчанию сбрасывает кэш на диск каждые 5 секунд или каждые 100 операций записи- что произойдет быстрее. Эта частота может быть изменена В firebird.conf корректировкой одного или двух параметров MaxUnflushedWrites и MaxUnflushedWriteTime.

Windows 95 не поддерживает асинхронную запись на диск.

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

Один из режимов восстановления в утилите gbak (gbak -r[estore]) позволяет восстанавливать файл резервной копии поверх существующей базы данных - база данных перезаписывается. В этом режиме возможно восстановление без предупреждения о том, что пользователи соединены с базой данных. Разрушение базы данных является практически гарантированным результатом.

Ваши инструменты и процедуры администратора должны быть спроектированы таким образом, чтобы предотвратить перезапись базы данных, когда с ней соединены любые пользователи (включая SYSDBA).

Чтобы сделать это практически, рекомендуется восстанавливать базу на резервное дисковое пространство, используя gbak -с[reate]. Прежде чем сделать восстановленную базу данных активной, проверьте ее в резервной области, используя isql или ваш предпочитаемый инструмент администратора.

Если вашей организации нравится жить на острие ножа, используйте переключатель -restore и позвольте пользователям соединяться с базой данных и выполнять изменения. Процесс восстановления создает базу данных с нуля, и как только будут созданы таблицы, ваши пользователи смогут (по крайней мере, потенциально, или если они все SYSDBA) обращаться к ним с операциями DML, в то время как ссылочная целостность и другие ограничения находятся еще только на подходе. В лучшем случае они получат исключения и кучу неподтвержденных транзакций в частично сконструированной базе данных. В худшем, они полностью уничтожат целостность данных.

Используйте любую утилиту копирования или архивирования файловой системы (DOS copy, xcopy, tar, gzip, WinZip, WinRAR и т.д.) для копирования файлов базы данных, в то время как с ней соединены любые пользователи (включая SYSDBA). Копия будет поврежденной, но еще хуже, система блокировки и/или кэширования этих программ может привести к потере данных и, возможно, к разрушению исходного файла.

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

Командой удаления базы данных является DROP DATABASE; она не имеет параметров. При выполнении команды вы должны быть соединены с базой данных как ее владелец, пользователь SYSDBA или (в Linux/UNIX) как пользователь с привилегиями операционной системы root.

Если, будучи соединенным с базой данных, вы захотите ее удалить, используйте для этого оператор:

DROP DATABASE;

После удаления база данных не может быть восстановлена, следовательно:

* будьте уверены, что вы действительно хотите, чтобы она была потеряна навсегда;

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

Создание базы данных инсталлирует инфраструктуру, необходимую для начала создания объектов. Первичным объектом для постоянного хранения данных в базе данных является таблица. В отличие от электронных таблиц, большинства настольных систем управления данными и даже одного или двух кандидатов на "профессиональную" реляционную СУБД Firebird не сохраняет данные в структурах, которые являются "табличными" в виде упорядоченных строк и столбцов, распознаваемых файловой системой. Firebird управляет собственным дисковым пространством и использует собственные правила для размещения и отображения постоянных данных. Он поддерживает множество способов выделения данных в подобные таблицам наборы. В следующей главе мы начнем с создания постоянного SQL-объекта TABLE.