Транзакції і паралелізм

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

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

Під транзакцією розуміється неподільна з погляду дії на БД послідовність операторів маніпулювання даними (читання, видалення, вставки, модифікації) така, що можливі два підсумки:

• результати всіх операторів, що входять в транзакцію, відповідним чином відображаються в БД;

• дія всіх цих операторів повністю відсутня

У СУБД транзакція починається з оператора BEGIN. При цьому якщо транзакція завершена оператором COMMIT, то результати фіксуються в зовнішній пам'яті; при завершенні транзакції оператором ROLLBACK результати відсутні в зовнішній пам'яті.

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

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

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

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

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

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

Поняття транзакції має безпосередній зв'язок з поняттям цілісності БД. Дуже часто БД може володіти такими обмеженнями цілісності, які просто неможливо не порушити, виконуючи зміну тільки одним оператором Наприклад, в базі даних СТУДЕНТИ - ПРЕДМЕТИ ОЦІНКИ (див. мал. 1.11) очевидним обмеженням цілісності є збіг значення атрибуту SN в кортежі відношення СТУДЕНТИ з аналогічним атрибутом відношення ОЦІНКИ. В цьому випадку виникає проблема з додаванням новому студенту оцінки по іспиту. Незалежно від того, яка операція буде виконана першою, вставка нового кортежу у відношення СТУДЕНТИ або у відношення ОЦІНКИ, після виконання операції БД опиниться в нецілісному поляганні.

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

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

При паралельній обробці БД виникає три основні проблеми:

• проблема втрати результатів оновлення - полягає в першу чергу в тому. що транзакція може бути незавершена через те, що дані, які вона обробляє, можуть бути модифіковані іншою транзакцією:

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

• проблема несумісного аналізу - пов'язана з тим. що в результаті модифікації БД транзакцією, інша транзакція може внести в БД якусь інформацію, яка не відповідатиме цілісному поляганню БД

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

Розрізняють два види блокування:

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

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

У СУБД використовують протокол доступу до даних, що дозволяє уникнути проблем паралелізму. Його суть полягає в наступному:

• транзакція, результатом дії якої на кортеж є його витягання, зобов'язана накласти блокування читання на цей кортеж;

• транзакція, призначена для модифікації кортежу, зобов'язана накласти блокування запису на цей кортеж;

• у випадку, якщо запрошуване блокування на кортеж відкидається через те, що на кортеж вже накладено блокування, то транзакція переводиться в режим очікування доти поки блокування не буде знято.

• блокування запису зберігається аж до кінця виконання транзакції, тобто до виконання операторів
COMMIT або ROLLBACK.

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

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