5.1.4.5.Понятие экстента и буферизация
Управление пространствами внешней памяти осуществляется с помощью экстентов, то есть непрерывных последовательностей страниц. Информация о наличии экстентов для объекта схемы данных находится в специальных управляющих структурах. При таком подходе модель объекта во внешней памяти представляется списком экстентов.
На рис. 35. иллюстрируется взаимосвязь блоков (страниц), экстентов и разделов (файлов) баз данных.
Рис.35. Блоки, экстенты и файлы базы данных
Операции манипулирования данными выполняются механизмами СУБД непосредственно над содержимым буферов. Система управления буферами реализует:
создание и поддержку совокупности буферных областей в оперативной памяти,
некоторый механизм перенесения содержимого буферов во внешнюю память, тем самым обеспечивая сохранение произведенных изменений в хранимой базе данных.
Следует отметить несколько важных проблем, возникающих в процессе физического проектирования.
Проблемы и параметры управления внешней памятью
Кроме рассмотренных выше проблем выбора методов доступа к записям, на этапе физического проектирования возникают и проблемы, связанные с управлением внешней памятью.
Выбор размера блока данных (страницы)
Размер блока оказывает большое влияние на производительность базы данных — при больших размерах скорость операций чтения/записи растет (особенно это характерно для полных просмотров таблиц и операций интенсивной загрузки данных), однако возрастают накладные расходы на хранение (база увеличивается) и снижается эффективность индексных просмотров. Меньший размер блока позволяет более экономно расходовать память, но вместе с тем относительно дорог. Длинные блоки (16, 32 или 64 Кбайт) лучше использовать для больших объектов данных: полнотекстовые фрагменты, мультимедиа-объекты, длинные строки и т.п. Короткие блоки (2 или 4 Кбайт) лучше подходят для значений числовых типов, недлинных строк, значений даты и времени. Следует также учитывать размер блока операционной системы (ОС), он должен быть кратен размеру блока базы данных. Малый размер блока лучше подходит для систем оперативной обработки транзакций, потому что, если сервер блокирует данные на уровне блоков, то это позволяет большему числу пользователей работать, не мешая друг другу. В системах поддержки принятия решений, для которых более критичным является не общая пропускная способность (количество транзакций в единицу времени), а среднее время отклика, больший блок предпочтительнее.
Очень важно сразу правильно выбрать размер блока: в работающей базе изменить его практически невозможно (для этого часто проводят ряд испытаний базы данных - прототипа).
Выбор размера экстента
Информация о наличии экстентов для объекта схемы данных находится в специальных управляющих структурах, реализация которых зависит от СУБД. На управление экстентами (выделение пространства, освобождение, слияние) тратятся определенные ресурсы, поэтому для достижения эффективности нужно правильно определять их экстентов.
Фрагментация
Распространенной проблемой для администраторов при управлении физическим хранением является фрагментация различных структур внешней памяти, которая чаще обусловлена операциями удаления. В отличие от преднамеренной фрагментации, такая «фрагментация» обычно ухудшает производительность. Встречается фрагментация на уровне блоков, когда в блоке остается свободное пространство после удаления строк из таблицы, на уровне экстентов, когда заполненные экстенты чередуются с незаполненными, появившимися после операций удаления таблиц, и т.п.
Фрагментацией могут быть обусловлены следующие важные для эксплуатации базы данных проблемы.
Выделение свободного пространства. При вставке строк в таблицу СУБД выдает сообщение о нехватке свободного пространства, хотя на первый взгляд пространства достаточно. Пространство выделяется экстентами и, если в базе данных нет непрерывного свободного блока нужного размера, то выдается это сообщение.
Расход свободного пространства и общее увеличение времени обработки данных. В случае сильной фрагментации обе величины могут вырасти вдвое.
Фрагментация неизбежна и поэтому является нормальным явлением, и не всегда ухудшает характеристики базы данных. Индексы также подвержены проблемам фрагментации.
Параметры проектирования физического уровня
Таким образом, организация хранения объектов данных является одной из самых сложных задач проектирования схемы базы данных, для решения которой привлекаются администраторы баз данных. И, хотя универсальных решений, которые подошли бы для любой СУБД, не существует, так как каждый производитель СУБД создает свой способ хранения и доступа к данных, хранение данных во внешней памяти в известных СУБД организовано очень похожим образом.
Вследствие этого, в литературе определяется совокупность следующих основных параметров, оказывающих влияние на проектирование схемы базы данных, общая для большинства реляционных СУБД:
размер табличных пространств для хранения таблиц;
размер табличных пространств для хранения индексов;
размер табличных пространств для хранения BLOB;
кластеры и их параметры;
размер словаря данных, включая код всех хранимых процедур, функций, триггеров, пакетов;
управляющие файлы;
файлы журнала;
интенсивность потока запросов, модифицирующих данные и индексы;
файлы временных табличных пространств (для хранения временных таблиц, которые строятся, например, при выполнении group by, а также других временных объектов);
интенсивность потока запросов, инициирующих создание временных таблиц;
потоки транзакций read-write, read-only, объем модифицируемых и считываемых ими данных, характеристики параллельной работы транзакций (какие и сколько их);
количество приложений, работающих параллельно с базой данных;
количество соединений с базой данных для каждого приложения;
входные и выходные данные, генерируемые пользовательскими программами.
В процессе проектирования все данные должны быть отражены в журнале проектирования. Однако многие тонкости в вопросах размещения объектов данных и конфигурации сервера баз данных на этапе проектирования не могут быть учтены, так как требуют полномасштабного тестирования.