Строки данных

Строки данных претерпели существенное изменение. Отметим наиболее важ­ные моменты.

Q Номера строки больше нет — строка идентифицируется номером слота, ко­торый ее определяет, либо значением кластерного ключа.

Q В версии 6.5 поля, допускающие NULL, хранятся точно так же, как поля пе­ременной длины. В версии 7.0 поля фиксированной длины всегда занимают свою полную длину, значение NULL задается специальным флагом. Это об­легчает замену неопределенного значения на некоторое конкретное без пере­мещения строк на странице.

Q Фиксированные поля вместе с описателями хранятся до полей переменной длины, так же как и в 6.5.

Q В каждой строке хранится общая длина строки и текущие длины полей пере­менной длины. Отсутствуют таблицы смещений и подстройки смещений. Дан­ные считываются последовательно с начального адреса.

Q Максимальное количество полей в строке 1024, в версии 6.5 только 256.

Текстовые страницы

В версии 7.0 изменены принципы хранения текстовых полей. Строки данных по-прежнему содержат 16-байтные указатели на текстовые данные. Однако хра­нение самих текстовых данных производится иначе.

Текстовая страница теперь может содержать несколько текстовых полей. Собст­венно данные хранятся в виде сбалансированного дерева (B-tree). Строка дан­ных содержит указатель на корневую структуру (Root structure) размером 84 байта.

Данные длиной менее 64 байт хранятся в корневой структуре. Для данных до 32 Кбайт корневая структура (Root structure) может адресовать 4 блока данных (это не блоки страниц) до 8 Кбайт каждый. Блоки наращиваются до 8 Кбайт (реально на одной текстовой странице может быть размещено 8080 байт). На­пример, если первая порция данных составляет 4 Кбайта, то отводится один блок. Если в дальнейшем данные увеличиваются до 6 Кбайт, то первый блок увеличивается до 6 Кбайт, а второй блок имеет размер всего 2 Кбайта.

Если же длина текстового поля более 32 Кбайт, то строятся промежуточные узлы.

В версии 7.0 текстовая страница может содержать данные нескольких тексто­вых полей (рис. 9.18).

Страницы журнала транзакций

В отличие от версии 6.5 в новой версии под журнал транзакций отводится все­гда отдельный файл. В предыдущей версии журнал транзакций являлся систем­ной таблицей и хранился в системном сегменте LOG. Несмотря на настоятель­ные рекомендации располагать журнал транзакций и файлы базы данных на разных физических устройствах, СУБД автоматически не контролировала этот факт. В новой версии журнал транзакций всегда хранится в отдельном файле.

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

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

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

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

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

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

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

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

Если бы запись об изменении базы данных реально немедленно записывалась во внешнюю память, это привело бы к существенному замедлению работы сис­темы.

Поэтому записи в журнал тоже буферизуются: при нормальной работе очеред­ная страница выталкивается во внешнюю память журнала только при полном заполнении записями.

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

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

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

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

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

[,<имя_столбца>[<признак упорядочения>...]) <имя_индекса > - уникальный идентификатор в системе. <Признак упорядочениям>::={ASC | DESC}

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

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

DROP INDEX <имя индекса>