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

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

Процесс восстановления базы данных заключается в отмене результатов незавершенных транзакций при сохранении в БД всех изменений, сделанных зафиксированными транзакциями.

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

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

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

5.3. Выполнение транзакций в многопользовательских системах

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

1. Проблема потери обновления.

Предположим, в базе данных хранится запись со сведениями о наличии на складе некоторого товара (поля Название товара – Количество, шт.):

Костюм

50

Эта запись считывается двумя пользователями. У каждого из них имеется одинаковая исходная информация, что на складе хранится 50 костюмов.

Первому пользователю необходимо отобразить в базе данных факт поступления на склад ста костюмов. Он изменяет имеющиеся данные и сохраняет обновленную запись в базе данных. Количество костюмов составляет 150 штук.

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

В результате в базе данных будет храниться ошибочная информация о наличии на складе 30 костюмов (в действительности их должно быть 130), так как изменения, внесенные первым пользователем, утрачены.

2. Проблема зависимости от незафиксированных обновлений.

Эта проблема возникает, когда одна транзакция выполнила обновление данных, но не зафиксировала его, а другая транзакция начинает использовать эти данные. При отмене первой транзакции будет получен неправильный результат.

Для иллюстрации указанной ситуации воспользуемся записью базы данных из предыдущего примера.

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

Выполняемая параллельно вторая транзакция учитывает поступление на склад двухсот костюмов. В итоге общее количество костюмов на складе составит 150 штук.

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

3. Проблема несогласованного анализа.

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

Предположим, что в базе данных хранятся записи о наличии товаров на трех складах торгового предприятия (поля Название склада – Количество, шт.):

Склад 1	50
Склад 2	100
Склад 3	200

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

Допустим, что действия в рамках транзакций выполняются в следующем порядке:

1. Первая транзакция читает первую запись. Количество товаров – 50 штук, следовательно, их суммарное количество также пока равно 50.

2. Вторая транзакция читает третью запись. Количество товаров – 200 штук.

3. Первая транзакция читает вторую запись. Количество товаров – 100 штук, сумма равна 150.

4. Вторая транзакция вычитает 100 штук товара из количества, указанного в третьей записи. Обновленное значение количества товаров в третьей записи составляет 100 штук.

5. Первая транзакция читает третью запись. Количество товаров – 100 штук, сумма равна 250.

6. Вторая транзакция читает первую запись и добавляет к хранящемуся в ней количеству товаров (50 штук) 100 поступивших единиц. Обновленное значение количества товаров в первой записи составляет 150 штук.

В результате несогласованного анализа первая транзакция неправильно вычислила суммарное количество товаров. Оно составило 250 штук при фактическом значении 350 штук.

Рассмотренные примеры свидетельствуют о том, что СУБД должна не только восстанавливать согласованное состояние базы данных после сбоев, но и обеспечивать корректную параллельную работу всех пользователей над одними и теми же данными [ 4 ]. Идеальной является такая организация работы, когда действия одного пользователя не видны другим пользователям, а выполняемые одновременно транзакции изолированы друг от друга.

Для решения этой задачи обычно используется механизм блокировки – если объект базы данных (таблица, страница или отдельная запись) используется некоторой транзакцией, доступ к этому объекту со стороны других транзакций запрещается полностью или ограничивается (блокируется). После завершения транзакции все заблокированные ею объекты становятся доступными другим транзакциям для выполнения любых операций.

Возможны два вида блокировок [ 2 ]:

1. Монопольная блокировка (X-блокировка, eXclusive locks).

В этом режиме объект базы данных, заблокированный некоторой транзакцией, может изменяться и удаляться только этой транзакцией, он недоступен для любых действий (включая чтение), выполняемых другими транзакциями.

2. Блокировка с взаимным доступом (S-блокировка, Shared locks).

Эта блокировка позволяет обращаться к объекту базы данных одновременно нескольким транзакциям, но только в режиме чтения (обновление и удаление информации запрещены).

Если транзакция обращается к объекту, к которому применена блокировка, она переходит в состояние ожидания момента снятия блокировки с этого объекта (исключением является ситуация, когда выполняемые транзакции предусматривают только чтение данных). Поэтому использование механизма блокировок приводит к задержке выполнения транзакций, следовательно, замедляет работу с базой данных.

Блокировки могут привести к возникновению тупиковых ситуаций. Предположим, первая транзакция в монопольном режиме блокирует объект А базы данных. Одновременно вторая транзакция в монопольном режиме блокирует объект В базы данных. Если затем первая транзакция пытается обратиться к объекту В, а вторая к объекту А, обе транзакции переходят в состояние бесконечного ожидания, так как они будут безрезультатно ждать прекращения выполнения другой транзакции и снятия блокировки с нужных им объектов.

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