ВІДНОВЛЕННЯ НОСІЇВ

Примітка Тема відновлення носіїв являє собою щось зовсім самостійне і не має відношення до транзакцій і відновленню системи після збоїв Вона включена в дане обговорення тільки для створення повної картини

Як вже зазначалося в розділі 154, відмови носіїв – це порушення зразок поломки головок дискового накопичувача або відмови контролера дисків, коли деяка частина бази даних руйнується фізично Відновлення після такого порушення

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

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

повністю скасовані (фактично просто втрачені)

Таким чином, процедура відновлення носіїв увазі наявність в системі утиліти копіювання / відновлення (Або вивантаження / завантаження) Функція копіювання цієї утиліти використовується для створення резервної копії у встановлені моменти Такі копії можуть зберігатися або на стрічці, або на інших пристроях архівування Зовсім не обовязково, щоб вони створювалися на пристроях зберігання з прямим доступом Функція відновлення утиліти використовується в разі відмови носія для відтворення бази даних з необхідною резервної копії

152 Двофазними ФІКСАЦІЯ

Примітка При першому читанні цей розділ можна пропустити

У даному розділі коротко розглядається дуже важливе вдосконалення основної концепції фіксації / відкату транзакцій, а саме – двофазна фіксація Це засіб організації роботи потрібно в тих умовах, коли певна транзакція

може взаємодіяти з декількома незалежними диспетчерами ресурсів, кожен з яких розпоряджається власним набором відновлюваних ресурсів і підтримує власний журнал восстановленія8 Наприклад, припустимо, що транзакція, виконувана на мейнфрейми IBM, модифікує як базу даних СУБД IMS, так і базу даних СУБД DB2 (подібні транзакції застосовуються на практиці досить часто) Якщо транзакція завершується успішно, то всі виконані нею оновлення, як в базі даних СУБД IMS, так і в базі даних СУБД DB2, повинні бути зафіксовані В іншому випадку для всіх внесених оновлень повинен бути виконаний відкат Інакше кажучи, неприпустима ситуація, коли оновлення інформації в базі даних СУБД IMS зафіксовані, а для оновлень інформації в базі даних СУБД DB2 виконаний відкат, або навпаки Суть в тому, що в подібному випадку транзакція перестане бути нерозривним (виконуваної за принципом все або нічого)

Звідси випливає, що для транзакції не має сенсу виконувати, наприклад, оператор COMMIT в СУБД IMS і оператор ROLLBACK У СУБД DB2 Навіть якщо один і той же оператор буде виданий для обох СУБД, в системі все одно може статися аварійний останов

8 Зокрема, це важливо в контексті розподілених систем баз даних, а тому дане питання більш докладно розглядається в розділі 21

між завершенням цих двох операцій, і отримані результати виявляться незадовільними Замість цього транзакція повинна видати одну глобальну, або загальносистемну, команду COMMIT (або ROLLBACK) Виконанням таких глобальних операцій фіксації або відкоту управляє системний компонент, званий координатором Його завдання полягає в забезпеченні того, що обидва диспетчера ресурсів (тобто СУБД IMS і СУБД DB2 в даному прикладі) узгоджено виконають фіксацію або відкіт тих оновлень, за які вони відповідальні Більш того, він повинен забезпечувати таку гарантію навіть у тому випадку, якщо відмова системи стався до завершення всього процесу Все це досягається за рахунок використання протоколу двофазної фіксації

Нижче наведено опис послідовності роботи координатора Для спрощення приймемо припущення, що транзакція в базі даних виконана успішно, тобто видана

загальносистемна команда COMMIT, а не ROLLBACK Після отримання запиту на виконання команди COMMIT координатор здійснює описаний нижче двофазний процес

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

2&nbsp Фіксація Друга фаза настає після того, як координатор отримає відпо ствующие відповіді від усіх учасників транзакцій Спочатку він примусово вивантажує записи про завершальний транзакції у власний фізичний журнал реєстрації, реєструючи своє рішення щодо цієї транзакції Якщо все що надійшли відповіді були позитивними, координатор приймає рішення ня глобально зафіксувати дану транзакцію Якщо само вчинив хоча б один негативну відповідь, то для транзакції буде виконаний глобальний відкат Потім координатор-яким способом інформує кожного з учасників транзакції про своє рішення, і кожен учасник, згідно надійшла инструк ції, повинен локально зафіксувати транзакцію або виконати її відкат Зверни ті увагу на те, що кожен учасник повинен робити те, що йому вказав коорди о санаторії в ході виконання другої фази в цьому і полягає суть даного протоколу

Зверніть також увагу на те, що перехід від фази 1 до фази 2 починається саме з появи запису про це рішення у фізичному журналі реєстрації коорди натора

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

запис не буде виявлена, передбачається, що було прийнято рішення про відкат даної транзакції і, отже, процес так чи інакше завершиться,Примітка Слід підкреслити, що якщо координатор та учасники виконують свою роботу на різних компютерах, що типово для розподіленої системи (глава 21), то помилка в роботі координатора може привести до того, що якийсь учасник досить довго чекатиме надходження відомостей про прийняте координатором рішенні Протягом всього часу очікування будь-яке з оновлень, вироблене транзакцією в базі даних цього учасника, має бути приховане від інших транзакцій (інакше кажучи, ці оновлення повинні бути заблоковані, про що мова піде в наступному розділі) Відзначимо, що диспетчер передачі даних (Data Communications Manager), або скорочено DCдіспетчер (див розділ 2), також може розглядатися як диспетчер ресурсів в описаному вище сенсі Це означає, що повідомлення можна вважати такими ж відновлюваними ресурсами, як і саму базу даних, а диспетчер передачі даних повинен бути здатний брати участь у процесі двухфазной фіксації Для подальшого вивчення цього питання, а також загальної ідеї двухфазной фіксації зверніться до [1512]

153 ТОЧКИ ЗБЕРЕЖЕННЯ (ВІДСТУП ВІД ОСНОВНОЇ ТЕМИ)

Вище було описано, що за звичайних умов транзакції не можуть бути вкладені одна в іншу Але іноді виникає необхідність передбачити розбиття транзакцій на менші субтранзакціі Таке завдання може бути вирішена, але тільки частково, оскільки передбачена лише можливість встановлювати в процесі виконання транзакції проміжні точки збереження і надалі виконувати відкат до заздалегідь встановленої точці збереження (якщо це потрібно), щоб не відновлювати всю роботу з виконання транзакції з самого початку Механізм створення точок збереження, діючий за вказаною принципом, фактично був включений в найперші версії деяких систем, в тому числі Ingres (в комерційний програмний продукт, а не прототип) і System R Крім того, цей засіб було введено в стандарт SQL в 1999 році Але слід зазначити, що операція установки точки збереження не є аналогічної операції COMMIT оновлення, внесені в ході транзакції, все ще залишаються невидимими для інших транзакцій до тих пір, поки не буде успішно виконана операція COMMIT в поточній транзакції Додаткові відомості з цієї теми наведені в розділі 158

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*