Основные понятия реляционной модели данных. Потенциальные ключи отношений, страница 14

ДО СЮДА

МЕНЕДЖЕР ПЕРЕСЫЛОК ДАННЫХ

Рисунок

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

1.  Fix – используется для запроса страницы и загрузки ее в оперативную память. В результате выполнения этого примитива страница загружается в память и помечается, как действительная страница. При этом указатель на страницу передается транзакцией, которая инициировала выполнение этого примитива. Выполнение этого примитива требуется, когда запрашиваемая страница не находится в оперативной памяти.

2.  Use – используется транзакциями для получения доступа странице, находящейся в оперативной памяти.

3.  Unfix – сигнализирует менеджеру о том, что транзакция завершила использование страницы и страница помечена, как недействительная.

4.  Force – используется для записи страницы из оперативной памяти во вторичную. Транзакция, которая запрашивает выполнение этого примитива, приостанавливается до его завершения.

5.  Flush - используется самим менеджером для пересылки из оперативной памяти во вторичную тех страниц, которые не являются действительными и не используются в течение некоторого промежутка времени.

При работе менеджер пересылок может использовать следующие стратегии:

1.

·  Steal-policy. Согласно этой стратегии при выполнении примитива fix менеджер пересылок загружать из памяти (оперативной) действительные страницы для того, чтобы поместить на их место страницы запрашиваемые другими транзакциями.

·  No-steal-policy.

2.

·  Force-policy – данная стратегия требует, чтобы все активные страницы используемые транзакцией, записывались во вторичную память при выполнении транзакцией операции подтверждения (commit).

·  No-force policy. Разрешает запись страниц после выполнения операции подтверждения. В этом случае возможна боле эффективная организация работы менеджера пересылки.

Во всех коммерческих СУБД используется пара стратегий No-steal & No-force. При организации обмена данными между оперативной и вторичной памятью в СУБД используется своя собственная модель файла, т.к. модель файла используемая ОС, не обеспечивает надежность процесса обмена данных.

СИСТЕМА УПРАВЛЕНИЯ НАДЕЖНОСТЬЮ

Данная система обеспечивает такие свойства транзакций, как атомарность и устойчивость. Для этого система поддерживает постоянный архив, в котором регистрируются все действия, выполняемые СУБД (LOGfile). Имея информацию, содержащуюся в LOG файле можно либо отменить, либо повторить действие. Структура данной системы: рис.???.

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

ОРГАНИЗАЦИЯ LOG-ФАЙЛА

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

1.  Записи транзакций.

2.  Системные записи.

Фрагмент LOG-файла: