Управление пространством в базе данных. Выделение, освобождение и размер экстентов, страница 6

СУБД Oracle располагает средствами, которые могут немного помочь администратору базы данных. Так, например, фоновый процесс SMON автоматически объединяет смежные свободные экстенты. Если в рассмотренном выше примере удалить, также, таблицу COMPANY, системный монитор SMON автоматически объединит два смежных свободных экстента, и размер образовавшегося свободного экстента позволит создать таблицу POLICY в этом табличном пространстве (Рисунок 4).

Рисунок 4 Табличное пространство после удаления двух таблиц

Объединить смежные свободные экстенты может, также, администратор базы данных, выполнив команду ALTER TABLESPACE имя_табличного_пространства COALESCE.

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

Если все же перед Вами встала проблема дефрагментации табличного пространства, то наиболее простой способ выполнить ее – экспортировать объекты табличного пространства, удалить их из табличного пространства, а затем импортировать обратно. Это не только поможет Вам объединить свободные фрагменты табличного пространства, но и плотно упакует импортируемые объекты.

Фрагментация объектов базы данных Oracle

Фрагментация табличного пространства приводит к проблемам при выделении ресурсов для хранения объектов. Однако фрагментация на уровне объектов более коварна, т.к. ее труднее обнаружить. На уровне табличного пространства все может быть в порядке, но после тестирования экстентов табличного пространства может обнаружиться, что дело обстоит не так хорошо, как кажется.

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

Фрагментация объектов бывает нескольких типов:

·  Миграция строк (row migrating)

Миграция строк происходит, если при обновлении строка не умещается в свободном пространстве блока данных. В этом случае строка «мигрирует» в другой блок данных, причем адрес строки сохраняется в исходном месте расположения строки. Если в процессе выполнения запроса необходимо прочитать эту строку, серверный процесс просматривает ее исходное место расположения, ищет указатель на новое место расположения и переходит к новому адресу по этому указателю. Такой метод позволяет сохранять исходный идентификатор строки (ROWID), что предотвращает необходимость изменения всех ссылок в зависимых объектах базы данных (например, в индексах). Изменение всех ссылок было бы более длительной операцией, и чреватой, к тому же, возникновением ошибок.

·  Расщепление строк (row chaining)

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

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

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

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

Управление пространством в базе данных SQL Server

Управление распределением экстентов и свободным пространством в БД SQL Server

SQL Server использует для управления распределением пространства внутренние структуры данных, которые организованы в страницы следующих типов:

Тип страницы

Содержимое

Глобальная карта распределения (Global Allocation Map)

Информация о распределении экстентов

Свободное пространство страниц

(Page Free Space)

Информация о свободном пространстве, доступном на страницах

Карта распределения индексов

(Index Allocation Map)

Информация об экстентах, занятых таблицами или индексами

Bulk Changed Map

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

Differential Changed Map

Информация об экстентах, которые были изменены со времени последнего резервного копирования базы данных

Внутренние структуры данных SQL Server, которые контролируют свободное пространство, имеют относительно простую структуру. Они обладают следующими свойствами:

·  Информация о свободном пространстве плотно упакована таким образом, что вся информация содержится в сравнительно небольшом числе страниц. Это позволяет уменьшить количество дисковых чтений, необходимых для извлечения информации о распределении экстентов, за счет чего возрастает скорость операций выделения пространства для объектов базы данных.