Основні принципи відновлення

При виникненні будь-якого апаратного або програмного збою СУБД повинна відновити останній погоджений стан БД.

Основні принципи відновлення полягають у наступному:

1) результати зафіксованих транзакцій повинні бути збережені у відновленому стані БД;

2) результати незафіксованих транзакцій повинні бути відсутніми у відновленому стані БД.

Зазначені принципи у типовій СУБД реалізуються з допомогою:

1) механізму резервного копіювання, призначеного для періодичного створення копій БД;

2) засоби ведення журналу, в якому фіксуються поточний стан транзакцій і вносяться до БД зміни;

3) функції створення контрольних точок, що забезпечує перенесення виконуваних в БД змін у вторинну пам'ять з метою зробити їх постійними;

4) менеджера відновлення, що забезпечує відновлення узгодженого стану БД, порушеного в результаті відмови.

8.2. МЕХАНІЗМ РЕЗЕРВНОГО КОПІЮВАННЯ.

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

1. Записи про транзакції.

2. Записи контрольних точок.

Записи про операції включають:

1) ідентифікатор транзакції;

2) тип записи журналу (початок транзакції, операції вставки, оновлення або видалення, скасування або фіксація транзакції);

3) ідентифікатор елемента даних, залучених в операцію обробки БД (операції вставки, видалення і оновлення);

4) копію елемента даних до операції, тобто його значення до зміни (тільки операції оновлення та видалення);

5) копію елемента даних після операції, тобто його значення після зміни (тільки для операцій оновлення і вставки);

6) службову інформацію файлу журналу, що містить покажчики на попередню і наступну запису журналу для цієї транзакції (будь-які операції);

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