6.1.2. Менеджеры транзакций

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

В любой СУБД существует подсистема, отвечающая за выполнение и обработку транзакций, управление параллельностью и выполнение восстановления системы (рис. 6.2).

Рис. 6.2. Подсистема обработки транзакций типичной СУБД.

Менеджер (диспетчер) транзакций осуществляет координацию работы транзакций, инециализируемых прикладными программами. Он взаимодействует с планировщиком (менеджер блокировок), отвечающим за реализацию выбранной стратегии управления параллельностью; второе название применимо в том случае, если выбран протокол управления на основе системы блокировок. Цель работы планировщика – достижение максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения целостности, согласованности базы данных. Если в процессе выполнения транзакции происходит откат, то база данных может находиться в несогласованном состоянии. Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае база данных будет автоматически восстановлена в то состояние, в котором она находилась на момент начала выполнения транзакции. Менеджер буферов отвечает за передачу данных основной памяти компьютера и вторичной дисковой памяти.

В зависимости от реализации подсистемы обработки транзакций, ресурс подлежащий диспетчеризации может быть установлен на уровне следующих объектов:

• База данных,

• Отдельный файл,

• Отдельная страница (обычно это сектор (группа секторов) на физическом диске) файла,

• Отдельная запись (строка таблицы),

• Отдельное поле в записи.

6.1.3. Параллельное выполнение транзакций

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

1. Проблемы пропавших (незафиксированных) изменений. Эта ситуация может возникнуть в том случае, когда две транзакции одновременно выполняют изменения в одной и той же записи. Например, два оператора работают на приеме заказов. Первый оператор (T₁) принял заказ на 30 единиц товара, в то время когда на складе хранилось 40 единиц товара. Получив подтверждение на заказ от покупателя, оператором был выставлен счет на это количество товара и оформлена покупка (новое количество товара на складе будет 10). В это же время второй оператор (T₂) принимает заказ на 20 единиц, принимая во внимание начальное их количество на складе – 40 штук, и также оформляет покупку. Таким образом, было продано 50 единиц, в то время как фактически их количество – 40, и на складе зафиксируется остаток не соответствующий действительности. Решение этой проблемы состоит в том, чтобы транзакции T₂ запретить доступ к базе, пока транзакция T₁ не завершится.

2. Проблемы промежуточных данных. Рассмотрим эту же ситуацию. T₁ ведет переговоры с заказчиком и указывает в заказе 30 единиц товара, однако перед окончательным выставлением счета он намеревается уточнить некоторые характеристики товара. На диске уже зафиксированы изменения в остатках товара на складе, произведенные первым оператором (остаток – 10 ед. товара). В это время T₂ работает над формированием собственного заказа на 20 ед. товара, и последние данные по остаткам товара не позволяют ему этот заказ сформировать; приложение T₂ оканчивает работу. После уточнения характеристик покупаемого товара, первый заказчик отказывается от покупки 30 единиц товара, и приложение T₁ выполняет откат транзакции, возвращая нас к исходному значению товара на складе в 40 единиц. Такая ситуация сложилась по той причине, что в процессе выполнения второй транзакции был открыт доступ к данным, которые сформировала первая транзакция.

3. Проблема несогласованных данных. Пусть, приступая к работе, оба оператора получают информацию о наличие на складе 40 ед. товара. T₁ завершает переговоры со своим клиентом и продает ему 30 ед. товара и транзакция завершается оператором COMMIT. Состояние базы данных расценивается как непротиворечивое. Пока второй оператор согласовывал условия заказа, он получает новое состояние склада, которое уже успело измениться. База данных находится в непротиворечивом состоянии, однако второй оператор считает, что нарушена целостность выполнения его транзакции. Это состояние возникло по той причине, что транзакция T₁ смогла изменить кортеж с данными, который уже был прочитан T₂ .

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

Сериализация транзакций.

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

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

Сериализация опирается на следующие правила:

1. В процессе выполнения транзакции программа «видит» только согласованные состояния базы данных; пользователь никогда не может получить доступ к незафиксированным изменениям в данных, достигнутым в результате действия другой программы;

2. Если две транзакции T₁ и T₂ выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы: – транзакция T₁ выполнялась бы первой, а за ней – выполнялась другая транзакция T₂, т.е. последовательно.

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

Существующие практические методы сериализации основываются на учете этих конфликтов с использованием хранимого журнала транзакций (см. приложение 3 [qqq]).