ВІДНОВЛЕННЯ ТРАНЗАКЦІЇ

Транзакція починається з виконання оператора BEGIN TRANSACTION і закінчується виконанням оператора COMMIT або ROLLBACK Оператор COMMIT встановлює так звану точку фіксації (Яку називають такожточкою синхронізації – Syncpoint, особливо в раніше створених системах) Точка фіксації відповідає (успішному) закінченню логічної одиниці роботи і, отже, точки, в якій база даних знаходиться (або буде знаходитися після фіксації) в несуперечливою стані На противагу цьому, після виконання оператора ROLLBACK база даних знову повертається в стан, в якому вона була в момент початку обробки оператора BEGIN TRANSACTION, тобто в попередню точку фіксації

Примітка Вираз попередня точка фіксації є цілком допустимим навіть у разі виконання в програмі першої транзакції, за умови, що перший оператор BEGIN TRANSACTION за замовчуванням встановлює в програмі первісну точку фіксації Слід також зазначити, що в цьому контексті термін база даних фактично означає доступну для транзакції частину бази даних Інші транзакції можуть виконуватися паралельно з даною транзакцією і вносити зміни в інші частини бази даних Тому загальна база даних може і НЕ бути в повністю несуперечливому стані в момент фіксації конкретної транзакції Але, як описано в розділі 151, в цьому розділі не враховується можливість паралельного виконання транзакцій, оскільки таке спрощення суттєво не впливає на аналізований питання

Нижче перераховані випадки установки точки фіксації

1 Як описано в розділі 152, всі оновлення, вчинені програмою з моменту установки попередньої точки фіксації, виконані, тобто отримали статус постійних в тому сенсі, що гарантована запис їх результатів у базу даних До досягнення точки фіксації всі виконані транзакцією оновлення можуть розглядатися тільки як намічені в тому сенсі, що вони можуть бути скасовані (тобто існує можливість їх відкату) Але гарантується, що з моменту фіксації оновлення вже ніколи не буде отменено3 (це і є визначення поняття фіксації)

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

2 Втрачена вся інформація про позиціонування бази даних і зняті всі блокування кортежів Визначення поняття позиціонування бази даних в цьому контексті засноване на тому, що в будь-який заданий момент виконується програма зазвичай адресується до конкретних кортежам в базі даних (наприклад, за допомогою певних курсорів у разі мови SQL, як показано в розділі 4) Ця адресується в точці фіксації втрачається Поняття блокування кортежів розглядається в наступному розділі

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

Примітка Тут п 2 також дійсний, якщо транзакція завершується оператором ROLLBACK, а не COMMIT (за винятком зауваження про можливість збереження деякої Адресуємий і, отже, відповідного блокування кортежів) До п 1 це, безумовно, не відноситься

З усього сказаного вище випливає, що транзакції – це НЕ тільки логічні одиниці роботи, а й одиниці відновлення Це означає, що при успішному завершенні транзакції система гарантує, що виконані нею оновлення будуть існувати в базі даних постійно, навіть якщо в наступний момент в системі відбудеться аварійний останов Цілком можливо, що в системі відбудеться збій після успішного виконання оператора COMMIT, але перед тим, як оновлення будуть фізично записані в базу даних (вони все ще можуть залишатися в буфері оперативної памяті4 і, таким чином, можуть бути загублені в момент збою системи) Навіть якщо подібне відбудеться, процедура перезапуску системи все одно повинна зареєструвати ці оновлення в базі даних щоб дізнатися про те, чи дійсно ці значення були записані в базу даних, можна ознайомитися з відповідними записами в журналі (З цього випливає, що фізична запис до журналу реєстрації повинна бути внесена перед завершенням операції COMMIT Це важливе правило називається правилом випереджаючої записи в журнал – Write-ahead log rule) Процедура перезапуску дозволяє відновити будь-які успішно завершені транзакції, поновлення яких не були фізично записані у вторинну память до виникнення збою системи Отже, як і вказувалося раніше, транзакція дійсно є одиницею відновлення

