1. Проблема втрати поновлення.

Припустимо, у базі даних зберігається запис з відомостями про наявність на складі деякого товару (поля Назва товару - Кількість, шт.):

Костюм

50

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

Першому користувачеві необхідно відобразити в базі даних факт надходження на склад ста костюмів. Він змінює наявні дані і зберігає оновлену запис в базі даних. Кількість костюмів становить 150 штук.

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

У результаті в базі даних буде зберігатися помилкова інформація про наявність на складі 30 костюмів (насправді їх повинно бути 130), так як зміни, внесені першим користувачем, втрачені.

2. Проблема залежності від незафіксованих оновлень.

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

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

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

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

Виконувана паралельно друга транзакція враховує надходження на склад двохсот костюмів. У підсумку загальна кількість костюмів на складі складе 150 штук.

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

2. Проблема неузгодженого аналізу

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

Припустимо, що в базі даних зберігаються записи про наявність товарів на трьох складах торговельного підприємства (поля Назва складу - Кількість, шт.):

Склад 1	50
Склад 2	100
Склад 3	200

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

Припустимо, що дії в рамках транзакцій виконуються в наступному порядку:

1. Перша транзакція читає перший запис. Кількість товарів - 50 штук, отже, їх сумарна кількість також поки дорівнює 50. 2. Друга транзакція читає третій запис. Кількість товарів - 200 штук. 3. Перша транзакція читає другий запис. Кількість товарів - 100 штук, сума дорівнює 150. 4. Друга транзакція віднімає 100 штук товару з кількості, зазначеної у третій запису. Оновлене значення кількості товарів в третій запису складає 100 штук. 5. Перша транзакція читає третій запис. Кількість товарів - 100 штук, сума дорівнює 250. 6. Друга транзакція читає перший запис і додає до заховану в ній кількості товарів (50 штук) 100 надійшли одиниць. Оновлене значення кількості товарів в першого запису складає 150 штук.

В результаті неузгодженого аналізу перша транзакція неправильно обчислила сумарну кількість товарів. Вона склала 250 штук при фактичному значенні 350 штук.

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

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

Можливі два види блокувань [2]:

1. Монопольна блокування (X-блокування, eXclusive locks).

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

2. Блокування з взаємним доступом (S-блокування, Shared locks).

Це блокування дозволяє звертатися до об'єкта бази даних одночасно кільком транзакціях, але тільки в режимі читання (оновлення і видалення інформації заборонені).

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

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

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