Керування трансакціями. Відновлення

Трансакції
Трансакція – логічна одиниця роботи БД

Властивості трансакцій (ACID)
Атомарність (Atomicity). Трансакції атомарні – виконується все або нічого.
Узгодженість (Consistency). Трансакції переводять базу даних з одного узгодженого стану в інший узгоджений стан.
Ізольованість (Isolation). Транзакції ізольовані одна від одної.
Довговічність (Durability). Якщо трансакція успішно закінчена, виконані нею дії оновлень даних зберігаються в БД постійно, навіть якщо в наступний момент відбудеться збій.

Режими відмов
Події Бажані
Небажані Очікувані
Неочікувані

Модель системи
процесор
пам’ять диск

Бажані події: дивись документацію…
Небажані очікувані події:
Системний збій
Втрата вмісту пам’яті
Зависання -> перезавантаження
Пошкодження носія
Небажані неочікувані події
Все інше!

Режими відмов
Помилкові елементи даних
Пошкодження носія
Катастрофа
Збій системи

Менеджер трансакцій
Відповідальність за коректну поведінку трансакцій покладається на менеджер трансакцій.

Менеджер трансакцій

Базові операції трансакцій
В процесі виконання трансакція має справу з трьома адресними просторами:
простір дискових блоків, що містять елементи даних БД;
простір віртуальної або оперативної пам’яті, що керується менеджером буферів;
власний локальний адресний простір трансакції.

Базові операції трансакцій
Input (X): дисковий блок, що містить значення X копіюється в буфер оперативної пам’яті.
Output (X): копіювати блок з елементом даних X на диск
Read (x,t): копіювати елемент X в локальну змінну t трансакції
Write (x,t): копіювати X значення локальної змінної t в буфер пам’яті, що відповідає елементу X бази даних

Ключова проблема
Незакінчені трансакції
Наприклад Constraint: A=B
T1: A ← A × 2
B ← B × 2

T1: Read (A,t); t ← t×2
Write (A,t);
Read (B,t); t ← t×2
Write (B,t);
Output (A);
Output (B);
A: 8
B: 8
A: 8
B: 8
пам’ять
диск

Вирішення проблеми
Потрібна атомарність
виконати всі дії трансакції або не виконати жодної

Рішення – протоколювання
Протокол, чи журнал – це послідовність так званих записів протоколу, кожний із яких несе в собі інформацію про певну дію, що виконується трансакцією.
В протоколі можуть перемішуватись записи декількох трансакцій.

Відновлення з використання протоколу
Для усунення згубних наслідків збою системи одні трансакції будуть виконані повторно, і зміни, виконані ними й раніше збережені в БД зафіксуються заново. Іншим транзакціям прийдеться відмінити свої дії, наче ці трансакції взагалі й не активувалися.

T1: Read (A,t); t ← t×2 A=B
Write (A,t);
Read (B,t); t ← t×2
Write (B,t);
Output (A);
Output (B);
A:8
B:8
A:8
B:8
memory
disk
log
Undo logging

“Ускладнення”
Журнал пишеться спочатку в пам’ять
Не пишеться на диск при кожній дії memory
DB
Log
A: 8 16
B: 8 16
Log:
A: 8
B: 8

“Ускладнення”
Журнал пишеться спочатку в пам’ять
Не пишеться на диск при кожній дії memory
DB
Log
A: 8 16
B: 8 16
Log:
A: 8
B: 8
...

Правила протоколювання в режимі Undo
Для кожної дії створювати запис журналу, що містить старе значення елементу даних
U1 Якщо трансакція Т змінює елемент x, запис журналу виду
повинен бути занесений в протокол до збереження нового значення на диску (write ahead logging:WAL)
U2 При фіксації результатів трансакції Т запис
слід заносити в протокол тільки після «скидання» всіх змінених елементів БД на диск, причому інтервал між дисковими операціями і записом
повинен бути як найменшим.

Відновлення: протокол Undo
Перша задача менеджера відновлення полягає в розподілі всіх трансакцій, згаданих в журналі, по двом категоріям – зафіксовані й незафіксовані.
Менеджер відновлення повинен здійснювати сканування журналу, починаючи з кінця і рухатись до початку.

Відновлення: протокол Undo
Для кожної Ti із записом
в журналі:
- If
or
in log, do nothing
- Else For all
in log:
write (X, v)
output (X )
Write
to log

Відновлення: протокол Undo
(1) Дано S = множина транзакцій в журналі з start>, але без
(або
), тобто незакінчені
(2) Для кожної
в журналі,
в зворотному порядку (останні → ранні) виконати:
- if Ti ∈ S then - write (X, v)
- output (X)
(3) Для кожної Ti ∈ S виконати
- записати
в журнал

Питання
Чи можна зробити запис
(крок 3) в будь-якій послідовності?
Наприклад: T1 і T2 обидві пишуть A
T1 виконується перед T2
T1 і T2 обидві rolled-back
записаний, а
- ні
T1 write A
T2 write A
time/log

Питання
Що буде коли відбудеться збій під час виконання відновлення?

