Заняття 10. Транзакції

виконується як єдине ціле (все або нічого) і яка переводить

базу даних з одного цілісного стану в інший цілісний стан.
Відкат транзакції – відміна дії усіх вже виконаних інструкцій транзакції в результаті невиконання якої-небудь інструкції у цій транзакції.

Isolation – ізольованість
Durability – довговічність, стійкість

або виконується уся транзакція, або вона вся не виконується.
Тільки коли

усі оператори транзакції виконуються без помилок, результати виконання усієї транзакції зберігаються в базі.

одного цілісного стану в інший цілісний стан; всередині транзакції узгодженість

бази даних може порушуватись.
Стан цілісності бази даних підтримується на рівні обмежень різних типів.
Разом з поняттям цілісності бази даних існує поняття реакції системи на спробу порушення цілісності. Є два типи таких реакцій:
відмова виконати «незаконну операцію»; при цьому генерується повідомлення користувачу;
виконання компенсуючих дій, які полягають у виконанні додаткового коду у транзакції, який підтримує узгодженість та цілісність даних.

одна одній.
Це означає, що в багатокористувацькому режимі транзакції повинні виконуватись

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

роботи повинні зберегтись у базі даних, навіть якщо в наступний

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

(явний режим транзакції).

транзакцій (autocommit). Це означає, що як тільки виконується оператор, що

модифікує дані, MySQL тут же зберігає зміни в базі даних.
Режим автоматичного завершення транзакцій можна відключити наступним оператором: SET AUTOCOMMIT = 0;
COMMIT – завершити виконання усіх інструкцій транзакції, які виконуються послідовно в одному блоці. Застосовується тоді, коли усі SQL-оператори транзакції імовірно виконані (вони сприйняті СУБД і не викликали помилок) і вимагається підтвердити зміни, внесені у БД.
ROLLBACK (відкат) – відбувається відміна дії усіх інструкцій транзакції, і база даних повертається у вихідний стан. Застосовується тоді, коли необхідно відмінити зміни внесені транзакцією, і відновити БД у попередньому стані.

відділяються одна від іншої так званими точками відкату (мітками), які

задаються за допомогою оператора:
SAVEPOINT <ім’я т.відкату>;
Він може використовуватись разом з оператором:
ROLLBACK TO SAVEPOINT < ім’я т.відкату>;
Якщо без точки відкату оператор ROLLBACK застосовувався для відміни усієї транзакції, то тепер його можна використовувати для відміни лише тієї частини транзакції, яка розміщена між точкою відкату та ROLLBACK TO SAVEPOINT.
Для видалення точки відкату в межах заданої транзакції існує оператор:
RELEASE SAVEPOINT < ім’я т.відкату>;

+ 0.01 WHERE snum = 1003;
SAVEPOINT saveupd;
DELETE FROM Orders WHERE

snum = 1003;
DELETE FROM Customers WHERE snum = 1003;
ROLLBACK TO SAVEPOINT saveupd;
COMMIT;

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

до різних даних або виконуються в різні проміжки часу.
Транзакції називаються

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

об'єкт і не завершилась. Друга транзакція намагається змінити цей об'єкт.

Результат – втрата результатів оновлення для транзакції, яка завершилась першою. Фіксуються зміни транзакції, яка завершилась пізніше.
R-W (Read-Write) – Читання-Запис. Перша транзакція двічі читає об'єкт. Між цими читаннями вклинюється друга транзакція і намагається змінити цей об'єкт. Результат – неповторне читання. Перша транзакція працює з даними, які довільно міняються.
W-R (Write-Read) – Запис-Читання. Перша транзакція змінила об'єкт і не завершилась. Друга транзакція прочитала цей об'єкт і працює з ним. Перша транзакція робить відкат і відновлює попередні дані. Результат – фіктивне читання даних. Друга транзакція працює з даними, яких нема і "не було" в БД.
Поява фантомів. Перша транзакція двічі виконує вибірку з фільтрацією. Між цими вибірками вклинюється друга транзакція, яка вставляє новий рядок, що задовольняє умову фільтрації. Результат – після другої вибірки з'явився фантом – лишній рядок, про який нічого не знає перша транзакція.

наскільки це потрібно для забезпечення правильності виконання конкуруючих транзакцій. Це

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

об’єкт не змінювався і/або не читався без відома цієї транзакції,

то цей об’єкт блокується.
Доступ до цього об’єкта зі сторони інших транзакцій обмежується на час виконання транзакції, яка викликає блокування.
Блокування не мають ніякого відношення до безпеки на рівні конкретних користувачів або їх груп.
Блокування в транзакціях виконує СУБД.

– це блокування без взаємного доступу (блокування запису (write)). Якщо

транзакція TRAN1 блокує об’єкт за допомогою Х-блокування, то будь-який доступ до цього об’єкта з боку інших транзакцій відкидається;
Розділені блокування (S-locks, Shared locks, S-блокування) – це блокування з взаємним доступом (блокування читання (read)). Якщо транзакція TRAN1 блокує об’єкт за допомогою S-блокування, то запити з боку інших транзакцій на Х-блокування будуть відхилені, а запити з боку інших транзакцій на S-блокування цього об’єкта будуть прийняті.

FOR UPDATES;

прочитати об’єкт, транзакція повинна накласти на цей об’єкт S-блокування.
Перед тим

