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

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

CREATE DATABASE 'LOCALHOST:/data/sample.fdb'

PAGE_SIZE 8192

DEFAULT CHARACTER SET WIN1251

LENGTH 250000 PAGES

FILE '/data/sample.fdl'

FILE '/data/sample.fd2'

STARTING AT 250001;

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

В этом примере первый вторичный файл "начнет работать", когда первичный файл приблизится к размеру 2 Гбайта. "Следующий файл в цепочке" начинает применяться, когда запрашиваемой операции понадобится использовать больше страниц, чем могут предоставить предыдущие файлы без превышения заданных им лимитов[36].

Обязанностью администратора базы данных является отслеживание размеров базы данных и обеспечение того, чтобы у базы данных всегда существовала возможность необходимого расширения. Принятие решения, нужно ли и когда следует разделять файлы базы данных, зависит от того, какое ожидается увеличение размеров базы данных и как скоро. Большее количество файлов может быть добавлено в любое время при использовании оператора ALTER DATABASE (см. следующий раздел).

При использовании многофайловых баз данных вы можете снять ограничение размера базы данных одним дисковым устройством, если файловая система не обеспечивает размещение одного, очень большого файла на нескольких дисках. Не будет никаких проблем инсталлировать RAID-массив и распространять базу данных Firebird на нескольких дисках для любой поддерживаемой платформы.

! ! !

ПРИМЕЧАНИЕ. Все файлы должны размещаться на дисках, находящихся под прямым управлением главной машины сервера Firebird.

. ! .

Изменение базы данных

Оператор ALTER DATABASE используется для добавления одного или более вторичных файлов к существующей базе данных. Он требует исключительного доступа к базе данных - см. разд. "Исключительный доступ"главы 39.

База данных может изменяться ее создателем (владельцем), пользователем SYSDBA или - для Linux/UNIX - любым пользователем с привилегиями операционной системы root.

Синтаксис

Синтаксис ALTER DATABASE:

ALTER {DATABASE | SCHEMA}

ADD <предложение-добавления>;

<предложение-добавления> = FILE 'спецификация-файла'

<информация-о-файле> [<предложение-добавления>]

<информация-о-файле> = {LENGTH [=] целое [PAGE[S]] |

STARTING [AT [PAGE]] целое }

[<информация-о-файле>]

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

ALTER DATABASE

ADD FILE 'mydatabase.fd2' STARTING AT PAGE 10001

ADD FILE 'mydatabase.fd3' STARTING AT PAGE 20001 ;

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

Следующий пример задает длину вторичного файла, а не начальный номер страницы:

ALTER DATABASE

ADD FILE 'mydatabase.fd2' LENGTH 10000

ADD FILE 'mydatabase.fd3' ;

Результат несколько отличается от первого примера. В этом случае Firebird начнет использовать вторичный файл, когда первичный файл достигнет лимита файловой системы.

Разница не оказывает влияния на производительность и на общий размер базы данных.

Кэш базы данных

Кэш базы данных- участок памяти, зарезервированной для базы данных, выполняющейся на сервере. Его назначение - хранение всех страниц базы данных (также называется буферами), которые были использованы последними. Он конфигурируется по умолчанию для новых баз данных и для всех баз данных, которые не были индивидуально сконфигурированы. Эта установка по умолчанию, которая задает количество блоков памяти, или буферов страниц, каждый размером в страницу базы данных, устанавливается в файле конфигурации сервера:

* для версии 1.5 и выше это параметр DefauitDbCachePages в файле firebird.config для всех платформ;

* для версии 1.0.x это параметр database_cache_pages в файле isc_config (POSIX) или в ibconfig (Win32).

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

Вновь создаваемая база данных имеет размер кэша на уровне базы данных 0 страниц. Если установка кэша остается нулевой, то соединение с этой базой данных будет использовать установку на уровне сервера. Следовательно, база данных с большим размером страницы будет использовать больший объем памяти кэша, чем база данных с меньшим размером страницы.

Размер кэша может быть установлен индивидуально и постоянно для базы данных. При необходимости он может быть изменен. Другие базы данных, для которых оставляется нулевое значение (или устанавливается в ноль), будут использовать значение по умолчанию сервера.

Количество требуемых буферов кэша является приблизительным. Оно должно быть достаточно большим, чтобы удовлетворить требованиям баз данных к страницам, но не столь большим, чтобы занять память, необходимую другим операциям. До этого момента, чем больше работы может быть выполнено в кэше, тем лучше общая производительность. Аксиома "серверы баз данных любят RAM" истинна и для Firebird. Однако Firebird использует RAM для других видов деятельности, которые являются, по меньшей мере, столь же важными, что и кэширование. Транзакции и индексы поддерживаются в RAM, а, начиная с версии 1.5, сортировка и слияние данных также выполняются в памяти, если она доступна.

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

Ограничения и значения по умолчанию

Минимальный размер кэша- 50 страниц. Максимума не существует, пока выделяемый объем памяти не превышает доступный объем RAM.

Величиной выделяемого кэша по умолчанию является:

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

Для оценки используемых ресурсов: одна выполняющаяся база данных с установками по умолчанию для PAGE_SIZE (4 Кбайт) и DefauitDbcachePages (2 Кбайт) требует 8 Мбайт памяти. Две базы данных, выполняющиеся с теми же установками, требуют 16 Мбайт и т.д. Используемый объем кэша по умолчанию вычисляется следующим образом:

PAGE_SIZE * DefaultDbCachePages * количество баз данных

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

PAGE_SIZE * DefaultDbCachePages * количество соединений

Вычисление размера кэша

Когда Firebird читает страницу базы данных с диска, он сохраняет эту страницу в кэше. Обычно размер кэша по умолчанию является достаточным. Если ваше приложение использует соединения из пяти и более таблиц, Firebird Суперсервер может автоматически увеличить размер кэша, если текущего размера недостаточно. Если ваше приложение хорошо локализовано (т. е. постоянно использует одну и ту же небольшую часть базы данных), вы можете увеличить размер кэша так, что серверу никогда не понадобится удалять какую-либо страницу из кэша для помещения туда другой.

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

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

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