7 "Мертві" блокування

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

Без вживання спеціальних механізмів виявлення і зняття "мертвих" блокувань нормальна робота транзакцій буде порушена. Якщо в системі встановлений нескінченний період очікування завершення транзакції (а це задано за умовчанням), то при виникненні "мертвого" блокування для двох транзакцій цілком можливо, що, чекаючи звільнення заблокованих ресурсів, в безвихідь попадуть і нові транзакції. Щоб уникнути подібних проблем, в середовищі MS SQL Server реалізований спеціальний механізм дозволу конфліктів тупикового блокування.

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

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

Для мінімізації можливості утворення "мертвих" блокувань при розробці коду транзакції слід дотримуватися наступних правил:

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

• уникати взаємодії з користувачем в тілі транзакції ;

• мінімізувати тривалість транзакції і виконувати її по можливості в одному пакеті;

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

8 Рівні ізоляції sql Server

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

SQL Server підтримує всі чотири рівні ізоляції, визначені стандартом ANSI. Рівень ізоляції встановлюється командою:

SET TRANSACTION ISOLATION LEVEL

{ READ UNCOMMITTED

| READ COMMITTED

| REPEATABLE READ

| SERIALIZABLE }

READ UNCOMMITED – незавершене читання, або допустиме чорнове читання. Низький рівень ізоляції, відповідний рівню 0. Він гарантує тільки фізичну цілісність даних: якщо декілька користувачів одночасно змінюють один і той же рядок, то в остаточному варіанті рядок матиме значення, визначене користувачем, що останнім змінив запис. По суті, для транзакції не встановлюється ніякого блокування, яке гарантувало б цілісність даних. Для установки цього рівня використовується команда:

SET TRANSACTION ISOLATION

LEVEL READ UNCOMMITTED

READ COMMITTED – завершене читання, при якому відсутнє чорнове, "брудне" читання. Проте в процесі роботи однієї транзакції інша може бути успішно завершена і зроблені нею зміни зафіксовані. У результаті перша транзакція працюватиме з іншим набором даних. Це проблема неповторюваного читання . Даний рівень ізоляції встановлений в SQL Server за умовчанням і встановлюється за допомогою команди:

SET TRANSACTION ISOLATION

LEVEL READ COMMITTED

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

SET TRANSACTION ISOLATION

LEVEL REPEATABLE READ

SERIALIZABLE – ізольованість. Читання заборонено до завершення транзакції. Це максимальний рівень ізоляції, який забезпечує повну ізоляцію транзакцій один від одного. Він встановлюється командою:

SET TRANSACTION ISOLATION

LEVEL SERIALIZABLE

В кожний момент часу можливий тільки один рівень ізоляції.

Таблиця 16.1. Рівень ізоляції конкуруючої транзакції прийнятий за умовчанням (READ COMMITTED). В прикладі кроки 4, 6 і 8 демонструють чорнове читання. Кроки 9 і 10 блокуються, тому що дані захоплені конкуруючою транзакцією.

Таблиця 16.2. Рівень ізоляції конкуруючої транзакції прийнятий за умовчанням (READ COMMITTED). В прикладі кроки 4, 6 і 8 демонструють блокування даних, захоплених іншою транзакцією, тоді як робота з іншими даними дозволяється (крок 10).

Таблиця 16.3. Рівень ізоляції конкуруючої транзакції прийнятий за умовчанням (READ COMMITTED). На кроці 2 транзакція захопила дані читанням і блокує роботу з ними із сторони конкуруючої транзакції (кроки 3, 5), яка може лише додавати записи (крок 7).

Таблиця 16.4. Рівень ізоляції конкуруючої транзакції прийнятий за умовчанням (READ COMMITTED). Приклад демонструє, що поточна транзакція захопила дані читанням (крок 2) і блокує будь-які дії з ними із сторони конкуруючої транзакції аж до вставки даних (крок 7) .

Контрольні питання

1. Дайте визначення транзакції.

2. Вчому полягає її призначення?

3. Якими властивостями володіє кожна транзакція?

4. Про що говорить властивість неподільності?

5. Про що говорить властивість ізольованості?

6. Про що говорить властивість стійкості?

7. Про що говорить властивість злагодженості?

8. Хто або що відповідає за дотримання властивостей транзакцій?

9. Що таке блокування?

10. За якої умови воно виникає?

11. Які різновиди блокування існують?

12. Що таке рівні блокування?

13. Скільки їх існує? Опишіть кожен.

14. Яким чином здійснюється керування транзакціями?

15. Перерахуйте і опишіть команди, що здійснюють керування.