Створення та обробка баз даних на ПЕОМ (стр. 35 )

Класичним прикладом транзакції, який звичайно приводять у літературі по БД, є бухгалтерська проводка. Нехай, наприклад, у банку є рахунки клієнтів А и Б, і потрібно деяку суму S зняти з рахунка А и перевести її на рахунок Б. Таким чином, у даному прикладі транзакція складається з двох операцій:

1.  зняти суму S з рахунка А;

2.  помістити суму S на рахунок Б.

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

При невдалому виконанні транзакції (при її відкаті), вона може бути виконана повторно.

13.3. Проблеми доступу до даних багатьох користувачів

Розглянемо тепер проблеми, що виникають при одночасному доступі до даних багатьох користувачив. Цим проблемам уже придумали спеціальні назви:

1.  «читання незафіксованих змін»;

2.  «неповторювальне читання»;

3.  «незафіксовані (чи фантомні) записи»;

4.  «загублені зміни», і ін.

Суть цих проблем коротко полягає в наступному:

«Читання незафіксованих змін». Нехай, наприклад, паралельно (одночасно) виконуються дві транзакції: Т1 і Т2. Транзакція Т1 зробила зміни даних у запису А, але ще їх не зафіксувала (транзакція ще не завершилася). Транзакція Т2 прочитала зміни даних у запису А и продовжує виконуватися далі. Якщо тепер з якої-небудь причини відбудеться скасування транзакції Т1, то в цьому випадку транзакція Т2 буде працювати з невірними даними.

«Неповторювальне читання». Транзакція Т1 прочитала запис А і продовжує з нею працювати. Транзакція Т2 до завершення Т1 змінила дані в записі А и зафіксувала їх у БД. При повторному читанні транзакцією Т1 даних вони можуть відрізнятися від колишніх і результати виконання транзакції Т1 можуть виявитися помилковими.

«Незафіксовані (фантомні) записи». Нехай транзакція Т1 створила новий запис А, але ще не зафіксувала його в БД. У цей час транзакція Т2 прочитала запис А и продовжує з ним працювати. Якщо транзакція Т1 буде скасована, то виявиться, що транзакція Т2 працює з неіснуючим записом.

Подібна ж ситуація відбудеться у випадку, якщо транзакція прочитала і працює з записом А, і після цього транзакція Т2 видалить цей запис. Транзакція Т1 буде продовжувати працювати з неіснуючим записом.

«Загублені зміни». Транзакція Т1 зробила зміни в запису А, але ще їх не зафіксувала. У цей час транзакція Т2 ще раз змінила дані в А и успішно завершилася. Зміни, зроблені транзакцією Т1, будуть загублені.

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

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

13.3. Блокування

Блокування, як уже відзначалося, є основним засобом розв’язання конфліктів.

При виникненні конфлікту у транзакції є два вибори – або негайно збудити виключення (помилку), або почекати якийсь час і після цього знову спробувати виконати потрібну дію. У зв'язку з цим введене поняття режиму блокування, що може мати два значення: wait (чекати), і nowait (не чекати).

Конфлікти, про які мова йде, можуть виникати як при читанні даних, так і при введенні чи редагуванні даних.

На конфлікти при читанні даних крім режиму wait/nowait, впливає також установлений рівень ізоляції транзакцій (про рівні ізоляції транзакцій мова йтиме пізніше). На конфлікти ж при введенні чи редагуванні даних рівень ізоляції транзакцій не впливає. Тому зручно розглянути, як застосовуються блокування при вирішенні конфліктів при введенні і редагуванні даних.

13.3.1. Конфлікт при вставці запису

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

Таблиця

0

 

2

Т1

3

 

Т2

Рис. 13.1. Конфлікт при вставці запису

У залежності від режиму блокування транзакції Т2 можливі такі варіанти:

1)  якщо Т2 запущена в режимі wait, то вона чекає завершення Т1. Якщо Т1 завершується підтвердженням, то для Т2 генерується виключення (помилка). Якщо Т1 не підтверджується (зроблений відкат Т1), то Т2 успішно завершується;