Примітка У наступному розділі буде показано, що транзакції є також одиницями організації паралельної роботи

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

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

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

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

Але на практиці (як правило) жодне з цих вимог не дотримується По-перше, буфера можуть просто виявитися недостатньо великими, а це означає, що буде потрібно записувати на диск оновлення транзакції А ще до того, як відбудеться фіксація транзакції А за допомогою оператора COMMIT Така необхідність може, наприклад, виникнути у звязку з тим, що буде потрібно звільнити місце для оновлень транзакції в (в подібних ситуаціях прийнято говорити, що транзакція в витісняє транзакцію А з буферного простору) По-друге, фізична (або примусова) запис оновлень на диск під час виконання оператора COMMIT може виявитися дуже неефективною наприклад, якщо всі 100 послідовних транзакцій оновлюють один і той же обєкт, то примусовий запис означає, що має бути виконано 100 фізичних операцій запису, коли цілком достатньо однієї З цих причин у застосовуваних на практиці диспетчерах транзакцій зазвичай передбачено так зване правило конфіскації і відмови від примусової записи(Steal / no-force), а це, цілком очевидно, досить значно ускладнює реалізацію Додаткові відомості про це виходять за рамки даної книги

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

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

■ Всі інші записи журналу, що стосуються певної транзакції, повинні бути фізично внесені в журнал ще до того, як в журнал буде фізично поза сіна запис з оператором COMMIT, яка відноситься до зазначеної транзакції

■ Обробка оператора COMMIT для даної транзакції не повинна завершуватися до тих пір, поки в журнал не буде фізично внесено запис з оператором COMMIT, який ставиться до цієї транзакціі5

5 У деяких системах передбачено примусовий висновок записи журналу з оператором COMMIT на диск відразу після отримання запиту на виконання оператора COMMIT, а в інших системах відбувається очікування до тих пір (наприклад), поки буфер не заповниться, і тільки після цього виконується примусовий вивід цього запису на диск Останній з цих методів називається груповий фіксацією (Group commit) на тій підставі, що його застосування зазвичай тягне за собою одночасну фіксацію кількох транзакцій при використанні такого методу кількість операцій введення-виведення скорочується, але тривалість виконання деяких транзакцій збільшується

Властивості ACID транзакцій

Як і в [1514], можна підсумувати матеріал цього і попереднього розділів, зробивши висновок, що транзакції володіють (або повинні володіти) Чотирма важливими властивостями:нерозривністю(atomicity),  правільностью6(correctness),  ізольованістю (Isolation) і стійкістю (Durability) Цей набір властивостей прийнято називати властивостями ACID (За першими літерами їхніх англійських назв)

■&nbsp&nbsp&nbsp&nbsp Нерозривність Транзакції нерозривні (виконуються за принципом все або ні чого)

■&nbsp&nbsp&nbsp&nbsp Правильність Транзакції перетворять базу даних з однієї правильної зі стояння в інше при цьому правильність не обовязково повинна забезпечуватися на всіх проміжних етапах

■&nbsp&nbsp&nbsp&nbsp Ізольованість Транзакції ізольовані одна від іншої Таким чином, навіть якщо буде запущено безліч транзакцій, що працюють паралельно, результати будь-яких операцій оновлення, виконуваних окремої транзакцією, будуть приховані від всіх інших транзакцій до тих пір, поки ця транзакція не буде зафіксувати вана Інакше кажучи, для будь-яких окремих транзакцій А і В справедливо слідую щее твердження: транзакція А зможе отримати результати виконаних тран ЗАКЦ в оновлень тільки після фіксації транзакції в, а транзакція в смо жет отримати результати виконаних транзакцією А оновлень тільки після фіксації транзакції А

■&nbsp&nbsp&nbsp Стійкість Після того як транзакція зафіксована, виконані нею поновлення зберігаються в базі даних на постійній основі, навіть якщо надалі відбудеться аварійний останов системи

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

*

*