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

Загальний побічний ефект усіх розглянутих алгоритмів управління па­ралельним доступом за допомогою блокувань — це можливість виникнення тупикових ситуацій. Тупик — це така ситуація, коло багато запитів ство­рюють цикл, очікуючи зняття захватів іншими запитами з цієї самої мно­жини. Виявлення та усунення тупиків — це одна з найскладніших задач у розподілених системах.

6.5. ТРАНЗАКЦІЇ ТА МЕХАНІЗМ ЇХ ПІДТРИМКИ

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

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

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

Проілюструємо дію цього механізму на прикладі. Нехай необхідно пе­ревести деяку суму з одного розрахункового рахунку в банку на інший. Ця операція складається з двох таких кроків:

1) зняти суму з одного розрахункового рахунку (модифікація запису 1);

2) добавити суму на другий рахунок (модифікація запису 2).

Зазначимо, що після виконання першого кроку файли бази даних пере­буватимуть у неузгодженому стані (рахунки не будуть балансуватись на ве­личину суми, знятої з першого рахунку). При паралельній роботі кількох користувачів такий стан файла буде помилковим, оскільки інші користувачі бачать файли з неузгодженою інформацією. Крім того, другий крок опера­ції може завершитися тупиком (наприклад, другий запис буде заблокований іншим користувачем) чи аварійним збоєм системи. Апаратний збій між ви­конанням першого і другого кроків взагалі може призвести до втрати конт­ролю над цілісністю та узгодженістю бази даних. Спроба розв'язати задачу блокуванням файлів на період виконання операції дуже уповільнить роботу інших користувачів мережі і не зможе забезпечити відновлення файлів у результаті апаратних збоїв системи.

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

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

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

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

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

У сучасних розподілених СУБД підтримку транзакцій можна виконува­ти за допомогою двох методів: