Транзакція як логічна одиниця роботи

Транзакція – Це логічна одиниця роботи вона починається з виконання операції BEGIN TRANSACTION і закінчується операцією COMMIT або ROLLBACK На рис 151 показаний псевдокод транзакції, яка призначена для перерахування суми 100 доларів з рахунку 123 на рахунок 456 Цілком очевидно, що операція переказу грошей з одного рахунку на інший, яка за самою своєю суттю є нерозривною, фактично вимагає виконання в базі даних двох окремих операцій оновлення Більш того, сама база даних на етапі між цими двома оновленнями знаходиться в неприпустимому стані, в тому сенсі, що вона не відображає дійсний стан справ у реальному світі цілком очевидно, що в банківській практиці переказ грошей з одного рахунку на інший не повинен впливати на сумарну кількість грошових коштів на розглянутих рахунках, а в даному прикладі після виконання першого оновлення сума в 100 дол на час зникає з

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

Рис 151 Приклад транзакції (псевдокод)

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

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

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

Компонент системи, який забезпечує таку нерозривність (або подібність нерозривності), називається диспетчером транзакцій (Для його позначення застосовуються також терміни монітор обробки транзакцій або ТР-монітор), а в основі організації його роботи лежать операції COMMIT і ROLLBACK, які описані нижче

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

■ Оператор ROLLBACK (Виконати відкат) сигналізує проневдаломузакінчення транзакції Він повідомляє диспетчеру транзакцій, що сталася якась помилка, база даних знаходиться в суперечливому стані і слід здійснити відкат всіх проведених при виконанні цієї транзакції оновлень, тобто вони повинні бути скасовані

Таким чином, у наведеному прикладі оператор COMMIT повинен бути виконаний, якщо обидва поновлення пройшли успішно, після чого внесені в базу даних зміни стануть постійними Якщо щось сталося не так, наприклад, якщо оновлення було перервано небудь умовою помилки, то виконується оператор ROLLBACK І будь-які проведені до сих пір зміни скасовуються

На підставі простого прикладу, наведеного на рис 151, можна зробити ряд важливих висновків, описаних нижче

■&nbsp&nbsp&nbsp&nbsp Неявно заданий оператор ROLLBACK У даному прикладі явно передбачено ви конання перевірок на наявність помилок і явний виклик на виконання оператора ROLLBACK у разі виявлення помилки Але не слід припускати (і саме це припущення не має сенсу), що транзакції завжди включають явно задані перевірки на випадок всіх можливих помилок Тому система повинна викликати на виконання неявно заданий оператор ROLLBACK ДЛЯ всіх транзакцій, кото риє з якоїсь причини закінчилися невдачею і не досягли етапу планового за вершенія (тут під плановим завершенням мається на увазі явно заданий опера торCOMMITІЛІROLLBACK)

■&nbsp&nbsp&nbsp&nbsp Обробка повідомлень Типова транзакція не тільки вносить (або намагається поза сти) оновлення в базу даних, але і передає кінцевому користувачеві ті чи інші повідомлення, що дозволяють йому дізнатися, що відбувається Наприклад, можна передбачити передачу повідомлення Переказ грошей з рахунку на рахунок виконаний, якщо досягнуто оператор COMMIT, або повідомлення Помилка – переказ грошей з рахунку на рахунок не виконано в іншому випадку Обробка повідомлень, в свою чергу, вимагає застосування додаткових засобів відновлення Більш під робние інформацію з цієї теми можна знайти в [1512]

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

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

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

■&nbsp&nbsp&nbsp&nbsp Нерозривність операцій Система повинна гарантувати, що виконання окремих на них операцій (весь процес їх виконання) має відбуватися нерозривно Така вимога стає особливо важливим в реляційних системах, по скільки в них операції виконуються на рівні множини і зазвичай зачіпають одночасно велику кількість кортежів, тому не можна допустити, щоб такі операції закінчувалися невдачею в ході виконання і залишали базу да них в суперечливому стані (наприклад, в такому стані, що деякі кортежі оновлені, а інші – ні) Іншими словами, якщо в ході виконання подібного оператора виникла помилка, то база даних повинна залишитися повно стю в незмінному стані Крім того, як описано в розділах 9 і 10, це умова залишається в силі, навіть якщо розглянута операція неявно вимагає виконання додаткових оновлень (наприклад, через те, що застосовується правило каскадного видалення або відбувається оновлення подання, в якому пре бачено зєднання таблиць)

