2. Журналізація

Однією з основних вимог до СУБД є надійність зберігання даних в зовнішній пам'яті. Під надійністю зберігання розуміється те, що СУБД повинна бути в змозі відновити останній узгоджений стан БД після будь-якого апаратного чи програмного збою. Апаратні збої зазвичай підрозділяються на два види:

- м'які збої пов'язані з раптовою зупинкою роботи комп'ютера. Зазвичай є наслідком раптового виключення живлення або "зависання" операційної системи (що особливо характерно для операційних систем Windows);

- жорсткі збої характеризуються втратою інформації на носіях зовнішньої пам'яті.

Програмні збої зазвичай виникають внаслідок помилок в програмах. Причому ці помилки можуть бути як в самій СУБД, що може привести до аварійного завершення її роботи, так і в призначеній для користувача програмі. Перший випадок можна розглядати як різновид м'якого апаратного збою. У другому випадку незавершеною залишається тільки одна транзакція.

У будь-якому випадку для відновлення інформації в базі даних необхідно мати деяку додаткову інформацію. Таким чином, для підтримки надійності зберігання даних вимагається надмірність даних. Причому та частина інформації, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримки такої надлишкової інформації є ведення журналу змін бази даних. Журнал є особливою частиною бази даних, недоступною користувачам СУБД і підтримувану з особливою ретельністю (іноді використовуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку поступають записи про усі зміни основної частини бази даних. У різних СУБД зміни бази даних журналізуються на різних рівнях: іноді запис в журналі відповідає деякій логічній операції зміни бази даних, іноді – мінімальній внутрішній операції модифікації сторінки зовнішньої пам'яті. Можуть також використовуватися одночасно обидва підходи. У усіх випадках дотримуються стратегії "попереджуючого" запису в журнал (так званого протоколу Write Ahead Log – WAL). Образно можна сказати, що ця стратегія полягає в тому, що запис про зміну будь-якого об'єкту бази даних має бути занесений в журнал до того, як буде виконана і зафіксована зміна цього об'єкту. Якщо в СУБД коректно реалізується протокол WAL, то за допомогою журналу можна вирішити усі проблеми відновлення бази даних після будь-якого збою.

Найпростіша ситуація відновлення – індивідуальний відкат транзакції. Строго кажучи, для цього не вимагається загальносистемний журнал змін бази даних. Досить для кожної транзакції підтримувати локальний журнал операцій модифікації бази даних, виконаних в цій транзакції, і проводити відкат шляхом виконання зворотних операцій, слідуючи від кінця локального журналу. У деяких СУБД так і роблять, але в більшості систем локальні журнали не підтримуються, а індивідуальний відкат транзакції виконують по загальносистемному журналу, для чого усі записи, що відносяться до однієї транзакції, зв'язують зворотним списком (від кінця до початку). При м'якому збої в зовнішній пам'яті основної частини бази даних можуть знаходитися об'єкти, модифіковані транзакціями, що не закінчилися до моменту збою, і можуть бути відсутніми об'єкти, модифіковані транзакціями, які до моменту збою успішно завершилися (унаслідок використання буферів оперативної пам'яті, вміст яких при м'якому збої пропадає). При дотриманні протоколу WAL в зовнішній пам'яті журналу повинні гарантовано знаходитися записи, що відносяться до операцій модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою являється приведення зовнішньої пам'яті основної частини бази даних в той стан, який виник би при фіксації в зовнішній пам'яті змін усіх транзакцій, що завершилися, і яке не містило б ніяких слідів незавершених транзакцій. Для того, щоб цього добитися, спочатку проводять відкат незавершених транзакцій, а потім повторно відтворюють ті операції завершених транзакцій, результати яких не відображені в зовнішній пам'яті.

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