ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1577
Скачиваний: 23
156
•
Подана
команда
COMMIT -
зафиксировать
транзакцию
(
в
режиме
AVTOCOMMIT
это
происходит
автоматически
при
успешном
выполнении
запроса
).
Команда
COMMIT
завершает
текущую
транзакцию
.
При
этом
гарантируется
,
что
результаты
работы
завершенной
транзакции
фиксируются
,
т
.
е
.
сохраняются
в
долговременной
памяти
базы
данных
.
•
Подана
команда
ROLLBACK
–
откатить
транзакцию
.
По
этой
команде
результат
работы
неудачной
транзакции
,
т
.
е
.
транзакции
,
в
процессе
выполнения
которой
возникла
какая
-
либо
ошибка
,
полностью
аннулируются
.
Тем
самым
база
данных
приводится
к
состоянию
,
в
котором
она
находилась
перед
началом
неудачной
транзакции
.
•
Произошел
сбой
системы
.
Система
из
-
за
сбоя
прекратила
работу
до
фиксации
результатов
транзакции
по
команде
COMMIT
или
ее
отказ
по
команде
ROLLBACK
,
т
.
е
.
база
данных
оказалась
в
логически
несогласованном
состоянии
.
В
этом
случае
СУБД
при
перезагрузке
системы
должна
привести
базу
данных
в
согласованное
состояние
.
Таким
образом
,
наличие
в
СУБД
механизма
поддержки
транзакций
подразумевает
,
что
система
гарантирует
нахождение
базы
данных
в
логически
согласованном
(
целостном
)
состоянии
до
начала
и
после
окончания
выполнения
транзакции
или
автоматическое
приведение
данных
в
целостное
согласование
при
восстановлении
работоспособности
системы
.
Возможность
выполнения
такой
гарантии
подразумевает
обеспечение
обратимости
всех
операций
,
осуществляемых
в
процессе
транзакции
,
вплоть
до
ее
завершения
.
Следует
заметить
,
что
не
любая
СУБД
и
не
всегда
обеспечивает
выполнение
всех
свойств
АСИД
в
полном
объеме
.
Ниже
,
проблемы
реализации
механизма
управления
транзакциями
рассматриваются
более
подробно
.
Эти
проблемы
можно
разделить
на
две
группы
.
Это
:
1)
обеспечение
согласованности
данных
,
т
.
е
.
фактически
обеспечение
восстановления
данных
,
при
сбоях
системы
,
и
2)
обеспечение
согласованности
данных
при
совместной
работе
с
базой
данных
нескольких
пользователей
.
13.
Откат
транзакций
и
восстановление
данных
после
сбоев
.
Журнализация
изменений
базы
данных
Как
уже
говорилось
выше
,
обеспечение
надежности
хранения
данных
с
помощью
механизма
управления
транзакциями
предполагает
восстановление
согласованного
состояния
данных
после
любого
нарушения
возможности
корректного
завершения
транзакции
из
-
за
возникновения
ошибок
в
ходе
ее
выполнения
,
аппаратных
или
программных
сбоев
системы
.
Очевидно
,
что
восстановление
исходного
согласованного
состояния
базы
данных
возможно
только
при
наличии
определенной
дополнительной
информации
о
процессе
модификации
данных
в
ходе
выполнения
транзакции
.
В
современных
реляционных
СУБД
такая
дополнительная
информация
поддерживается
в
виде
специального
журнала
изменения
базы
данных
или
журнала
транзакций
.
Общими
принципами
восстановления
согласованного
состояния
данных
являются
следующие
:
•
Результаты
зафиксированных
транзакций
должны
быть
сохранены
в
восстановленном
состоянии
базы
данных
;
•
Результаты
незафиксированных
транзакций
должны
отсутствовать
в
восстановленном
состоянии
базы
данных
.
Именно
это
и
означает
,
что
восстанавливается
последнее
во
времени
согласованное
состояние
базы
данных
.
Возможны
следующие
ситуации
,
при
которых
должно
производиться
восстановление
прежнего
состояния
базы
данных
.
Индивидуальный
откат
транзакции
.
Откат
транзакции
может
быть
инициирован
при
выполнении
транзакции
путем
подачи
команды
ROLLBACK
.
Например
,
откат
транзакции
может
быть
инициирован
самой
СУБД
в
случае
возникновения
какой
-
либо
ошибки
(
деление
на
ноль
и
др
.),
или
при
выборе
транзакции
в
качестве
«
жертвы
»
при
обнаружении
ситуации
синхронизационного
тупика
(
см
.
ниже
).
При
индивидуальном
откате
транзакции
для
восстановления
согласованного
состояния
базы
данных
в
базе
данных
должны
быть
устранены
последствия
действия
операторов
модификации
базы
данных
,
которые
выполнялись
в
этой
транзакции
.
Восстановление
после
внезапной
потери
содержимого
оперативной
памяти
–
мягкий
сбой
системы
.
Такая
ситуация
может
возникнуть
при
аварийном
выключении
электрического
питания
,
при
возникновении
158
неустранимого
сбоя
процессора
(
например
,
срабатывания
контроля
оперативной
памяти
)
и
т
.
д
.
При
таком
сбое
данные
,
хранящиеся
на
диске
,
остаются
неповрежденными
,
но
утрачивается
содержимое
буферов
базы
данных
в
оперативной
памяти
.
Восстановление
после
отказа
внешнего
устройства
долговременного
хранения
данных
(
дисков
) –
жесткий
сбой
системы
.
Эта
ситуация
может
возникнуть
из
-
за
разрушения
структуры
записанных
на
дисках
данных
,
повреждения
поверхности
дисков
,
головок
записи
(
чтения
и
т
.
д
.).
Во
всех
трех
случаях
основой
восстановления
данных
является
избыточное
хранение
данных
.
Такая
дополнительная
,
необходимая
для
восстановления
данных
информация
записывается
в
специальном
журнале
,
и
представляет
собой
последовательность
записей
о
произведенных
в
ходе
транзакции
изменениях
базы
данных
.
Журнализация
изменений
базы
данных
тесно
связана
не
только
с
механизмом
управления
транзакциями
,
но
и
с
буферизацией
страниц
базы
данных
в
оперативной
памяти
.
Проблема
восстановления
данных
решилась
бы
гораздо
проще
,
если
бы
все
изменения
данных
сразу
же
фиксировались
во
внешней
памяти
системы
.
Такое
решение
,
однако
,
привело
бы
к
резкому
падению
эффективности
системы
из
-
за
объективно
существенной
разницы
в
скорости
доступа
к
данным
в
оперативной
памяти
и
в
устройствах
внешней
памяти
.
Буферизация
страниц
базы
данных
в
оперативной
памяти
является
единственным
реальным
способом
достижения
удовлетворительной
производительности
СУБД
.
Аналогичная
проблема
имеет
место
и
при
записи
в
журнал
транзакций
ирформации
о
том
,
какие
изменения
данных
были
осуществлены
в
ходе
транзакции
.
Немедленная
фиксация
этих
записей
во
внешней
памяти
также
привела
бы
к
существенному
замедлению
системы
.
Поэтому
записи
в
журнал
также
буферизуются
в
оперативной
памяти
:
при
нормальной
работе
системы
очередная
страница
буфера
записей
журнала
выталкивается
во
внешнюю
память
журнала
только
при
ее
полном
заполнении
записями
.
Таким
образом
,
система
поддерживает
в
оперативной
памяти
два
типа
буферов
–
буферы
страниц
базы
данных
и
буферы
журнала
транзакций
.
Страницы
базы
данных
,
содержимое
которых
в
буфере
(
в
оперативной
памяти
)
отличается
от
содержимого
страниц
во
внешней
памяти
,
называют
«
грязными
» (
dirty
)
страницами
.
Система
должна
поддерживать
список
«
грязных
»
страниц
и
обеспечивать
время
от
времени
их
выталкивание
из
оперативной
памяти
во
внешнюю
память
,
осуществляя
,
тем
самым
,
фиксацию
изменений
базы
данных
.
Очевидно
,
что
описанная
ситуация
не
порождает
проблем
при
решении
вопроса
индивидуального
отката
транзакций
,
поскольку
в
этом
случае
для
отката
транзакции
могут
быть
использованы
страницы
журнала
транзакций
расположенные
как
на
диске
,
так
и
в
буферах
оперативной
памяти
.
159
Другое
дело
–
ситуация
мягкого
сбоя
системы
,
когда
содержимое
буферов
оперативной
памяти
(
как
буферов
данных
,
так
и
буферов
журнала
)
утрачивается
.
В
этом
случае
для
обеспечения
возможности
восстановления
данных
необходимо
выполнение
определенных
правил
выталкивания
во
внешнюю
память
буферов
базы
данных
и
буферов
журнала
транзакций
.
Первым
принципом
согласованной
политики
выталкивания
буфера
журнала
и
буферов
страниц
базы
данных
является
то
,
что
запись
об
изменении
объекта
базы
данных
должна
попадать
во
внешнюю
память
журнала
раньше
,
чем
измененный
объект
оказывается
во
внешней
памяти
базы
данных
.
Соответствующий
протокол
журнализации
(
и
управления
буферизацией
)
называется
Write Ahead Log (WAL) – «
пиши
сначала
в
журнал
».
Суть
этого
протокола
состоит
в
том
,
что
,
если
требуется
вытолкнуть
во
внешнюю
память
измененный
объект
базы
данных
,
то
перед
этим
нужно
гарантировать
выталкивание
во
внешнюю
память
журнала
записи
о
его
изменении
.
Это
означает
,
что
если
во
внешней
памяти
базы
данных
содержится
объект
,
к
которому
применена
некоторая
команда
модификации
,
то
во
внешней
памяти
журнала
транзакций
содержится
запись
об
этой
операции
.
Обратное
неверно
,
если
во
внешней
памяти
журнала
содержится
запись
о
некотором
изменении
объекта
,
то
во
внешней
памяти
базы
данных
может
и
не
быть
самого
измененного
объекта
.
Вторым
принципом
является
то
,
что
при
фиксации
транзакции
,
во
внешнюю
память
журнала
должны
быть
вытолкнуты
все
записи
буфера
журнала
,
относящиеся
к
изменениям
базы
данных
,
совершенных
этой
транзакцией
.
Это
гарантирует
,
что
при
любом
сбое
,
повлекшем
потерю
содержимого
оперативной
памяти
,
в
системе
будет
возможность
восстановления
состояния
базы
данных
,
содержащего
результаты
всех
закончившихся
к
моменту
сбоя
транзакций
.
Третий
принцип
выталкивания
содержимого
буферов
связан
с
ограниченностью
объемов
буферов
базы
данных
и
журнала
транзакций
.
Периодически
или
при
наступлении
определенного
события
(
например
,
количество
страниц
в
dirty
-
списке
превысило
определенный
порог
,
или
количество
свободных
страниц
в
буфере
уменьшилось
и
достигло
критического
значения
)
система
принимает
так
называемую
контрольную
точку
.
Принятие
контрольной
точки
означает
выталкивание
во
внешнюю
память
содержимого
буферов
базы
данных
и
вместе
со
специальной
физической
записи
контрольной
точки
,
которая
представляет
собой
список
всех
осуществляемых
в
данный
момент
транзакций
.
Таким
образом
,
на
момент
контрольной
точки
,
все
изменения
базы
данных
оказываются
реально
зафиксированными
на
устройстве
внешней
памяти
.
Возможность
восстановления
последнего
согласованного
состояния
базы
данных
гарантируется
выталкиванием
при
фиксации
транзакций
во
внешнюю
память
журнала
всех
записей
об
изменении
базы
данных
этой
транзакцией
.
При
160
этом
последней
записью
в
журнал
,
производимой
от
имени
данной
транзакции
,
является
специальная
запись
о
конце
этой
транзакции
.
Рассмотрим
теперь
,
как
можно
выполнять
операции
восстановления
базы
данных
в
различных
ситуациях
,
если
в
системе
поддерживается
общий
для
всех
транзакций
журнал
с
общей
буферизацией
записей
,
поддерживаемый
в
соответствии
с
протоколом
WAL.
Индивидуальный
откат
транзакции
.
Для
того
чтобы
можно
было
выполнить
по
журналу
транзакций
индивидуальный
откат
транзакции
,
все
записи
в
журнале
относящиеся
к
данной
транзакции
связываются
в
обратный
список
.
Началом
списка
для
не
закончившихся
транзакций
является
запись
о
последнем
изменении
базы
данных
,
произведенной
данной
транзакцией
.
Для
закончившихся
транзакций
(
индивидуальные
откаты
которых
уже
невозможны
)
началом
списка
является
запись
о
конце
транзакции
,
которая
обязательно
вытолкнута
во
внешнюю
память
журнала
.
Концом
списка
всегда
служит
первая
запись
об
изменении
базы
данных
,
произведенном
данной
транзакцией
.
В
каждой
записи
имеется
уникальный
системный
номер
транзакции
,
чтобы
можно
было
восстановить
прямой
список
записей
об
изменениях
базы
данных
данной
транзакцией
.
Индивидуальный
откат
транзакции
(
речь
идет
о
не
закончившихся
транзакциях
)
выполняется
следующим
образом
:
•
Просматривается
список
записей
,
сделанных
данной
транзакцией
в
журнале
транзакций
(
от
последнего
изменения
к
первому
изменению
).
•
Выбирается
очередная
запись
из
списка
данной
транзакции
.
•
Выполняется
противоположная
по
смыслу
операция
:
вместо
операции
INSERT
выполняется
соответствующая
операция
DELETE
,
вместо
операции
DELETE
выполняется
INSERT
,
и
вместо
прямой
операции
UPDATE
обратная
операция
UPDATE
,
восстанавливающая
предыдущее
состояние
объекта
базы
данных
.
•
Любая
из
этих
обратных
операций
также
журнализируется
.
Это
необходимо
делать
,
потому
что
во
время
выполнения
индивидуального
отката
может
произойти
мягкий
сбой
,
при
восстановлении
после
которого
потребуется
откатить
такую
транзакцию
,
для
которой
не
полностью
выполнен
индивидуальный
откат
.
•
При
успешном
завершении
отката
в
журнал
заносится
запись
о
конце
транзакции
.
Восстановление
после
мягкого
сбоя
.
К
числу
основных
проблем
восстановления
после
мягкого
сбоя
является
то
,
что
одна
логическая
операция
изменения
базы
данных
может
изменять
несколько
физических
блоков
базы
данных
,
например
,
страницу
данных
и
несколько
страниц
индексов
.
Страницы
базы
данных
буферизуются
в