ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 31.03.2021
Просмотров: 1579
Скачиваний: 23
161
оперативной
памяти
и
выталкиваются
во
внешнюю
независимо
.
Вследствие
этого
,
несмотря
на
применение
протокола
WAL,
после
мягкого
сбоя
часть
набора
страниц
внешней
памяти
соответствует
объекту
до
изменения
,
а
часть
–
после
изменения
,
так
как
не
все
«
грязные
»
страницы
базы
данных
были
вытолкнуты
во
внешнюю
память
.
Состояние
внешней
памяти
базы
данных
называется
физически
согласованным
,
если
наборы
страниц
всех
объектов
согласованы
,
т
.
е
.
соответствуют
состоянию
объекта
либо
после
его
изменения
,
либо
до
изменения
.
В
журнале
транзакций
отмечаются
точки
физической
согласованности
базы
данных
,
так
называемые
контрольные
точки
–
моменты
времени
,
в
которые
во
внешней
памяти
содержатся
согласованные
результаты
операций
,
завершившихся
до
соответствующего
момента
времени
,
и
отсутствуют
результаты
операций
,
которые
не
завершились
,
и
при
этом
во
внешнюю
память
полностью
вытолкнут
буфер
журнала
транзакций
.
Такие
точки
обозначают
tpc
(
time of physical consistency
).
Последний
момент
,
когда
гарантированно
были
вытолкнуты
«
грязные
»
страницы
–
это
момент
принятия
последней
контрольной
точки
.
К
моменту
мягкого
сбоя
возможны
пять
вариантов
состояния
транзакций
по
отношению
к
моменту
последней
контрольной
точки
,
которые
представлены
на
рис
. 13.1.
Время
tpc
tf
T1
T2
T3
T4
T5
Контрольная
точка
(
время
tpc)
Отказ
системы
(
время
tf)
Рис
. 13.1.
Пять
вариантов
состояний
транзакций
к
моменту
мягкого
сбоя
.
Как
показано
на
рис
13.1,
последняя
контрольная
точка
принималась
в
момент
tpc
.
Мягкий
сбой
системы
произошел
в
момент
tf
(
time of fatal
).
162
Транзакции
T1-T5
характеризуются
следующими
свойствами
:
•
T1-
транзакция
успешно
завершена
до
принятия
контрольной
точки
.
Все
данные
этой
транзакции
сохранены
в
долговременной
памяти
–
как
записи
журнала
,
так
и
страницы
данных
,
измененные
этой
транзакцией
.
Поэтому
для
транзакции
Т
1
никаких
операций
по
восстановлению
не
требуется
.
•
T2-
транзакция
начата
до
принятия
контрольной
точки
и
успешно
завершена
после
контрольной
точки
,
но
до
наступления
сбоя
.
Записи
журнала
транзакций
,
относящиеся
к
этой
транзакции
вытолкнуты
во
внешнюю
память
.
Для
данной
транзакции
необходимо
повторить
заново
те
операции
,
которые
были
выполнены
после
принятия
контрольной
точки
.
•
Т
3-
транзакция
начата
до
принятия
контрольной
точки
и
не
завершена
в
результате
сбоя
.
Такую
транзакцию
необходимо
откатить
.
Проблема
,
однако
,
в
том
,
что
часть
страниц
данных
,
измененных
этой
транзакцией
,
уже
содержится
во
внешней
памяти
–
это
те
страницы
,
которые
были
обновлены
до
принятия
контрольной
точки
.
Следов
изменений
,
внесенных
после
контрольной
точки
в
базе
данных
нет
.
Записи
журнала
транзакций
,
сделанные
до
принятия
контрольной
точки
,
вытолкнуты
во
внешнюю
память
,
те
записи
журнала
,
которые
были
сделаны
после
контрольной
точки
,
отсутствуют
во
внешней
памяти
журнала
.
Поэтому
для
этой
транзакции
должны
быть
аннулированы
изменения
данных
,
произведенные
до
контрольной
точки
.
•
Т
4-
транзакция
начата
после
принятия
контрольной
точки
и
успешно
завершена
до
сбоя
системы
.
Записи
журнала
транзакций
,
относящиеся
к
этой
транзакции
вытолкнуты
во
внешнюю
память
журнала
.
Изменения
в
базе
данных
,
внесенные
этой
транзакцией
,
полностью
отсутствуют
во
внешней
памяти
базы
данных
.
Такую
транзакцию
необходимо
повторить
целиком
.
•
T5-
транзакция
начата
после
принятия
контрольной
точки
и
не
завершена
в
результате
сбоя
.
Никаких
следов
этой
транзакции
нет
ни
во
внешней
памяти
журнала
транзакций
,
ни
во
внешней
памяти
базы
данных
.
Для
такой
транзакции
никаких
действий
предпринимать
не
нужно
,
ее
как
бы
и
не
было
вовсе
.
Восстановление
системы
после
мягкого
сбоя
осуществляется
как
часть
процедуры
перезагрузки
системы
при
перезагрузке
системы
:
транзакции
Т
2
и
Т
4
необходимо
частично
или
полностью
повторить
,
транзакцию
Т
3-
частично
откатить
,
для
транзакций
Т
1
иТ
5
никаких
действий
предпринимать
не
нужно
.
Отметим
,
что
транзакции
,
завершившиеся
неудачно
и
,
следовательно
,
отмененные
перед
моментом
времени
tf
,
вообще
не
будут
вовлечены
в
процесс
перезагрузки
,
т
.
к
.
все
изменения
,
которые
были
произведены
в
ходе
их
выполнения
,
к
этому
моменту
уже
скомпенсированы
.
При
перезагрузке
системы
выполняются
следующие
действия
.
Создается
два
списка
транзакций
UNDO
(
отменить
)
и
REDO
(
повторить
).
В
список
UNDO
заносятся
все
транзакции
из
последней
записи
контрольной
точки
(
т
.
е
.
все
транзакции
,
выполнявшиеся
в
момент
принятия
контрольной
точки
).
163
Список
REDO
остается
пустым
.
В
нашем
случае
будет
:
UNDO
={T2, T3},
REDO
={}.
Журнал
транзакций
просматривается
вперед
,
начиная
с
записи
контрольной
точки
.
Если
в
журнале
транзакций
обнаруживается
запись
о
начале
транзакции
,
то
эта
транзакция
добавляется
в
список
UNDO
.
В
нашем
случае
эти
списки
имеют
вид
:
UNDO
={T2, T3, T4},
REDO
={}.
Заметим
,
что
следов
транзакции
Т
5
в
журнале
нет
.
Если
в
файле
регистрации
обнаруживается
запись
COMMIT
об
окончании
транзакции
,
то
эта
транзакция
добавляется
в
список
REDO
.
В
нашем
случае
будет
:
UNDO
={T2, T3, T4},
REDO
={T2, T4}.
Заметим
,
что
записи
о
конце
этих
транзакций
имеются
во
внешней
памяти
журнала
транзакций
в
соответствии
с
минимальным
требованием
выталкивания
записей
журнала
при
фиксации
транзакции
.
Когда
будет
достигнут
конец
журнала
транзакций
,
оба
списка
анализируются
.
При
этом
из
списка
UNDO
удаляются
те
транзакции
,
которые
попали
в
список
REDO
.
В
нашем
случае
будет
:
UNDO
={T3},
REDO
={T2, T4}.
После
этого
система
просматривает
журнал
транзакций
назад
,
начиная
с
момента
контрольной
точки
и
откатывая
все
транзакции
из
списка
UNDO
.
В
нашем
случае
будут
откатываться
те
операции
транзакции
Т
3,
которые
были
выполнены
до
принятия
контрольной
точки
.
Окончательно
,
система
просматривает
журнал
транзакций
вперед
,
начиная
с
момента
контрольной
точки
,
и
повторно
выполняет
все
операции
транзакций
из
списка
REDO
.
В
нашем
случае
,
система
выполнит
повторно
все
операции
транзакции
Т
4
и
те
операции
транзакции
Т
2,
которые
были
выполнены
после
принятия
контрольной
точки
.
Восстановление
после
жесткого
сбоя
При
жестком
сбое
база
данных
на
диске
нарушается
физически
.
Основой
восстановления
в
этом
случае
является
журнал
транзакций
и
архивная
копия
базы
данных
.
Архивная
копия
базы
данных
должна
создаваться
периодически
,
а
именно
с
учетом
скорости
наполнения
журнала
транзакций
.
Восстановление
начинается
с
обратного
копирования
базы
данных
из
архивной
копии
.
Затем
выполняется
просмотр
журнала
транзакций
для
выявления
всех
транзакций
,
которые
закончились
успешно
до
наступления
сбоя
(
транзакции
,
закончившиеся
откатом
до
наступления
сбоя
,
можно
не
рассматривать
).
После
этого
по
журналу
транзакций
в
прямом
направлении
повторяются
все
успешно
законченные
транзакции
.
При
этом
нет
необходимости
отката
транзакций
,
прерванных
в
результате
сбоя
,
т
.
к
.
изменения
,
внесенными
этими
транзакциями
,
отсутствуют
после
восстановления
базы
данных
из
резервной
копии
.
164
Наиболее
плохим
случаем
является
ситуация
,
когда
оказываются
физически
разрушенными
и
база
данных
,
и
журнал
транзакций
.
В
этом
случае
единственное
,
что
можно
сделать
–
это
восстановить
состояние
базы
данных
на
момент
последнего
резервного
копирования
.
Для
того
чтобы
не
допустить
возникновение
такой
ситуации
,
базу
данных
и
журнал
транзакций
обычно
располагают
на
разных
дисках
,
управляемых
физически
разными
контроллерами
.
Несколько
слов
о
производстве
архивных
копий
базы
данных
.
Самый
простой
способ
–
архивировать
базу
данных
при
переполнении
журнала
.
В
журнале
вводится
специальная
зона
,
при
достижении
которой
образование
новых
транзакций
временно
блокируется
.
Когда
все
транзакции
закончатся
,
и
,
следовательно
,
база
данных
придет
в
согласованное
состояние
,
можно
производить
ее
архивацию
,
после
чего
начинать
заполнять
журнал
заново
.
Можно
выполнять
архивацию
базы
данных
реже
,
чем
переполняется
журнал
.
При
переполнении
журнала
и
окончания
всех
начатых
транзакций
можно
архивировать
сам
журнал
.
Поскольку
такой
архивированный
журнал
,
по
сути
дела
,
требуется
только
для
воссоздания
архивной
копии
базы
данных
,
журнальная
информация
при
архивации
может
быть
существенно
сжата
.
14.
Транзакции
и
параллелизм
14.1.
Проблемы
,
возникающие
при
параллельном
выполнении
транзакций
Рассмотрим
проблемы
нарушения
целостности
данных
,
которые
могут
возникать
при
одновременном
выполнении
двух
транзакций
.
Имеются
три
основные
проблемы
параллелизма
:
1)
проблема
потери
результатов
обновления
;
2)
проблема
незафиксированной
зависимости
(
чтение
«
грязных
данных
»,
неаккуратное
считывание
);
3)
проблема
несовместимого
анализа
.
Последняя
проблема
несовместимого
анализа
включает
в
себя
еще
три
следующих
варианта
:
4)
неповторяемое
считывание
;
5)
фиктивные
элементы
(
фантомы
);
6)
собственно
несовместимый
анализ
.
Рассмотрим
,
в
чем
эти
проблемы
состоят
.
Проблема
потери
результатов
обновления
Две
транзакции
по
очереди
записывают
некоторые
данные
в
один
и
тот
же
кортеж
и
затем
фиксируют
эти
изменения
.
Транзакция
А
Время
Транзакция
В
↓
Чтение
кортежа
Р
t
1
---
↓
---
t
2
Чтение
кортежа
Р
↓
Запись
значения
Р
1
в
кортеж
Р
t
3
---
↓
---
t
4
Запись
значения
Р
2
в
кортеж
Р
↓
Фиксация
транзакции
t
5
---
↓
---
t
6
Фиксация
транзакции
↓
Результат
:
Потеря
результатов
обновления