■&nbsp&nbsp&nbsp&nbsp Виконання програми як послідовності транзакцій Необхідно звернути особливу увагу на те, що оператори COMMIT і ROLLBACK завершують транзак цію, а не прикладну програму Як правило, процес прогону окремої про грами складається з ряду транзакцій, які слідують одна за одною, як показу але на рис 152

■&nbsp&nbsp&nbsp&nbsp Відсутність вкладених транзакцій Якщо явно не вказано інше, то в даній главі передбачається, що в прикладній програмі оператор BEGIN TRANSACTION мо же бути викликаний на виконання, тільки якщо в даний час в цій програмі не виконується небудь інша транзакція Іншими словами, транзакція не може містити в собі вкладену транзакцію Але необхідно відзначити, що в наступному розділі це припущення буде переглянуто

■&nbsp&nbsp&nbsp&nbsp Допустимість За визначенням база даних повинна завжди перебувати, по мен шою мірою, в несуперечливою стані Під поняттям несуперечності, згідно чолі 9 (а також загальноприйнятій тлумачення цього терміна), ми подра зумевает відсутність порушень будь-яких відомих обмежень цілісності Слід також зазначити, що несуперечність бази даних, розглянута з точки зору такого визначення даного терміну, забезпечується засобами самої СУБД З цього випливає (також за визначенням), що транзакції завжди пе РЕВОД базу даних з одного несуперечливого стану в інший Але однією

несуперечності недостатньо база даних має відповідати вимогам допустимості, а не тільки несуперечності Наприклад, у разі транзакції, показаної на рис 151, потрібно, щоб сумарна кількість грошей на рахунках 123 і 456 в результаті транзакції не змінилося Але було б нерозумно ставити перед собою завдання з підготовки обмеження цілісності, яке відповідало б такій вимозі (Поясніть, чому), і тому не можна розраховувати на те, що СУБД зможе стежити за дотриманням даної вимоги Насправді, як уже було сказано в розділі 9, несуперечливість не має на увазі правильність Тому, на жаль, все, що ми можемо зробити (і чого ми взагалі можемо добитися за допомогою СУБД), це просто прийняти припущення, що транзакції є правильними, в тому сенсі, що вони достовірно відображають лише ті операції реального світу, які були реалізовані за їх допомогою Точніше, ми припускаємо, що якщо т – транзакція, яка переводить базу даних зі стану D1 в стан D2 і стан D1 є правильним, то D2 також є правільним2 Але ще раз відзначимо, що це бажане властивість не може бути забезпечено самою системою (як було зазначено в розділі 9, система може забезпечити не істинність, а тільки несуперечність)

Рис 152 Діаграма, на якій процес виконання програми показаний як ряд транзакцій

■ Множинне присвоювання Як було зазначено в розділі 5 (відповідно з доводами, наведеними в [33]), в базі даних необхідно передбачити підтримку множинної форми присвоювання, яка дозволяє виконувати одночасно будь-яку кількість окремих операцій привласнення (тобто оновлень) Наприклад, дві окремі операції UPDATE, показані на рис 151, можуть бути замінені наступним одним оператором (зверніть увагу на застосовуваний в ньому роздільник у вигляді коми)

2 Слід також звернути особливу увагу на те, що це твердження має поширюватися на всі можливі правильні стану D1 Очевидно, що транзакція Т може фактично не «достовірно відображати лише ті операції реального світу, які були за допомогою неї реалізовані , і разом з тим забезпечувати перехід в правильний стан D2 з деякого конкретного стану D1 Але нас це не цілком влаштовує, оскільки правильність транзакції має бути гарантованою, а не бути просто результатом випадкового збігу обставин

UPDATE ACC 123 { BALANCE := BALANCE $100

} , UPDATE ACC 456 { BALANCE := BALANCE +

$100 }

Тепер ця транзакція буде включати тільки одну операцію оновлення, тому її вплив на базу даних буде нерозривним з визначення і оператори BEGIN TRANSACTION, COMMIT і ROLLBACK більше не будуть потрібні (Принаймні, в даному конкретному випадку) Але, як було зазначено в розділі 5, сучасні програмні продукти не підтримують множинне присвоювання (або підтримують цю операцію не повністю) Тому з практичних міркувань до кінця даної глави можливість застосування множинного присвоювання не розглядається (Безумовно, при проведенні оригінальної дослідницької роботи, присвяченої транзакціях, можливість застосування множинного присвоювання фактично навіть не розглядалася Додаткова інформація на цю тему приведена в розділі 1610)

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

*

*