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