Введення контрольних точок
Для введення контрольної точки системі потрібно:
Призупинити прийом запитів на активізацію нових трансакцій.
Дочекатися, поки всі діючі трансакції не виконають операції фіксації чи переривання і не занесуть в журнал записи
або
.
Здійснити «скидання» журналу на диск командою flush log.
«Скинути» всі буфери на диск
Занести в протокол запис виду
.
Відновити прийом запитів.
Недоліки?

Динамічне введення контрольних точок
Внести в протокол запис
і через команду flush log «скинути» протокол на диск; T1…Tn - всі активні трансакції на момент введення контрольної точки
Дочекатися моменту фіксації або переривання всіх трансакцій з T1…Tn не забороняючи можливості старту нових трансакцій.
При завершенні всіх трансакцій з T1…Tn зберегти в протоколі запис
і виконати flush log.

Динамічні контрольні точки
L
O
G
чекаємо
завершення
трансакцій
Start-ckpt
active TR:
Ti,T2,...
end
ckpt
...
...
...

Відновлення з використанням контрольних точок
Якщо спочатку менеджеру відновлення зустрівся запис виду CKPT>, це свідчить про те, що всі незавершені трансакції почалися після процедури введення контрольної точки, тобто знаходяться після запису
. Тому достатньо здійснити сканування до запису
.

Відновлення з використанням контрольних точок
Якщо першим зустрівся запис
, значить, збій відбувся в період виконання процедури введення контрольної точки. Незавершеними будуть тільки ті трансакції із числа T1…Tn , які не встигли здійснити фіксацію своїх результатів до виникнення ситуації відмови.

20>

Протоколювання в режимі REDO
Для кожної дії створювати запис журналу, що містить нове значення елементу даних
R1 Перш ніж трансакція змінить X на дискові, необхідно внести в протокол всі записи оновлення X, включаючи запис оновлення
і запис фіксації

Протоколювання в режимі REDO
T1: Read(A,t); t t×2; Write (A,t);
Read(B,t); t t×2; Write (B,t);
Output(A); Output(B)
A: 8
B: 8
A: 8
B: 8
memory
DB
LOG

Відновлення: протокол REDO
Ідентифікувати всі завершені трансакції
Сканувати протокол в напрямку від початку до кінця. Зустрівши запис
:
ігнорувати його, якщо Т – незавершена
зберегти на дискові значення v для елемента x, якщо трансакція Т завершена.
Для кожної незавершеної трансакції Т зберегти в журналі запис
Виконати команду flush log

Відновлення: протокол REDO
Для кожної Ti з
в журналі:
Для всіх v> в журналі:
Write(X, v)
Output(X)

Відновлення: протокол REDO
Дано S = множина трансакцій з
в журналі
Для кожної
в журналі, в порядку появи (ранні →останні) виконати:
- if Ti ∈ S then Write(X, v)
Output(X)

Введення контрольних точок
Внести в журнал запис виду
, де - T1…Tn всі активні (незафіксовані) трансакції і виконати «скидання» протоколу на диск командою flush log.
Зберегти на дискові значення всіх елементів бази даних, змінених в буферах пам’яті, але не записаних на диск тими трансакціями, які на момент включення в журнал запису
виявилися завершеними.
Зберегти в протоколі запис
і виконати flush log

START>

Відновлення: протокол REDO
Якщо спочатку менеджеру відновлення зустрівся запис виду
, це свідчить про те, що всі зміни, внесені трансакціями, які закінчилися до відповідного запису
записані на диск і їх відновлювати не потрібно.

Відновлення: протокол REDO
Але будь-яка трансакція зі списку T1…Tn, можливо ще не встигла записати дані на диск, навіть якщо в журналі є запис
. Тому для відновлення потрібно розглянути трансакції зі списку T1…Tn або ті, які стартували після процедури введення контрольної точки.

Відновлення: протокол REDO
Якщо першим зустрівся
. В такому випадку неможливо гарантувати, що всі трансакції, завершені на момент внесення
, змогли зберегти свої оновлення даних на диск. Тому треба перейти до попереднього
, знайти відповідний йому запис
, а потім повторити збереження результатів оновлень всіх зафіксованих трансакцій Sj зі або тих, які стартували після внесення а протокол

Протоколювання: undo/redo
Режим undo вимагає, щоб змінені дані зберігалися на диску безпосередньо по закінченню трансакції.
Режим redo передбачає зберігання модифікованих блоків даних в буферах до моменту, поки трансакція не буде зафіксована і записи протоколу не будуть “скинуті” на диск.

Протоколювання: undo/redo
Перш ніж трансакція Т зможе модифікувати елемент Х бази даних на диску, необхідно записати в журнал на диску запис оновлення

Відновлення: undo/redo
Повторити операції всіх зафіксованих трансакцій в порядку від ранніх до останніх.
Відмінити результати всіх незавершених трансакцій в зворотному порядку.

Введення контрольних точок
Внести в протокол запис виду
і виконати “скидання” протоколу на диск командою flush log.
Зберегти на диску інформацію всіх буферів, що містять “бруд”, тобто змінені значення, не “скинуті” на диск.
Зберегти в журналі запис
і виконати команду flush log