ВІДНОВЛЕННЯ СИСТЕМИ

Система повинна бути готова до відновлення не тільки після локальних відмов, подібних виникненню умови переповнення при виконанні операції в межах певної транзакції, але і після глобальних порушень, подібних відключенню харчування Локальне порушення за визначенням впливає тільки на ту транзакцію, в якій воно, власне кажучи, і сталося Подібні порушення вже обговорювалися вище, у розділах 152 і 153 Глобальне порушення впливає відразу на всі транзакції, що виконувалися в момент його виникнення, і тому призводить до більш значних для системи наслідків У цьому і наступному розділі стисло описано, які дії необхідно виконати в процесі відновлення після глобального відмови системи Такі відмови поділяються на дві основні категорії, які описані нижче

■&nbsp&nbsp&nbsp&nbsp Відмови системи (наприклад, збої в харчуванні) впливають на всі виконуються в даний момент транзакції, але не призводять до фізичного пошкодження бази даних Відмова системи іноді також називають мяким аварійним остановом

6 У літературі (зокрема в [1514]) найчастіше замість терміна правильність (Correctness) застосовується термін сумісність (Consistency), але в цьому розділі вже було сказано, по яких причин автор воліє саме перший термін

■&nbsp&nbsp Відмови носіїв (Наприклад, поломка головки дискового накопичувача), що можуть становити загрозу для фізичного стану всієї бази даних або будь-якої її частини, здатні впливати, принаймні, на ті транзакції, які використовують пошкоджену частину бази даних Відмова носія іноді називають також жорстким аварійним остановом

У цьому розділі будуть розглянуті відмови системи, а в розділі 155 – відмови носіїв

Критичним моментом у відмові системи євтрата вмісту основної (оперативною) памяті (Зокрема, буферів бази даних) Оскільки точне стан будь-якої виконувалася в момент відмови системи транзакції залишається невідомим, така транзакція не може бути успішно завершена Тому при перезапуску системи

будь-яка така транзакція буде скасована (Тобто буде виконаний її відкат)

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

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

зліва направо)

■ Відмова системи відбувся в момент часу tf

■ Найближча до моменту tf контрольна точка була створена в момент часу tc

■ Транзакція типу Т1 успішно завершена до моменту часу tc

■ Транзакція типу Т2 розпочата до моменту tc і успішно завершена після моменту часу tc, але до моменту часу tf

■ Транзакція типу ТЗ також розпочато до моменту часу tc, але не завершена до мо менту часу tf

■ Транзакція типу Т4 розпочата після моменту часу tc і успішно завершена до моменту часу tf

■ Нарешті, транзакція типу Т5 також розпочато після моменту tc, але не завершена до моменту часу tf

Очевидно, що при перезапуску системи транзакції типів ТЗ і Т5 мають бути скасовані, а транзакції типу Т2 і Т4 – виконані повторно Відзначимо, що транзакції типу Т1 взагалі не беруть участь в процесі перезапуску, оскільки виконані ними оновлення були примусово внесені у фізичну базу даних до моменту часу tc як частина процедури створення цієї контрольної точки Зверніть увагу також на те,

Рис 1S3 Пять можливих варіантів виконання транзакцій

що транзакції, що завершилися невдало (тобто для них був виконаний відкат) до моменту часу tf, також не враховуватимуться в процесі перезапуску (поясніть, чому)

… Отже, під час перезапуску система передусім виконує описану нижче процедуру для виявлення всіх транзакцій тіповТ2-Т5

1 Створюються два списки транзакцій назвемо їх UNDO (Скасувати) і REDO (Виконан нитка повторно)

2 У список UNDO заносяться всі транзакції, згадані в останній з існую щих записів контрольної точки, a cписок REDO поки залишається порожнім

3 У журналі реєстрації пошук починається з запису контрольної точки і відбувається із дит в прямому напрямку

4 Якщо в журналі реєстрації виявлено запис BEGIN TRANSACTION із зазначенням ем про початок виконання деякої транзакції т, то ця транзакція додається в СПИСОК UNDO

5 Якщо в журналі реєстрації виявлено запис COMMIT, яка свідчить про закінчення виконання деякої транзакції т, ця транзакція переноситься зі списку UNDO В СПИСОК REDO

6 По досягненні кінця файлу журналу реєстрації списки UNDO і REDO анализи руются для виявлення, відповідно, транзакцій типів ТЗ і Т5, а також типів Т2 і Т4

Після цього система переглядає журнал реєстрації в зворотному напрямку, виконуючи відкат транзакцій зі списку UNDO, а потім знову переглядає журнал в прямому напрямку, повторно виконуючи транзакції з cnіcкa REDO

Примітка Відновлення узгодженого стану бази даних за допомогою скасування виконаних операцій іноді називається зворотним відновленням Аналогічним чином, відновлення узгодженого стану бази даних за рахунок повторного виконання вже виконаних дій називаєтьсяпрямим відновленням Необхідно враховувати, що при прямому відновленні повторне внесення оновлень

відбувається в тому порядку, в якому вони були виконані спочатку, а при зворотному відновленні скасування оновлень відбувається в зворотному порядку

Система буде готова до подальшої роботи тоді (і тільки тоді), коли така відновлювальна робота буде завершена

Алгоритм ARIES

Безумовно, наведене вище опис процедури відновлення системи надмірно упрощено7 Зокрема, слід зазначити, що у цій процедурі операції скасування внесених оновлень (звані також відкотом)виконуються перед операціями повторного внесення змін (які прийнято також називати накатом) На перших порах в багатьох системах відновлення було організовано саме таким чином, але для підвищення ефективності в сучасних системах ці дії відбуваються в зворотній послідовності У Нині в більшості систем фактично використовується схема, яка називається ARIES [1520], або інша організація роботи, дуже схожа на цю схему, в якій операції накату в дійсності здійснюються в першу чергу Виконання процедур алгоритму ARIES підрозділяється на описані нижче три основних етапи

1 Аналіз Формування списків REDO (накат) і UNDO (відкат)

2 Накат Починаючи з позиції журналу, яка визначена на етапі аналізу, віднов новление бази даних до того стану, в якому вона перебувала під час ава рийного зупину

3 Відкат Скасування результатів внесення змін тими транзакціями, фіксація яких не була виконана

Слід зазначити, що принцип накат перед відкотом передбачає повторне внесення змін, зроблених тими транзакціями, що не були зафіксовані і для цих змін надалі потрібно знову виконувати відкат Частково з цієї причини етап накату в алгоритмі ARIES часто називають повторенням історії [1521] (або повторенням колишніх помилок) Заслуговує також на увагу той факт, що в алгоритмі ARIES передбачається запис в журнал всіх операцій, виконуваних на етапі відкоту, тому, якщо в ході виконання даної процедури перезапуску знову відбудеться аварійний останов системи (а це аж ніяк не можна виключити), то оновлення, для яких вже був виконаний відкат, не будуть скасовані повторно при наступному перезапуску

Абревіатура ARIES розшифровується як Algorithms for Recovery and Isolation Exploiting Semantics (Алгоритми відновлення та ізоляції на основі семантики)

7 Крім усього іншого, в ньому передбачається, що відновлення завжди можливо Цілком очевидно, що якщо ніякі транзакції не виконувалися паралельно в момент аварії, то всі вони можуть бути відновлені Але якщо в базі даних передбачена можливість паралельного виконання транзакцій, то організація її роботи значною мірою ускладнюється і доводиться ретельно стежити за тим, щоб виконувані в ній операції виключали можливість відновлення Ця тема розглядається більш докладно в наступному розділі

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*