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