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

Местное нарушение поражает только транзакцию, в которой оно произошло.

Глобальное нарушение поражает сразу все транзакции и приводит к значительным для системы последствиям. Возможны два вида глобальных нарушений:

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

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

Для восстановления системы применяются различные методы, основанные на использовании журнала транзакций [5, 24].

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

Используя эти копии, СУБД возвращает строки в прежнее состояние и таким образом отменяет изменения, внесенные в БД во время выполнения транзакции.

В случае системного сбоя механизм восстановления системы БД должен выяснить два вопроса:

- какие транзакции не успели завершиться к моменту сбоя и, следовательно, должны быть отменены;

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

Администратор БД восстанавливает ее с помощью специальной утилиты восстановления, поставляемой вместе с СУБД (для СУБД Firebird это утилита командной строки gfix.exe).

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

БД могут быть локальными, сетевыми и распределенными.

Если данные хранятся в одной базе данных, то транзакция к ней рассматривается как локальная. Все рассмотренное выше применимо к локальным БД.

Если с БД одновременно работают несколько пользователей, то обработка транзакций приобретает новое измерение (параллелизм, который будет рассмотрен позже).

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

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

Для обработки распределенных транзакций в современных СУБД предусмотрен так называемый протокол двухфазной фиксации транзакций (two-phase commit). Т.е. фиксация распределенной транзакции выполняется в две фазы [1, 11].

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

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

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

- потерянные или скрытые обновления;

- зависимость от незафиксированных данных ( грязное чтение);

- несогласованный анализ (неповторяемое чтение);

- чтение фантомов.

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

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

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

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

Поэтому необходим определенный механизм обработки транзакций, позволяющий устранить подобные проблемы. Такой механизм существует и опирается на следующие правила [1, 11].

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