як оновити об’єкт, транзакція повинна накласти на цей об’єкт Х-блокування. Якщо транзакція вже заблокувала об’єкт S-блокуванням (для читання), то перед оновленням об’єкта S-блокування необхідно замінити на Х-блокування.
Якщо блокування об’єкта транзакцією TRAN2 відкидається, тому що об’єкт вже заблокований транзакцією TRAN1, то транзакція TRAN2 переходить у стан очікування до тих пір, поки транзакція TRAN1 не знімить блокування об’єкта.
Х-блокування, накладені транзакцією TRAN1, зберігаються до її завершення.

рядків таблиць (MS SQL Server, Oracle);
блокування окремих полів (для цього

необхідно використовувати індекси).

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

блокування.
З іншого боку, перевагою блокувань великих об’єктів є зменшення накладних витрат системи і усунення проблем, які не вирішуються через блокування менших об’єктів.

об’єктів вищого рівня. Наприклад, від блокування рядків до блокування таблиці.

Вручну змінити рівень блокування можна через підказку оптимізатору.
Кількість блокувань. У СУБД передбачені обмеження на кількість блокувань, доступних для одночасного виконання транзакцій.
Ескалація блокувань – здатність СУБД об’єднати декілька блокувань одного рівня в одне блокування вищого рівня. Це автоматична здатність СУБД консолідувати велику кількість блокувань у малу.
Час очікування. Більшість СУБД надають можливість адміністратору встановити параметри, що задають обмеження для часу очікування початку опрацювання транзакції. Якщо блокування не відбулось за вказаний час, то повертається повідомлення про помилку.

[LOCAL] | [LOW_PRIORITY] WRITE}
[, ім'я_таблиці [AS псевдонім] {READ [LOCAL]

| [LOW_PRIORITY] WRITE}] ...
Блокування таблиць знімаються за допомогою команди UNLOCK TABLES.

тому вибираються стратегії блокувань з меншими обмеженнями.
Песимістичне блокування – очікуються

конкуруючі транзакції, тому вибираються стратегії блокувань з більшими обмеженнями.

більше транзакцій намагаються заблокувати одні і ті ж об’єкти і

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

необхідно розпізнати та нейтралізувати.
Методом вирішення тупикової ситуації є відкат

однієї з транзакцій, яку називають транзакція-жертва, щоб інші транзакції продовжували свою роботу.
Після усунення тупика транзакцію-жертву можна повторити.

слідкує за виникненням тупиків. Транзакції самі вирішують, чи бути їм

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

виникненням тупиків і вона ж приймає рішення, якою транзакцією пожертвувати.

Цей спосіб є характерним для промислових СУБД.
СУБД сама вибирає цю транзакцію через деякі вартісні характеристики, наприклад, найкоротшу, або з найменшим пріоритетом.

паралельного доступу до даних.
При блокування на рівні рядків, якщо усі

транзакції виконують протокол доступу, вирішуються усі конфліктні ситуації, крім фантомів.
Блокування вирішують проблему конфліктів, якщо вони недовготривалі (мілісекунди, секунди).
Якщо блокування тривають довго, вони блокують доступ до даних, тому доцільніше використовувати версії даних (Oracle).

тразакціями різних користувачів БД і рівень їх взаємного впливу.
З цією

метою використовується оператор:
SET TRANSACTION ISOLATION LEVEL <рівень ізоляції>;

читання (за замовчування в MySQL);
READ COMMITED – підтверджене читання;
READ UNCOMMITED

– непідтверджене читання.

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

користувачем, навіть якщо перший користувач не підтвердив їх за допомогою оператора COMMIT. Проблема виникає, якщо перший користувач виконав відкат своєї транзакції. Тоді усі наступні дії іншого користувача можуть базуватись на невірних (псевдооновлених) даних.
Будь-які модифікації, що виконуються іншими транзакціями, впливають на поточну транзакцію, незалежно від їх фіксації. Виникає проблема незафіксованих даних, а також фантомів.
Однак, СУБД не допустить виникнення проблеми втрачених результатів оновлення і використає відкат для змін поточної транзакції, якщо вони викличуть таку проблему.
Рівень READ UNCOMMITED підходить при статистичній або аналітичному опрацюванні даних, які змінюються досить рідко.

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

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

результати оновлення даних (зміна або видалення) іншими транзакціями не повинні

відображатись у записах поточної транзакції.
При цьому допускаються операції додання даних.
Рівень виключає проблему неповторюваного читання.
Однак, не усуває проблему фіктивного читання та фантомного додання даних.

завжди виконуються не паралельно, а послідовно. Якщо одна з них

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

відомостей про будь-яку транзакцію, яка модифікує базу даних.
Щоб відновити БД

після перебою, необхідно, щоб кожна дія транзакції над БД була зафіксована в журналі транзакцій.

даних
1 транзакція на оновлення даних в таблиці та її повний

відкат;
1 транзакція із точкою відкату та субтранзаціями після неї та відкат до цієї точки;
1 блокування таблиці на читання, спроба перегляду даних та розблокування таблиці.
Зміна рівня ізоляції транзакцій на READ UNCOMMITED.
1 транзакція на оновлення даних в таблиці без явного режиму транзакцій. Перегляд внесених змін. Відкат цієї транзакції.