Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Название:Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2006
- Город:Санкт-Петербург
- ISBN:5-94157-609-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ краткое содержание
Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.
Для разработчиков баз данных
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 сконфигурирован в страницах, очевидно, что база данных с большим размером страницы потребляет больше памяти, чем база данных с меньшим размером страницы. Когда множество баз данных выполняется на одном и том же сервере, может оказаться желательным переопределить размер кэша на стороне сервера значением на уровне базы данных или в некоторых случаях на уровне приложения.
Приложение, которое интенсивно выполняет индексированные выборки, требует больше буферов, чем приложение, преимущественно выполняющее добавление данных.
Там, где много клиентов обращается к различным таблицам или к различным частям одной таблицы, потребность в памяти выше, чем в случае, когда большинство клиентов работает с одними и теми же или частично перекрывающимися наборами данных.
Может случиться, что слишком много буферов кэша будет выделено из имеющейся RAM. При наличии большого количества одновременно выполняющихся баз данных запрос может затребовать больше RAM, чем доступно в системе. Кэш будет перекачиваться вперед и назад между RAM и диском, уничтожая преимущества кэширования. Другие приложения (включая сервер) будут испытывать недостаток в памяти, если кэш будет слишком велик.
Поэтому важно, чтобы в системе был установлен соответствующий объем RAM для обеспечения требований сервера баз данных к памяти. Если производительность базы данных важна для ваших пользователей, то исключите создание конкуренции за использование ресурсов со стороны других выполняющихся на сервере приложений.
Оценка размера кэша не является простой или точной наукой, особенно если у вас множество баз данных, выполняющихся одновременно. Использование сервером кэша определяется базой данных с наибольшим размером страниц. Классический сервер выделяет кэш для каждого соединения, в то время как Суперсервер объединяет кэш для всех соединений одной базы данных. Как отправная точка, это будет полезным для работы с числами и нужно для базы данных с наибольшим размером страницы. Реальные условия использования определят, где требуются корректировки.
Нет необходимости иметь кэш, вмещающий всю базу данных. Найдите коэффициент уменьшения для каждой базы данных, оценивая ту часть, к которой, скорее всего, будет доступ в процессе обычного использования. Совет по оценке простой - не существует "правила". Пусть, когда мы говорим о "DbCachePage", мы имеем в виду размер кэша, но не обязательно при условии установок сервера по умолчанию для новых и неконфигурированных баз данных.
Читать дальшеИнтервал:
Закладка: