Лекція № 13
Транзакції і поновлення даних. – 2 год
Причини і мета журналізації
Відновлення транзакцій
Види відновлення транзакцій
Журналізація та буферизація
Індивідуальний відкат транзакції .
Поновлення після м'якого збою
Поновлення після жорсткого збою збою(Пушніков, гл. 11)
Транзакції і відновлення даних
1. Причини і мета журналізації
Головна вимога довговічності даних транзакцій полягає в тому, що дані зафіксованих транзакцій повинні зберігатися в системі, навіть якщо в наступний момент відбудеться збій системи. Здавалося б, найпростіший спосіб забезпечити таку гарантію - це під час кожної операції відразу записувати всі зміни на дискові носії. Такий спосіб не є задовільним, тому що є істотне розходження у швидкості роботи з оперативної і з зовнішньою пам'яттю. Єдиний спосіб досягти прийнятної швидкості роботи полягає в буферизаціїи сторінок бази даних в оперативній пам'яті. Це означає, що дані попадають у зовнішню довгострокову пам'ять не відразу після внесення змін, а через якийсь (досить великий) час. Проте, дещо в зовнішній пам'яті повинне залишатися, тому що інакше нівідкіля одержати інформацію для відновлення.
Вимога атомарності транзакцій стверджує, що не закінчені чи транзакції, які відкотилися, не повинні залишати слідів у базі даних. Це означає, що дані повинні зберігатися в базі даних з надмірністю, що дозволяє мати інформацію, по якій відновлюється стан бази даних на момент початку невдалої транзакції. Таку надмірність звичайно забезпечує журнал транзакцій. Журнал транзакцій містить деталі всіх операцій модифікації даних у базі даних, зокрема, старе і нове значення модифікованого об'єкта, системний номер транзакції, що модифікував об'єкт і інша інформація.
Загальною метою журналізації змін баз даних є забезпечення можливості відновлення узгодженого стану бази даних після будь-якого збою. Оскільки основою підтримки цілісного стану бази даних є механізм транзакцій, журналізація і відновлення тісне зв'язані з поняттям транзакції. Загальними принципами відновлення є наступні:
результати зафіксованих транзакцій повинні бути збережені у відновленому стані бази даних;
результати незафіксованих транзакцій повинні відсутнє у відновленому стані бази даних.
Це, власне, і означає, що відновлюється останній за часом узгоджений стан бази даних.
2. Відновлення транзакцій
2.1. Види відновлення даних
Відновлення бази даних може провадитися в наступних випадках:
Індивідуальне відкочення транзакції. Відкочення індивідуальної транзакції може бути ініційований або самою транзакцією шляхом подачі команди ROLLBACK, або системою. СУБД може ініціювати відкочення транзакції у випадку виникнення якої-небудь помилки в роботі транзакції (наприклад, розподіл на нуль) чи якщо ця транзакція обрана за жертву при усуненні тупика.
М'який збій системи (аварійне відмовлення програмного забезпечення). М'який збій характеризується втратою оперативної пам'яті системи. При цьому уражаються всі транзакції, що виконуються в момент збою , губиться уміст усіх буферів бази даних. Дані, що зберігаються на диску, залишаються неушкодженими. М'який збій може відбутися, наприклад, у результаті аварійного відключення електричного живлення чи в результаті непереборного збою процесора.
Жорсткий збій системи (аварійне відмовлення апаратури). Жорсткий збій характеризується ушкодженням зовнішніх носіїв пам'яті. Жорсткий збій може відбутися, наприклад, у результаті поломки головок дискових накопичувачів.
В усіх трьох випадках основою відновлення є надмірність даних, забезпечувана журналом транзакцій. Ці надлишкові дані зберігаються в журналі, що містить послідовність записів про зміну бази даних.
Можливі два основних варіанти ведення журнальної інформації. У першому варіанті для кожної транзакції підтримується окремий локальний журнал змін бази даних цієї транзакцією. Ці локальні журнали використовуються для індивідуальних відкотів транзакцій і можуть підтримуватися в оперативній (вірніше сказати, у віртуальній) пам'яті. Крім того, підтримується загальний журнал змін бази даних, використовуваний для відновлення стану бази даних після м'яких і жорстких збоїв.
Цей підхід дозволяє швидко виконувати індивідуальні відкоти транзакцій, але приводить до дублювання інформації в локальних і загальних журналах. Тому частіше використовується другий варіант - підтримка тільки загального журналу змін бази даних, що використовується і при виконанні індивідуальних відкотів. Далі ми розглядаємо саме цей варіант.
2.2. Журналізація і буферизація
Журналізація змін тісно зв'язана не тільки з управлінням транзакціями, але і з буферизацією сторінок бази даних в оперативній пам'яті. З причин об'єктивно існуючої різниці у швидкості роботи процесорів і оперативної пам'яті і пристроїв зовнішньої пам'яті (ця різниця у швидкості існувала, існує і буде існувати завжди) буферизація сторінок бази даних в оперативній пам'яті - єдиний реальний спосіб досягнення задовільної ефективності СУБД. Якби запис про зміну бази даних, що повинна надійти в журнал при виконанні будь-якої операції модифікації бази даних, реально негайно записувався б у зовнішню пам'ять, це призвело б до істотного уповільнення роботи системи. Тому записи в журнал теж буферизуються: при нормальній роботі чергова сторінка виштовхується в зовнішню пам'ять журналу тільки при повному заповненні записами.
Як і сторінки бази даних, дані з журналу транзакцій не записуються відразу на диск, а попередньо буферизируються в оперативній пам'яті. Таким чином, система підтримує два види буферів - буфери сторінок бази даних і буфери журналу транзакцій.
Сторінки бази даних, вміст яких у буфері (в оперативній пам'яті) відрізняється від вмісту на диску, називаються "брудними" (dirty) сторінками. Система постійно підтримує список "брудних" сторінок - dirty-список. Запис "брудних" сторінок з буфера на диск називається виштовхуванням сторінок у зовнішню пам'ять. Очевидно, необхідно передбачити такі правила виштовхування буферів бази даних і буферів журналу транзакцій, що забезпечували б дві вимоги:
Максимальну швидкість виконання транзакцій. Для цього необхідно виштовхувати сторінки як можна рідше. В ідеалі, якщо оперативна пам'ять була б нескінченною, і збої ніколи б не відбувалися, найкращим виходом було би завантаження всієї бази даних в оперативну пам'ять, робота з даними тільки в оперативній пам'яті, і запис змінених сторінок на диск тільки в момент завершення роботи всієї системи.
Гарантію того, що при виникненні збою (будь-якого типу), дані завершених транзакцій можна було б відновити, а дані незавершених транзакцій безвісти видалити, тобто забезпечення відновлення останнього узгодженого стану бази даних. Для цього щось виштовхувати на диск усе-таки необхідно, навіть якщо ми мали би нескінченну оперативну пам'ять.
Таким чином, мається дві причини для періодичного виштовхування сторінок у зовнішню пам'ять - нестача оперативної пам'яті і можливість збоїв. Є два види буферів - буфер журналу і буфер сторінок оперативної пам'яті, що містять зв'язану інформацію. виштовхуватися в зовнішню пам'ять можуть і ті, і інші буфери. Проблема полягає у виробленні деякої загальної політики виштовхування, що забезпечувала б можливості відновлення стану бази даних після збоїв.
Проблема не виникає при індивідуальних відкоченнях транзакцій, оскільки в цих випадках вміст оперативної пам'яті не втрачено і можна користатися вмістом як буфера журналу, так і буферів сторінок бази даних. Але якщо відбувся м'який збій, і вміст буферів утрачений, для проведення відновлення бази даних необхідно мати деякий узгоджений стан журналу і бази даних у зовнішній пам'яті.
Основним принципом погодженої політики виштовхування буфера журналу і буферів сторінок бази даних є те, що запис про зміну об'єкта бази даних повинна потрапляти в зовнішню пам'ять журналу раніш, ніж змінений об'єкт виявляється в зовнішній пам'яті бази даних. Відповідний протокол журналізації (і управління буферизацією) називається Write Ahead Log (WAL) - "пиши спочатку в журнал", і полягає в тому, що якщо потрібно виштовхнути в зовнішню пам'ять змінений об'єкт бази даних, то перед цим потрібно гарантувати виштовхування в зовнішню пам'ять журналу запису про його зміну. Це означає, що якщо в зовнішній пам'яті бази даних міститься об'єкт, до якого застосована деяка команда модифікації, то в зовнішній пам'яті журналу транзакцій міститься запис про цю операцію. Зворотне невірно - якщо в зовнішній пам'яті журналу міститься запис про деяку зміну об'єкта, то в зовнішній пам'яті бази даних може і не бути самого зміненого об'єкта.
Додаткова умова на виштовхування буферів накладається тою вимогою, що кожна успішно завершена транзакція повинна бути реально зафіксована в зовнішній пам'яті. Який би збій не відбувся, система повинна могти відновити стан бази даних, що містить результати всіх зафіксованих до моменту збою транзакцій.
Третьою умовою виштовхування буферів є обмеженість обсягів буферів бази даних і журналу транзакцій. Періодично чи при настанні певної події (наприклад, кількість сторінок у dirty-списку перевищило певний порог, чи кількість вільних сторінок у буфері зменшилася і досягла критичного значення) система приймає так називану контрольну точку. Прийняття контрольної точки включає виштовхування в зовнішню пам'ять вмісту буферів бази даних і спеціальний фізичний запис контрольної точки, що являє собою список усіх здійснюваних у даний момент транзакцій.
Виявляється, що мінімальною вимогою, що гарантує можливість відновлення останнього узгодженого стану бази даних, є виштовхування при фіксації транзакції в зовнішню пам'ять журналу всіх записів про зміну бази даних цієї транзакцією. При цьому останнім записом у журнал, зробленим від імені даної транзакції, є спеціальний запис про кінець цієї транзакції.
Розглянемо тепер, як можна виконувати операції відновлення бази даних у різних ситуаціях, якщо в системі підтримується загальний для всіх транзакцій журнал із загальною буферизацией записів, підтримуваний відповідно до протоколу WAL.
2.3. Індивідуальне відкочення транзакції
Для того, щоб можна було виконати по журналі транзакцій індивідуальне відкочення транзакції, усі записи в журналі від даної транзакції зв'язуються в зворотний список. Початком списку для транзакцій, які не закінчилися, є запис про останню зміну бази даних, зроблену даною транзакцією. Для транзакцій, що закінчилися (індивідуальні відкочення яких уже неможливі), початком списку є запис про кінець транзакції, що обов'язково виштовхнутий у зовнішню пам'ять журналу. Кінцем списку завжди служить перший запис про зміну бази даних, зробленому даної транзакцією. У кожному записі є унікальний системний номер транзакції, щоб можна було відновити прямий список записів про зміни бази даних даною транзакцією.
Індивідуальне відкочення транзакції виконується в такий спосіб:
Проглядається список записів, зроблених даною транзакцією в журналі транзакцій (від останньої зміни до першої зміни).
Вибирається черговий запис зі списку даної транзакції.
Виконується протилежна за змістом операція: замість операції INSERT виконується відповідна операція DELETE, замість операції DELETE виконується INSERT, і замість прямої операції UPDATE зворотна операція UPDATE, що відновлює попереднє стан об'єкта бази даних.
Кожна з цих зворотних операцій також журнализируются. Це необхідно робити, тому що під час виконання індивідуального відкочення може відбутися м'який збій, при відновленні після якого буде потрібно відкотити таку транзакцію, для якої не повністю виконане індивідуальне відкочення.
При успішному завершенні відкоченняа в журнал заноситься запис про кінець транзакції.
2.4. Відновлення після м'якого збою
До числа основних проблем відновлення після м'якого збою відноситься те, що одна логічна операція зміни бази даних може змінювати кілька фізичних блоків бази даних, наприклад, сторінку даних і кілька сторінок індексів. Сторінки бази даних буферизуються в оперативній пам'яті і виштовхуються незалежно. Незважаючи на застосування протоколу WAL, після м'якого збою набір сторінок зовнішньої пам'яті бази даних може виявитися неузгодженим, тобто частина сторінок зовнішньої пам'яті відповідає об'єкту до зміни, частина - після зміни. До такого стану об'єкта не застосовні операції логічного рівня.
Стан зовнішньої пам'яті бази даних називається фізично погодженим, якщо набори сторінок всіх об'єктів погоджені, тобто відповідають стану об'єкта або після його зміни, або до зміни.
Будемо вважати, що в журналі відзначаються точки фізичної узгодженості бази даних - моменти часу, у які в зовнішній пам'яті містяться узгоджені результати операцій, що завершилися до відповідного моменту часу, і відсутні результати операцій, що не завершилися, а буфер журналу виштовхнуть у зовнішню пам'ять. Назвемо такі точки tc (time of physical consistency).
Незважаючи на протокол WAL, після м'якого збою не усі фізичні сторінки бази даних містять змінені дані, тому що не всі "брудні" сторінки бази даних були виштовхнуті в зовнішню пам'ять. Останній момент, коли гарантовано були виштовхнуті "брудні" сторінки - це момент прийняття останньої контрольної точки. Тоді до моменту м'якого збою можливі наступні 5 варіантів стану транзакцій стосовно моменту останньої контрольної точки і до моменту збою:

П'ять варіантів транзакцій
Остання контрольна точка приймалася в момент tc. М'який збій системи відбувся в момент tf. Транзакції T1-T5 характеризуються наступними властивостями:
T1 - транзакція успішно завершена до прийняття контрольної точки. Усі дані цієї транзакції збережені в довгостроковій пам'яті (у зовнішній пам'яті БД)- як записи журналу, так і сторінки даних, змінені цієї транзакцією. Для транзакції T1 ніяких операцій по відновленню не потрібно.
T2 - транзакція почата до прийняття контрольної точки й успішно завершена після контрольної точки, але до настання збою. Записи журналу транзакцій, що стосуються цієї транзакції виштовхнуті в зовнішню пам'ять. Сторінки даних, змінені цієї транзакцією, тільки частково виштовхнуті в зовнішню пам'ять. Для транзакції T2 потрібно повторити заново ті операції, які були виконані після прийняття контрольної точки, тобто повторно виконати частину операцій, що залишилася, (redo). Дійсно, у зовнішній пам'яті цілком відсутні сліди операцій, що виконувалися в транзакції T2 після моменту tc. Отже, повторна пряма інтерпретація операцій T2 коректна і приведе до логічно погодженого стану бази даних (оскільки транзакція T2 успішно завершилася до моменту м'якого збою, у журналі містяться записи про всі зміни, зроблені цієї транзакцією).
T3 - транзакція почата до прийняття контрольної точки і не завершена в результаті збою. Таку транзакцію треба відкотити. Але проблема в тому, що в зовнішній пам'яті вже міститься частина сторінок даних, змінених цією транзакцією, - це ті сторінки, що були обновлені до прийняття контрольної точки. Слідів змін, внесених після контрольної точки, в базі даних немає. Записи журналу транзакцій, зроблені до прийняття контрольної точки, виштовхнуті в зовнішню пам'ять, ті записи журналу, що були зроблені після контрольної точки, відсутні в зовнішній пам'яті журналу. Тоді для транзакції T3 потрібно виконати в зворотному напрямку першу частину операцій (undo). Дійсно, у зовнішній пам'яті гарантовано присутні результати операцій T3, що були виконані до моменту tc і цілком відсутні результати операцій T3, що були виконані після моменту tc. Отже, зворотна інтерпретація операцій T3 коректна і приведе до узгодженого стану бази даних (оскільки транзакція T3 не завершилася до моменту м'якого збою, при відновленні необхідно усунути всі наслідки її виконання)
T4 - транзакція розпочата після прийняття контрольної точки tc і успішно завершена до збою системи. Записи журналу транзакцій, що відносяться до цієї транзакції, виштовхнуті в зовнішню пам'ять журналу. Зміни в базі даних, внесені цією транзакцією, цілком відсутні в зовнішній пам'яті бази даних. Таку транзакцію необхідно повторити цілком, виконавши повну повторну пряму інтерпретацію операцій (redo).
T5 - транзакція почата після прийняття контрольної точки і не завершена в результаті збою. Ніяких слідів цієї транзакції немає ні в зовнішній пам'яті журналу транзакцій, ні в зовнішній пам'яті бази даних. Для такої транзакції ніяких дій починати не потрібно, її як би і не було зовсім.
Фізична узгодженість бази даних. Для забезпечення наявності точок фізичної узгодженості бази даних, тобто відновлення стану бази даних у момент tc використовуються два основних підходи:
підхід, заснований на використанні тіньового механізму, і
підхід, у якому застосовується журналізація посторінкових змін бази даних.
Тіньовий механізм. При відкритті файлу таблиця відображення номерів його логічних блоків в адреси фізичних блоків зовнішньої пам'яті зчитується в оперативну пам'ять. При модифікації будь-якого блоку файлу в зовнішній пам'яті виділяється новий блок. При цьому поточна таблиця відображення (в оперативній пам'яті) змінюється, а тіньова - зберігається незмінною. Якщо під час роботи з відкритим файлом відбувається збій, у зовнішній пам'яті автоматично зберігається стан файлу до його відкриття. Для явного відновлення файлу досить повторно зчитати в оперативну пам'ять тіньову таблицю відображення.
У контексті бази даних тіньовий механізм використовується в такий спосіб. Періодично виконуються операції встановлення точки фізичної узгодженості бази даних (checkpoints). Для цього всі логічні операції завершуються, усі буфери оперативної пам'яті, вміст яких не відповідає вмісту відповідних сторінок зовнішньої пам'яті, виштовхуються. Тіньова таблиця відображення файлів бази даних заміняється на поточну (вірніше сказати, що поточна таблиця відображення записується на місце тіньової). Відновлення до tc відбувається миттєво: поточна таблиця відображення заміняється на тіньову (при відновленні просто зчитується тіньова таблиця відображення). Усі проблеми відновлення вирішуються, але за рахунок занадто великої перевитрати зовнішньої пам'яті.
Тіньовий механізм - це надійний, але занадто грубий засіб. Забезпечується узгоджений стан зовнішньої пам'яті в один спільний для всіх об'єктів момент часу. Насправді, досить мати набір узгоджених наборів сторінок, кожному з який може відповідати свій набір часу.
Журналізація посторінкових змін. Для досягнення такої більш слабкої вимоги поряд з логічною журналізацією операцій зміни бази даних провадиться журналізація посторінкових змін. Перший етап відновлення після м'якого збою полягає в посторінковому відкоченні логічних операцій, що не закінчилися. Подібно до того, як це робиться з логічними записами стосовно транзакцій, останнім записом про посторінкові зміни від однієї логічної операції є запис про кінець операції. Для того, щоб розпізнати, чи потребує сторінка зовнішньої пам'яті бази даних відновлення, при виштовхуванні будь-якої сторінки з буфера оперативну пам'ять у неї поміщається ідентифікатор останнього запису про посторінкову зміну цієї сторінки. Є й інші технічні нюанси.
Відновлення системи після м'якого збою. Відновлення системи після м'якого збою здійснюється як частина процедури перезавантаження системи. При перезавантаженні системи транзакції T2 і T4 необхідно частково чи повністю повторити, транзакцію T3 - частково відкотити, для транзакцій T1 і T5 ніяких дій починати не потрібно. При перезавантаженні система виконує наступні дії:
Створюється два списки транзакцій UNDO (скасувати) і REDO (повторити). У список UNDO заносяться всі транзакції з останнього запису контрольної точки (тобто всі транзакції, що виконувалися в момент прийняття контрольної точки). Список REDO залишається порожнім. У нашому випадку буде: UNDO = {T2, T3}, REDO = { }.
Починаючи з запису контрольної точки, проглядається вперед журнал транзакцій.
Якщо в журналі транзакцій виявляється запис про початок транзакції, то ця транзакція додається в список UNDO. У нашому випадку буде: UNDO = {T2, T3, T4}, REDO = { }. Помітимо, що слідів транзакції T5 у журналі транзакцій немає.
Якщо у файлі реєстрації виявляється запис COMMIT про закінчення транзакції, то ця транзакція додається в список REDO. У нашому випадку буде: UNDO = {T2, T3, T4}, REDO = {T2, T4}. Помітимо, що записи про кінець цих транзакцій є в зовнішній пам'яті журналу транзакцій відповідно до мінімальної вимоги виштовхування записів журналу при фіксації транзакції.
Коли досягається кінець журналу транзакцій, обидва списки аналізуються. При цьому зі списку UNDO видаляються ті транзакції, що потрапили в список REDO. У нашому випадку буде: UNDO = {T3}, REDO = {T2, T4}.
Після цього система переглядає журнал транзакцій назад, починаючи з моменту контрольної точки і відкочуючи всі транзакції зі списку UNDO. У нашому випадку будуть відкочуватися ті операції транзакції T3, що були виконані до прийняття контрольної точки.
Остаточно, система переглядає журнал транзакцій уперед, починаючи з моменту контрольної точки, і повторно виконує всі операції транзакцій зі списку REDO. У нашому випадку, система виконає повторно всі операції транзакції T4 і ті операції транзакції T2, що були виконані після прийняття контрольної точки.
2.5. Відновлення після жорсткого збою
При жорсткому збої база даних на диску порушується фізично. Основою відновлення в цьому випадку є журнал транзакцій і архівна копія бази даних. Архівна копія бази даних повинна створюватися періодично, а саме з урахуванням швидкості наповнення журналу транзакцій.
Відновлення починається зі зворотного копіювання бази даних з архівної копії. Потім виконується перегляд журналу транзакцій для виявлення всіх транзакцій, що закінчилися успішно до настання збою. (Транзакції, що закінчилися відкоченням до настання збою, можна не розглядати). Після цього по журналу транзакцій у прямому напрямку повторюються всі успішно закінчені транзакції (для всіх транзакцій, що закінчилися, виконуються redo, тобто операції повторно виконуються в буквальному значенні). При цьому немає необхідності відкоченняа транзакцій, перерваних у результаті збою, тому що зміни, внесеними цими транзакціями, відсутні після відновлення бази даних з резервної копії.
Насправді, оскільки жорсткий збій не супроводжується втратою буферів оперативної пам'яті, можна відновити базу даних до такого рівня, щоб можна було продовжити навіть виконання що незакінчилися транзакцій. Але звичайно це не робиться, тому що відновлення після жорсткого збою - це досить тривалий процес.
Найбільш поганим випадком є ситуація, коли зруйновані фізично і база даних, і журнал транзакцій. У випадку втрати журналу єдиним способом відновлення бази даних є повернення до архівної копії. Єдине, що вдається зробити - це відновити стан бази даних на момент останнього резервного копіювання. Звичайно, у цьому випадку не удасться отримати останній погоджений стан бази даних, але це краще, ніж нічого. Для того щоб не допустити виникнення такої ситуації, базу даних і журнал транзакцій звичайно розташовують на фізично різних дисках, керованих фізично різними контролерами.
Архівацію бази даних можна виконувати при переповненні журналу чи рідше, ніж переповняється журнал. У першому випадку в журналі вводиться так називана "жовта зона", при досягненні якої утворення нових транзакцій тимчасово блокується. Коли всі транзакції закінчаться, і отже, база даних прийде в узгоджений стан, можна робити її архівацію, після чого починати заповнювати журнал заново. В другому випадку при переповненні журналу і закінченні всіх початих транзакцій можна архивировать сам журнал. Оскільки такий архівіруваний журнал, по суті справи, потрібно тільки для відтворення архівної копії бази даних, журнальна інформація при архівації може бути істотно стиснута.
Відновлення даних і стандарт SQL
Стандарт мови SQL не містить вимоги до поновлюваності даних, залишаючи ці питання на розсуд розробників СУБД.
Висновки
Головна вимога довговічності даних транзакцій полягає в тому, що дані зафіксованих транзакцій повинні зберігатися в системі, навіть якщо в наступний момент відбудеться збій системи. Надмірність збереження даних, що дозволяє відновити систему після збою звичайно забезпечує журнал транзакцій.
Відновлення бази даних може провадитися в наступних випадках:
Індивідуальне відкочення транзакції.
М'який збій системи (аварійне відмовлення програмного забезпечення).
Жорсткий збій системи (аварійне відмовлення апаратури).
Сторінки бази даних і журналу транзакцій не записуються відразу на диск, а попередньо буферизируются в оперативній пам'яті. Сторінки бази даних, вміст яких у буфері відрізняється від вмісту на диску, називаються "брудними" (dirty) сторінками. Запис "брудних" сторінок з буфера на диск називається виштовхуванням сторінок у зовнішню пам'ять.
Основним принципом погодженої політики виштовхування буфера журналу і буферів сторінок бази даних є протокол журналізації Write Ahead Log (WAL) - "пиши спочатку в журнал".
Мінімальною вимогою, що гарантує можливість відновлення останнього узгодженого стану бази даних, є виштовхування при фіксації транзакції в зовнішню пам'ять журналу всіх записів про зміну бази даних цією транзакцією.
Індивідуальне відкочення транзакції виконується за допомогою журналу транзакцій.
Відновлення системи після м'якого збою здійснюється як частина процедури перезавантаження системи. При перезавантаженні системи транзакції проходять процедуру ідентифікації для виявлення що завершилися і перерваних у результаті збою транзакцій. Транзакції, що успішно завершилися до настання збою, і дані про які відсутні в базі даних, повторюються заново. Транзакції, що не встигли завершитися до моменту збою, і дані про які є в базі даних, відкочуються.
Відновлення системи після жорсткого збою виконується за допомогою архівної копії бази даних і журналу транзакцій.