Функції відновлення

Трансакції та відновлення

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

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

Ситуація ускладнюється тим, що запис до бази даних неє нерозривною дією (що виконується за один крок), тому існує наступна ймовірність: трансакція завершена і зафіксована, але змінні, що вона внесла, не будуть реально відображені в БД, через те, що ще не досягли файлу БД

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

- визначає дискову адресу блока даних, що містить запис з первинним ключем x;

- зчитує блок даних з диску і розміщує його в буфер СУБД в оперативній пам`яті;

- копіює відомості про зарплату з буфера СУБД в змінну salary;

При записі послідовність дій наступна:

- визначає дискову адресу блоку даних, що містить запис з первинним ключем x;

- зчитує блок даних з диску і розміщує його в буфер СУБД в оперативній пам`яті;

- копіює відомості про зарплату зі змінної salary до СУБД;

- виводить блок даних з буферу СУБД в оперативній пам’яті на диск.

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

Якщо відмова системи відбудеться між записами даних до буфера і вивантаженням буферу в вторинну пам`ять, диспетчер повинен уточнити стан трансакції, що використовувалася в аварії.

Якщо трансакція вже видала команду фіксації її потрібно повторити ще раз (накатити).

Якщо трансакція ще не була зафіксована відповідно вона відміняється, відкатується (всі операції).

Типова СУБД повинна надавати наступні фіксації відновлення:

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

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

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

- диспетчер відновлення, що забезпечує відновлення положеного стану БД, після виклику;

1. Резервне копіювання виконується автоматично. Необхідність в цьому наступна – резервна копія викликається в разі псування або основної втрати БД.

2. Файл журналу містить відомості про всі трансакції і всі зміни, що вони вносять в БД.

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

3. Контрольна точка – момент синхронізації між БД і журналом реєстрації трансакцій. В цей момент всі буфери системи примусово дописуються до вторинної пам`яті.

При виникненні відмови інформація про те з якого матеріалу необхідно почати відновлення може бути відсутня. В такому випадку може бути виконаний повторний накат вже зафіксованих трансакцій. Це може викликати непогодженості. К трансакціям створюються з метою обмеження обсягу пошуку в журналі того місця з якого необхідно почати відновлення

Дата добавления: 2014-01-07