БД повинна потрапити в зовнішню пам'ять журналу раніше, ніж змінений об'єкт потрапить у зовнішню пам'ять основної частини БД. Відомо, що якщо в СУБД коректно дотримується протокол WAL, то за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою. p align="justify"> Найпростіша ситуація відновлення - індивідуальний відкат транзакції. Строго кажучи, для цього не потрібно загальносистемний журнал змін БД. Достатньо для кожної транзакції підтримувати локальний журнал операцій модифікації БД, виконаних у цій транзакції, і виробляти відкат транзакції, шляхом виконання зворотних операцій, слідуючи від кінця локального журналу. У деяких СУБД так і роблять, але в більшості систем локальні журнали не підтримують, а індивідуальний відкат транзакції виконують по общесистемному журналу, для чого всі записи від однієї транзакції пов'язують зворотним списком (від кінця до початку). p align="justify"> При м'якому збої в зовнішній пам'яті основної частини БД можуть знаходитися об'єкти, модифіковані транзакціями, не закінчивши до моменту збою, і можуть бути відсутні об'єкти, модифіковані транзакціями, які до моменту збою успішно завершилися (унаслідок використання буферів оперативної пам'яті, вміст яких при м'якому збої пропадає). При дотриманні протоколу WAL у зовнішній пам'яті журналу повинні гарантовано знаходитися записи, пов'язані з операціями модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою є: стан зовнішньої пам'яті основної частини БД, яке виникло б при фіксації в зовнішній пам'яті змін всіх завершилися транзакцій і яке не містило б ніяких слідів незакінчених транзакцій. Для того щоб цього домогтися, спочатку виробляють відкат незавершених транзакцій, а потім повторно відтворюють ті операції завершених транзакцій, результати яких не відображені в зовнішній пам'яті. Цей процес містить багато тонкощів, пов'язаних із загальною організацією управління буферами і журналом. p align="justify"> Для відновлення БД після жорсткого збою використовують журнал і архівну копію БД. Грубо кажучи, архівна копія - це повна копія БД до моменту початку заповнення журналу. Звичайно, для нормального відновлення БД після жорсткого
збою необхідно, щоб журнал не пропав. Як вже зазначалося, до схоронності журналу в зовнішній пам'яті в СУБД пред'являються особливо підвищені вимоги. p align="justify"> Тоді відновлення БД полягає в тому, що виходячи з архівної копії, по журналу відтворюється робота всіх транзакцій, які закінчилися до моменту збою. В принципі, можна навіть відтворити роботу незавершених транзакцій і продовжити їх роботу після завершення відновлення. Однак у реальних системах це звичайно не робиться, оскільки процес відновлення після жорсткого збою є досить тривалим. p align="justify">. Підтримка мов БД
Для роботи з базами даних використовуються спеціальні мови, в цілому...
