Створення контрольних точок

Поміщається в файл журналу інформація призначена для використання в процесі відновлення системи після відмови. Одне з основних труднощів у цій схемі полягає в тому, що коли відбувається відмова, може бути яка-небудь інформація про те, наскільки далеко назад слід «відкотитися» у файлі журналу, щоб розпочати повторний прогін вже завершених транзакцій. В результаті може виявитися, що повторний прогін буде виконаний для тих транзакцій, які вже були остаточно зафіксовані в БД. Для обмеження обсягу пошуку в файлі журналу використовується технологія створення контрольних точок.

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

Контрольні точки організовуються через встановлений інтервал часу і включають виконання наступних дій:

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

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

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

8.3. МЕТОДИ ВІДНОВЛЕННЯ.

Тип процедури, яка буде використана для відновлення БД, залежить від розміру пошкоджень, які були отримані базою в результаті відмови. Розглянемо два варіанти.

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

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

Метод відкладеного оновлення і метод негайного оновлення відрізняються один від одного способом внесення оновлень у вторинну пам'ять. Крім того, ми познайомимося з альтернативним методом тіньових сторінок.

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

1. Під час транзакції в журнал міститься запис: Початок транзакції.

2. При виконанні будь-якої операції запису поміщається в файл журналу рядок містить всі зазначені вище дані (за винятком значення елементів даних до оновлення). Реально запис змін в буфері СУБД або саму БД не проводиться.

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

4. У разі скасування виконання транзакції запису журналу по цій транзакції анулюються і не виводяться на диск.

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

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

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

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

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

1. Під час транзакції в журнал міститься запис: Початок транзакції.

2. При виконанні будь-якої операції запису поміщається в файл журналу рядок містить всі зазначені вище дані.

3. Як тільки згадана вище запис буде поміщена в файл журналу, всі виконані оновлення вносяться до буфера БД.

4. У власне файли БД зміни будуть внесені при черговій розвантаженні буферів БД у вторинну пам'ять.

5. Коли транзакція завершує своє виконання, файл журналу заноситься запис: Транзакція завершена.

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

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

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

Метод тіньових сторінок. Цей метод є альтернативою описаними вище схемами відновлення, побудованим на використанні файлу журналу. Він передбачає організацію на час виконання транзакції двох таблиць сторінок – поточну і тіньову. Коли транзакція починає роботу, обидві таблиці сторінок ідентичні. Тіньова таблиця сторінок ніколи не змінюється і може бути використана для відновлення БД в разі відмови системи. В ході виконання транзакції поточна таблиця сторінок використовується для запису в БД всіх внесених змін. Після завершення транзакції поточна таблиця стає тіньовою. Метод тіньових сторінок має ряд переваг перед методами використання журналу транзакцій: виключається навантаження, пов'язана з веденням журналу транзакцій, процес відновлення відбувається значно швидше, оскільки немає необхідності в повторному прогоні або відкату операцій. Проте йому властиві й певні недоліки: фрагментація даних і необхідність періодичного виконання процедури складання сміття для повернення в систему невикористовуваних блоків пам'яті.