1. Read Uncommitted
2. Read Committed
3. Repeatable Read
4. Serializable
Рівні ізоляції покликані забезпечити в СУБД правила паралелізму і послідовності роботи з даними. Коли встановлюється рівень ізоляції, безліч користувачів, що працюють з одними і тими ж наборами даних (одні і ті ж значення даних в стовпчиках і рядках таблиці), встановлюють блокування або слідують заснованим на встановленому рівні ізоляції правилам. За замовчуванням, встановлюється ізоляція Read Committed, і ця установка діє в рамках сеансу. Основний принцип полягає в тому, що друкарська транзакція завжди блокує читають транзакції, якщо вони мають рівні ізоляції вище її, виключаючи Read Uncommited. Коли встановлено рівень Read Uncommited, друкарська транзакція не блокує читають, а читають не блокують запис. Таким чином, Ви маєте можливість скласти запит таким чином, що отримаєте брудні дані, які ще не збережені в базі даних, і цим буде порушений принцип послідовності. Коли встановлено Read Committed, прочитати можна тільки збережені дані. Але як тільки читаюча транзакція завершить процес читання даних, навіть якщо сама транзакція до цього моменту ще не завершена, її блокування вже не буде перешкоджати змінам в цих даних. При використанні Repeatable Read, коли в одній транзакції читаються порції даних, одні і ті ж дані будуть вважатися кожен раз, коли відбувається читання в цій транзакції. Тому, навіть в моменти, коли читання даних не виконується, інші транзакції не зможуть змінювати дані, але вони зможуть здійснювати вставки нових даних в таблицю або в діапазони даних, які в народних обранців блоковані. Рівень Serializable йде на крок далі по відношенню Repeatable Read і захищає всі інші блоки даних від вставок. Це називається запобіганням фантомних читань.
За замовчуванням ця опція вимкнена - OFF. Ви можете дізнатися стан цієї опції, запросивши дані з sysdatabase.
Використання Snapshot - ізоляції буде дозволено (ON) тільки після того, як виконуються в даний час транзакції будуть завершені. До цих пір стан цієї опції буде перебувати в проміжному стані: Pending_On (або Pending_Off при спробі відключити опцію). Поряд з опцією ALLOW_SNAPSHOT_ISOLATION, Ви можете встановити опцію READ_COMMITTED_SNAPSHOT на всю базу даних.
Коли опція READ_COMMITTED_SNAPSHOT буде включена, які читають транзакції в сеансі з рівнем Snapshot - ізоляції не матимуть можливість встановити загальну блокування ресурсу. Ви можете перевірити установку стану READ_COMMITTED_SNAPSHOT, зробивши запит до таблиці sysdatabases.
Цей запит повертає 0 або 1. Після того, як Ви включите Snapshot - ізоляцію на рівні бази даних, стане можливим використовувати рівень Snapshot - ізоляції в рамках сеансу, якщо для нього буде встановлена наступна опція:
Цікавий момент, на який варто звернути тут увагу, це те, що вищезгадана інструкція не видасть помилку, якщо Snapshot - ізоляція не дозволена на рівні бази даних. Але це поверне помилку, коли в сеансі буде зроблена спроба виконання будь-DML (НЕ DDL) інструкції.
Msg 3952, Level 16, State 1, Line 1
Transaction failed in database 'TestDbase' because the database does not allow snapshot isolation. Use ALTER DATABASE to allow snapshot isolation.
Давайте тепер подивимося на прикладі, як працює Snapshot - ізоляція. Створіть в базі даних просту таблицю з ім'ям Transactions, скрипт створення якої наведено нижче:
Встановіть для бази даних рівень Snapshot - ізоляції, якщо Ви ще цього не зробили.
Ви знову побачите попередню копію даних з таблиці Transactions. Але в цьому випадку, другий сеанс буде блокований першим сеансом, де транзакція не закінчена. Дані, які Ви побачите, будуть тими даними, які також були перед початком транзакції першого сеансу. Ще один момент, який варто відзначити, Ви можете змінити рівень ізоляції, не припиняючи транзакцію. Але помилка все-таки буде отримана, коли Ви виконаєте вибірку, і в ній буде повідомлятися, що Snapshot - ізоляція не була встановлена, коли була розпочата транзакція. Помилка показана нижче.
Msg 3951, Level 16, State 1, Line 1
Transaction failed in database 'TestDbase' because the statement used snapshot isolation but the transaction did not start in snapshot isolation.
Ще один цікавий момент, навіть після завершення транзакції першого сеансу, Ви все ще будете бачити старі дані в другому сеансі з другої транзакцією. Як тільки Ви завершите другий сеанс (завершите транзакцію, виконайте перепідключення або встановіть SET TRANSACTION ISOLATION LEVEL READ COMMITTED) і виконаєте вибірку знову, тоді в неї потраплять змінені дані. До виконання цих дій, повторне виконання вибірки завжди буде повертати не змінені дані.
Порада. як тільки транзакція починається з рівнем Snapshot - ізоляції, запити на вибірку завжди будуть повертати одні і ті ж дані до моменту закінчення транзакції, і це не залежить від стану інших транзакцій, що працюють з даними.
Як це все працює: