22.3.Журнал транзакций
Реализация в СУБД принципа “все или ничего” по отношению к инструкциям транзакции вызывает закономерный вопрос, каким образом СУБД может отменить изменения, внесенные в базу данных, если во время выполнения транзакции происходит системная ошибка? В различных СУБД для этого используются различные методы. Но все они, как правило, основаны на применении журнала транзакций (см. рисунок 24). Ниже в упрощенной форме объясняется, для чего он служит.
Рисунок 24 Журнал транзакций
Когда пользователь выполняет запрос на изменение базы данных, СУБД автоматически вносит в журнал транзакций одну запись для каждой строки, измененной в процессе выполнения запроса. Эта запись содержит две копии строки. Одна копия представляет собой строку до изменения, а другая – после изменения. Только когда в журнале будет сделана запись, СУБД изменит физическую строку на диске. Затем, если пользователь выполняет инструкцию COMMIT, в журнале отмечается конец транзакции. Если пользователь выполняет инструкцию ROLLBACK, СУБД обращается к журналу и извлекает из него “исходные” копии строк, измененных во время транзакции. Используя эти копии, СУБД возвращает строки в прежнее состояние и таким образом отменяет изменения, внесенные в базу данных в ходе транзакции.
В случае системного сбоя администратор базы данных восстанавливает ее с помощью специальной утилиты восстановления, поставляемой вместе с СУБД. Эта утилита просматривает журнал транзакций и отыскивает транзакции, которые не были завершены к моменту сбоя. Затем утилита отменяет все незавершенные транзакции; таким образом, в базе данных будут отражены только завершенные транзакции.
22.4.Транзакции и работа в многопользовательском режиме
Если с базой данных одновременно работают двое или более пользователей, обработка транзакций приобретает новое измерение. Теперь СУБД должна не только осуществлять восстановление базы данных после отмены транзакции или системного сбоя, но и гарантировать, что пользователи не будут мешать друг другу, т.е обеспечивать “прозрачность” работы пользователей. В идеальном случае каждый пользователь должен работать с базой данных так, как если бы он имел к ней монопольный доступ, и не должен беспокоиться о действиях других пользователей. Средства обработки транзакций в SQL позволяют реляционным СУБД “изолировать” пользователей друг от друга именно таким образом.
Чтобы понять, как выполняются параллельные транзакции, следует рассмотреть проблемы, которые возникнут, если эти транзакции не обрабатывать положенным образом. Хотя такие проблемы довольно многочисленны, их можно разбить на четыре основные категории, рассматриваемые в четырех последующих параграфах.
22.4.1 Проблема пропавшего обновления
Данную проблему проще всего проиллюстрировать на примере параллельной работы хотя бы двух пользователей базы данных. На рисунке 25 изображена схема работы простой прикладной программы, с помощью которой двое служащих принимают заказы от клиентов.
Рисунок 25 Проблема пропавшего обновления
Перед вводом заказа программы по таблице PRODUCTS проверяют, имеется ли требуемое изделие в наличии. На приведенном рисунке Пользователь 1 начинает вводить заказ от своего клиента на 100 изделий Samsung C110. В то же время Пользователь 2 начинает вводить заказ от своего клиента на 125 тех же изделий. Обе программы для ввода заказов выполняют запрос к таблице PRODUCTS, и каждая из них выясняет, что на складе имеется 139 требуемых изделий – количество, более чем достаточное для выполнения заказа. Пользователь 1 просит клиента подтвердить заказ; затем его копия программы обновляет таблицу PRODUCTS, показывая, что в наличии осталось 39 изделий Samsung C110, и добавляет в таблицу ORDERS новый заказ на 100 изделий. Через несколько секунд Пользователь 2 просит своего клиента подтвердить заказ. Его копия программы обновляет таблицу PRODUCTS, показывая, что на складе осталось 14 изделий Samsung C110, и добавляет в таблицу ORDERS новый заказ на 125 изделий.
Очевидно, что обработка этих двух заказов привела к возникновению противоречия в базе данных. Первое из двух обновлений таблицы PRODUCTS пропало. Заказы от обоих клиентов приняты, но на складе нет достаточного количества изделий для удовлетворения обоих заказов. Более того, таблица PRODUCTS показывает, что в наличии осталось еще 14 изделий. Данный пример показывает, что проблема “пропавшего обновления” может возникнуть всякий раз, когда две программы извлекают из базы одни и те же данные, используют их для каких – либо расчетов, а затем пытаются обновить эти данные.