Модели безфайловой физической организации данных

Файловая структура и система управления файлами являются прерогативой операционной системы (ОС), поэтому принципы обмена данными подчиняются законам ОС. По отношению к базам данных эти принципы могут быть далеки от оптимальности. СУБД подчиняется несколько иным принципам и стратегиям управления внешней памятью, чем те, которые поддерживают ОС для большинства пользовательских процессов или задач.

Это и послужило причиной того, что СУБД взяли на себя непосредственное управление внешней памятью. При этом пространство внешней памяти предоставляется СУБД полностью для управления, а ОС не получает непосредственного доступа к этому пространству.

Физическая организация современных БД является наиболее закрытой, она определяется как коммерческая тайна для большинства поставщиков коммерческих СУБД.

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

Определим некоторые понятия, используемые в данной модели.

Чанк (chank) — представляет собой часть диска, физическое пространство на диске, которое ассоциировано одному процессу (online процессу обработки данных).

Чанком может быть назначено неструктурированное устройство, часть этого устройства, блочно-ориентированное устройство или просто файл UNIX.

Чанк характеризуется именем, смещением (от физического начала устройства до начальной точки на устройстве, которая используется как чанк), размером, заданным в Кбайтах или Мбайтах. При использовании блочных устройств и файлов величина смещения считается равной нулю.

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

Сегмент — это непрерывная область дисковой памяти.

Для моделирования каждой таблицы используется 2 типа сегментов: первый и последующие. Первый сегмент задается при создании нового объекта типа таблица, его размер задается при создании. EXTENTSIZE — размер первого сегмента, NEXT SIZE — размер каждого следующего. Минимальный размер сегмента в каждой системе свой, но в большинстве случаев он равен 4 страницам, максимальный — 2 Гбайтам. Новый сегмент создается после заполнения предыдущего и связывается с ним специальной ссылкой, которая располагается на последней странице сегмента. При динамическом заполнении БД данными применяется специальный механизм адаптивного определения размера сегментов. Внутри сегмента идет учет свободных станиц.

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

Архитектура разделяемой памяти

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

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

Разделяемая память, управляемая СУБД, состоит из нескольких типов буферов:

• Буферы страниц данных. Содержат копии страниц данных, с которыми работает СУБД.

• Буферы страниц журнала транзакций. Отражают процесс выполнения транзакции — последовательности операций над БД, переводящей БД из одного непротиворечивого состояния в другое непротиворечивое состояние.

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

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

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

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

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

Способ создания индексов с помощью SQL

В SQL существует команда создания индексных файлов. При этом по умолчанию стандартно создаются индексные файлы для первичных ключей, для вторичных ключей индексные файлы создаются дополнительной командой CREATE INDEX, которая имеет следующий формат:

CREATE [UNIQUE] INDEX <имя_индекса> ON <имя_таблицы>

( <имя_столбца>[<признак упорядочения>] |

[,<имя_столбца>[<признак упорядочения>]…])

<имя_индекса > — уникальный идентификатор в системе.

<Признак упорядочения>::={ASC | DESC}

Здесь ASC — признак упорядочения по возрастанию, DESC — признак упорядочения по убыванию значений соответствующего столбца в индексе.

Индекс может быть удален командой DROP INDEX, которая имеет следующий формат: DROP INDEX <имя_индекса>