3. Журнал транзакций

Реализация в СУБД принципа "все или ничего" по отношению к операторам транзакции кажется неискушенному пользователю почти чудом. Каким образом СУБД может отменить изменения, внесенные в базу данных, если во время выполнения транзакции происходит системная ошибка? В различных СУБД для этого используются различные методы. Но все они, как правило, основаны на использовании журнала транзакций, как показано на рис. 6.4.

Когда пользователь выполняет запрос на изменение базы данных, СУБД автоматически вносит в журнал транзакций одну запись для каждой строки, изменённой данным оператором. Эта запись содержит две копии строки. Одна копия представляет собой строку до изменения, а другая — после изменения. Только после того, как в журнале будет сделана запись, СУБД изменит физическую строку на диске. Затем, если пользователь выполняет оператор commit, в журнале отмечается конец транзакции. Если пользователь выполняет оператор rollback, СУБД обращается к журналу и извлекает из него "исходные" копии строк, измененных во время транзакции. Используя эти копии, СУБД возвращает строки в прежнее состояние и таким образом отменяет изменения, внесенные в базу данных во время выполнения транзакции

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

Р исунок 6.4 - Журнал транзакций

5. Транзакции и работа в многопользовательском режиме

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

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

Проблема пропавшего обновления

На рис. 6.5 изображена простая прикладная программа, с помощью которой двое служащих принимают заказы от клиентов. Перед вводом заказа программа по таблице products проверяет, имеется ли требуемый товар в наличии. На данном рисунке Джо начинает вводить заказ от своего клиента на 100 изделий ACI-41004. В то же время Мэри начинает вводить заказ от своего клиента на 125 тех же изделий ACI-41004. Обе программы для ввода заказов выполняют запрос к таблице products и каждая из них выясняет, что на складе имеется 139 требуемых изделий — количество, более чем достаточное для выполнения заказа. Джо просит клиента подтвердить заказ, затем его копия программы обновляет таблицу products, показывая, что в наличии осталось 39 изделий ACI-41004, и добавляет в таблицу orders новый заказ на 100 изделий. Через несколько секунд Мэри просит своего клиента подтвердить заказ. Ее копия программы обновляет таблицу products, показывая, что на складе осталось 14 изделий ACI-41004, и добавляет в таблицу orders новый заказ на 125 изделий.

Очевидно, что обработка этих двух заказов привела к возникновению противоречия в базе данных. Первое из двух обновлений таблицы products пропало! Заказы от обоих клиентов приняты, но на складе нет достаточного количества изделий для удовлетворения обоих заказов. Более того, таблица products показывает, что в наличии осталось еще 14 изделий! Данный пример показывает, что проблема "пропавшего обновления" может возникнуть всякий раз, когда две программы считывают из базы данных одни и те же данные, используют их для каких-либо расчетов, а затем пытаются обновить эти данные.

Р исунок 6.5 - Проблема пропавшего обновления