Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

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.

ГЛАВА 16. Таблицы.

В терминологии SQL-89 и SQL-92 таблицы Firebird являются постоянными базовыми таблицами. Эти стандарты определяют некоторые другие типы, включая просматриваемые таблицы, которые Firebird реализует в виде просмотров (view, см. главу 24), и производные таблицы (derived tables), которые Firebird реализует в виде хранимых процедур выбора (см. главы 28 и 30).

О таблицах Firebird

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

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

Структурные описания

Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов - сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются, изменяются или удаляются. Он постоянно к ним обращается при выполнении операций над строками. Такие таблицы называются системными таблицами. Более подробную информацию см. в разд. "Системные таблицы" в самом начале главы 14. Схемы системных таблиц см. в приложении 9.

Создание таблиц

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

* вы должны создать базу данных для их размещения - инструкции см. в главе 15;

* вы должны соединиться с базой данных;

* если вы планируете использовать домены для определения типов данных столбцов ваших таблиц, вы должны уже создать домены (см. главу 13).

Владение таблицами и привилегии

Когда создается таблица, Firebird автоматически применяет к ним безопасность схемы по умолчанию. Человеку, который создает таблицу (ее владелец), назначаются к ней все привилегии SQL, включая право передавать привилегии другим пользователям, триггерам и хранимым процедурам. Ни один другой пользователь, за исключением SYSDBA, не будет иметь никакого доступа к этой таблице, пока явно не получит привилегии.

! ! !

ВНИМАНИЕ! Эта защита будет столь же хороша (или плоха), сколь и защита доступа к вашему серверу. Любой, кто может соединиться с вашим сервером, сможет создать базу данных. Любой, кто может соединиться с вашей базой данных, сможет создавать в ней таблицы. Firebird 1.5 несколько улучшает эту печальную ситуацию, позволяя вам ограничивать размещения, где могут создаваться базы данных. См. параметр DatabaseAccess в файле firebird.conf.

. ! .

Информацию о привилегиях SQL см. в главе 35.