Состояние базы

данных -

перед транзакцией

Точка сохранения А

Точка сохранения В

commit transaction

Состояние базы

данных -

после транзакции

Рис. 12.4. Модель транзакции в СУБД Sybase

В некоторых СУБД, применяющих модель транзакции Sybase, запрещено внутри транзакции использовать инструкции, изменяющие структуру базы данных (инструкции create table, alter table и drop table), a также изменяющие атрибуты защиты базы данных (инструкции grant и revoke). Эти инструкщти должны выполняться за пределами транзакций. Данное ограничение облегчает реализацию модели транзакции,

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

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

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

Последовательность инструкций SQL

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

Рис. 12.5. Журнал транзакций

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

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

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

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

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

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

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

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

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