2)  якщо Т2 запущена в режимі nowait, то для Т2 відразу генерується помилка.

13.3.2. Конфлікт при редагуванні запису

Транзакція Т1 змінила дні у якому-небудь запису, але ще не підтвердила зміни. Транзакція Т2 намагається редагувати чи видалити цей самий запис. У залежності від режиму блокування для Т2 можливі такі варіанти:

1)  якщо Т2 запущена в режимі wait, то вона буде чекати, поки Т1 не підтвердиться чи скасується. Якщо Т1 підтвердилася, то для Т2 генерується помилка. Якщо Т1 не підтвердилася, то Т2 успішно завершується;

2)  якщо Т2 запущена в режимі nowait, то відразу генерується помилка.

13.3.3. Взаємне блокування транзакцій

Нехай запущені дві трансакції: Т1 і Т2, і є два запису: А и Б. Припустимо, виконується така послідовність дій:

1)  Транзакція Т1 заблокувала запис А і успішно з ним працює;

2)  Транзакція Т2 заблокувала запис Б и також успішно з ним працює;

3)  Транзакції Т1 знадобилося попрацювати з записом Б и вона намагається його заблокувати. Тому що запис Б зайнятий, Т1 переходить у режим чекання;

4)  Тепер транзакції Т2 треба було попрацювати з записом А. Вона намагається його заблокувати і також переходить у режим чекання.

У результаті виникла сумна ситуація: обидві транзакції не мають ніякої можливості продовжити своє виконання, тому що “намертво” заблокували одна одну.

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

13.4. Рівні ізоляції транзакцій

Завдяки механізму транзакцій можна зробити цілком “невидимими” для всіх інших транзакцій (користувачів) зміни, вироблені в даної транзакції аж до її підтвердження. Однак така повна ізольованість транзакцій не завжди ефективна, тому що приводить до уповільнення роботи інформаційної системи. Продуктивність системи може бути збільшена, якщо дозволити транзакції “бачити” ті зміни, що були підтверджені іншими транзакціями вже після запуску даної транзакції.

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

Існують чотири рівні ізоляції транзакцій:

DIRTY READ. Транзакція з таким рівнем ізоляції може читати непідтверджені дані в інших транзакціях. Цей рівень називають “брудне читання”. У InterBase такий рівень ізоляції транзакцій заборонений.

REАD COMMITED. Транзакція, запущена з таким рівнем, може читати зміни, зафіксовані в паралельно виконуваних транзакціях. Цей рівень гарантує, що ми не зможемо прочитати непідтверджені змінені дані в інших транзакціях, але підтверджені дані прочитати можна.

SNAPSHOT. Цей рівень ізоляції використовується для створення “моментального знімка” БД у момент запуску транзакції. Всі операції читання даних у цієї транзакції будуть “бачити” БД у стані, у якому вона була в момент запуску транзакції. Усі зміни в інших транзакціях (підтверджені і непідтверджені) не видимі для цієї транзакції.

SNAPSHOT TABLE STABILITY. Цей рівень ізоляції аналогічний рівню SNAPSHOT, але додатково блокує таблицю на запис. Ідея тут проста – якщо транзакція з таким рівнем ізоляції робить зміни в якій-небудь таблиці, то транзакції з рівнями REАD COMMITTED і SNAPSHOT можуть тільки читати цю таблицю, а транзакції з таким же рівнем ізоляції, тобто SNAPSHOT TABLE STABILITY, не можуть і читати її дані.

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

13.5. Сервер InterBase

13.5.1. Призначення. Загальні відомості

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

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

InterBase є кросплатформеним продуктом, який сумісний з різними типами операційних систем, включаючи Windows NT, Windows 98 (2000, XP), Linux і ін. InterBase відрізняється надзвичайно низькими системними вимогами і при цьому високою продуктивністю і легкістю адміністрування.