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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГЛАВА 10 Распределенная обработка данных

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

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

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

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

Если же БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен параллельный доступ нескольких пользователей, то мы имеем дело с параллельным доступом к распределенной БД. Подобные системы назы­ваются системами распределенных баз данных. В общем случае режимы исполь­зования БД можно представить в следующем виде (см. рис. 10.1).

Рис. 10.1. Режимы работы с базой данных

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

Дата добавления: 2015-05-09