|
БАЗИ ДАНИХ. МОВИ ЗАПИТІВ, УПРАВЛІННЯ ТРАНЗАКЦІЯМИ, РОЗПОДІЛЕНА ОБРОБКА ДАНИХ |
|
2.6 Механізми відновлення бази даних
2.6.1
Функції СКБД по відновленню бази даних
2.6.1 Функції СКБД по відновленню бази даних
Відновлення бази даних – це процес повернення бази даних в прийнятний стан, втрачений в результаті збою чи відмови. Типова СКБД повинна надавати такі функції відновлення: 1. Механізм резервного копіювання, призначений для періодичного створення резервних копій бази даних. 2. Засоби ведення журналу транзакцій, в якому фіксується поточний стан транзакцій і зміни, які вони вносять у базу даних. 3. Функція створення контрольних точок, яка забезпечує перенесення виконуваних в базі даних змін у вторинну пам’ять з метою зробити їх постійними. 4. Диспетчер відновлення, що забезпечує відновлення узгодженого стану бази даних, порушеного в результаті відмови. Резервна копія бази даних використовується у випадку пошкодження або руйнування файлів бази даних у вторинній пам’яті. Резервне копіювання може виконуватись для всієї бази даних в цілому або для зміненої її частини (тобто інкрементно). В останньому випадку в копію поміщаються відомості лише про зміни, що накопичились з моменту створення попередньої повної або інкрементної резервної копії системи. Після того, як буде відновлена остання резервна копія, необхідно виконати накат всіх зафіксованих транзакцій, відомості про які містяться в журналі транзакцій. Безумовно, припускається, що сам журнал транзакцій не був пошкодженим. Тому рекомендується, щоб у всіх випадках, коли це можливо, файл журналу транзакцій створювався на дискових накопичувачах, відмінних від тих, де розміщені основні файли бази даних. Якщо ж база даних не отримала фізичних пошкоджень, а лише втратила узгодженість розміщених у ній даних (наприклад, в результаті аварійної зупинки системи в процесі обробки транзакцій), то достатньо виконати відкат тих змін, які спричинили перехід бази даних в неузгоджений стан. Крім того, може виникнути необхідність виконати накат деяких транзакцій, щоб внесені в них зміни були дійсно зафіксовані у вторинній памяті. В даному випадку немає необхідності звертатись до резервної копії бази даних, оскільки повернути базу даних в узгоджений стан можна за допомогою інформації з журналу транзакцій. Для повернення бази даних в узгоджений стан використовуються такі методи: метод відкладеного оновлення, метод негайного оновлення та альтернативний метод тіньового сторінкового обміну.
Журналом транзакцій називають спеціальний файл, у якому СКБД фіксує хід виконання транзакцій в базі даних. Він містить відомості про всі оновлення, що виконуються в базі даних. У файлі журналу транзакцій може міститись така інформація: - записи про транзакції, включаючи ідентифікатор транзакції; - тип запису журналу (початок транзакції, операція вставки, оновлення чи видалення, відміна чи фіксація транзакції); - ідентифікатор елемента даних, над яким виконується операція обробки (операції вставки, видалення та оновлення); - копія елемента даних до операції, тобто його значення до зміни (тільки для операцій оновлення та видалення); - копія елемента даних після операції, тобто його значення після зміни (тільки для операцій оновлення та вставки); - службова інформація файлу журналу транзакцій, яка включає покажчики на попередній та наступний запис журналу для цієї транзакції (для всі всіх операцій); - записи контрольних точок. Оскільки файл журналу транзакцій відіграє важливу роль в процесах відновлення, він може створюватися в двох і навіть трьох екземплярах, які автоматично підтримуються системою. У випадку пошкодження однієї копії при відновленні буде використовуватись інша. Файл журнала транзакцій потенційно є вузьким місцем з точки зору продуктивності будь-яких систем, тому швидкість запису інформації у файл журналу транзакцій може виявитись одним із найважливіших факторів, що визначають загальну продуктивність системи з базою даних.
2.6.3 Створення контрольних точок
Інформація з журналу транзакцій призначена для використання в процесі відновлення системи після відмови. Але при виникненні відмови може бути відсутньою інформація про те, з якого моменту в минулому необхідно почати пошук у файлі журналу транзакцій, щоб не виконувати накат транзакцій, які вже завершились з успішною фіксацією в базі даних. Для обмеження об’єму пошуку та послідовної обробки інформації у файлі журналу транзакцій використовується метод створення контрольних точок. Контрольною точкою називається момент синхронізації між базою даних та журналом транзакцій. В цей момент всі буфера системи примусово записуються у вторинну пам’ять системи. Контрольні точки організовуються через встановлений інтервал часу та передбачають виконання таких дій: - перенесення всіх наявних в оперативній пам’яті записів журналу транзакцій у вторинну пам’ять; - запис всіх модифікованих блоків у буферах бази даних у вторинну пам’ять; - поміщення у файл журналу транзакцій записів контрольної точки. Цей запис містить ідентифікатори всіх транзакцій, які були активні в момент створення контрольної точки. Якщо транзакції виконуються послідовно, то після виникнення відмови файл журналу транзакцій переглядається з метою виявлення останньої з транзакцій, яка почала свою роботу до моменту створення останньої контрольної точки. Будь-яка більш рання транзакція успішно зафіксована в базі даних, а це означає, що її зміни були перенесені на диск в момент створення останньої контрольної точки. Тому необхідно виконати накат тільки тих транзакцій, які були активні в момент створення контрольної точки, а також всіх наступних транзакцій, які почали свою роботу пізніше і для яких в журналі наявні записи як початку, так і їх фіксації. Та транзакція, яка була активна в момент відмови повинна бути відмінена. Якщо транзакції виконуються паралельно, потрібно виконати накат всіх транзакцій, які були зафіксовані з часу створення контрольної точки, та відкат всіх транзакцій, які були активні в момент аварії. Як правило, створення контрольних точок є відновно недорогою операцією, тому часто достатньо створювати три або чотири контрольні точки в годину. Таким чином, у випадку збою необхідно відновлювати роботу лише за останні 15-20 хвилин.
2.6.4 Метод відкладеного оновлення
При використанні цього методу оновлення даних не заносяться в базу даних до тих пір, поки транзакція не видасть команду фіксації виконаних змін. Якщо виконання транзакції буде припинено до досягнення цієї точки, жодних змін в базі даних виконано не буде, тому не потрібно буде їх відміняти. Однак в даному випадку може виникнути потреба у виконанні накату оновлень зафіксованих транзакцій, оскільки їх результати могли ще не досягти бази даних. При застосуванні даного методу файл журналу транзакцій використовується з метою захисту системи від аварій за таким алгоритмом: 1. При запуску транзакцій в журнал поміщається запис початку транзакції. 2. При виконанні будь-якої операції у файл журналу транзакцій заноситься уся інформація про виконану операцію за виключення значень елементів даних, які передували оновленню. При цьому реального запису змін в буфери СКБД або базу даних не відбувається. 3. Коли транзакція досягає точки фіксації, у файл журналу транзакцій заноситься запис фіксації транзакції. 4. У випадку аварійного завершення транзакції записи журналу по цій транзакції анулюються і не виводяться на диск. Слід звернути увагу на те, що записи по виконуваній транзакції виводяться на диск до того, як її результати будуть зафіксовані. Тому якщо відмова бази даних відбудеться в процесі справжнього внесення оновлень в базу даних, занесені в журнал відомості зберігаються і необхідні оновлення можна буде виконати пізніше. У випадку відмови файл журналу транзакцій аналізується з метою виявлення транзакцій, які знаходились в процесі виконання в момент відмови. Починаючи з останнього рядка файл журналу транзакцій переглядається у зворотному напрямку, аж до запису про останню виконану контрольну точку. 5. Для будь-яких транзакцій, для яких у файлі журналу транзакцій присутні записи початку транзакції та фіксації транзакції, повинен бути виконаний накат. Процедура накату транзакцій виконує всі операції запису в базу даних, використовуючи інформацію про стан елементів даних після оновлення, яка міститься в записах журналу по даній транзакції, при чому в тому порядку, в якому вони були записані у файл журналу транзакцій. Якщо ці операції запису вже були успішно завершені до виникнення відмови, це не спричинить жодного впливу на стан елементів даних, оскільки вони не можуть бути зіпсовані, якщо будуть записані ще раз. Однак такий метод гарантує, що будуть оновлені будь-які елементи даних, які не були коректно оновлені до моменту відмови. 6. Будь-яка транзакція, для якої у файлі журналу транзакцій присутні записи початку транзакції і відміни транзакції, просто ігнорується, оскільки жодних реальних оновлень інформації в базі даних по ній не виконувалось, а тому і не потрібно виконувати їх відкат. Якщо в процесі відновлення виникне інший системний збій, записи файлу журналу транзакцій можуть бути використані для відновлення бази даних ще раз. В такому випадку немає значення, скільки разів кожен з рядків журналу буде використаний для повторного внесення змін в базу даних.
2.6.5 Метод негайного оновлення
При використанні протоколу негайного оновлення всі зміни вносяться в базу даних одразу ж після їх виконання в транзакції, ще до досягнення моменту фіксації. Окрім необхідності виконання накату змін зафіксованих транзакцій одразу ж після аварії, може виникнути потреба виконати відкат змін, внесених транзакціями, які не були зафіксовані до моменту аварії. При застосуванні даного методу файл журналу транзакцій використовується з метою захисту системи від аварій за таким алгоритмом: 1. При запуску транзакцій в журнал поміщається запис початку транзакції. 2. При виконанні будь-якої операції у файл журналу транзакцій заноситься уся інформація про виконану операцію. 3. Щойно запис буде поміщений у файл журналу транзакцій, всі виконані оновлення заносяться в буфера бази даних. 4. Оновлення записуються в базу даних при кожному черговому скиданні буферів бази даних у вторинну пам’ять. 5. Після фіксації транзакцій у файл журналу транзакцій заноситься запис фіксації транзакції. Важливо, щоб всі записи заносились у файл журналу транзакцій до внесення відповідних змін в базу даних. Ця вимога відома як протокол попереднього запису журналу. Якщо зміни спочатку будуть внесені в базу даних і збій в системі виникне до занесення інформації про це у файл журналу транзакцій, то диспетчер відновлення не буде мати можливості виконати відкат (або накат) результатів даної операції. При використанні протоколу попереднього запису журналу диспетчер відновлення завжди може діяти, базуючись на тому, що якщо для визначеної транзакції у файлі журналу транзакцій відсутній запис фіксації транзакції, то транзакція вважається активною в момент виникнення відмови і тому для неї повинен бути виконаний відкат. Якщо виконання транзакції завершилось аварійно, то для відміни внесених нею змін може бути використаний файл журналу транзакцій, оскільки в ньому збережені відомості про початкові значення всіх змінених елементів даних. Враховуючи те, що транзакція може виконати декілька змін одного і того ж елемента даних, відміна операції запису виконується у зворотному порядку. Незалежно від того, чи були результати виконання транзакції внесені в базу даних, наявність в записах журналу транзакцій початкових значень елементів даних гарантує, що база даних буде приведена в стан, що відповідає початку відміненої транзакції.
2.6.6 Метод тіньового сторінкового обміну
Альтернативою згаданим вище схемам відновлення, побудованим на використанні файлу журналу транзакцій, є метод ті нього сторінкового обміну. Цей метод передбачає організацію на час виконання транзакції двох таблиць сторінок – поточної та тіньової. Коли транзакція починає свою роботу, обидві таблиці сторінок є однаковими. Тіньова таблиця сторінок в подальшому не змінюється і може бути використана для відновлення бази даних у випадку відмови системи. В ході виконання транзакції поточна таблиця сторінок використовується для реєстрації всіх змін, внесених у базу даних. Після завершення транзакції поточна таблиця сторінок стає тіньовою таблицею. Метод тіньового сторінкового обміну має ряд переваг перед методами, що використовують журнал транзакцій: - виключаються витрати, пов’язані з веденням журналу транзакцій; - процес відновлення відбувається значно швидше, оскільки немає необхідності виконувати операції накату і відкату. Однак йому властиві деякі недоліки: фрагментація даних та необхідність періодичного виконання процедури збору сміття для повернення в систему не використовуваних блоків пам’яті.
|
|
Пєтух А.М., Романюк О.В., Романюк О.Н. ВНТУ 2016 |