3. Методи блокування

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

Припустимо, що перший користувач виконує команду:

UPDATE USP

SET OCENKA = 3 WHERE PNUM = 2003;

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

SELECT SNUM, MIN (OCENKA) FROM USP GROUP BY SNUM;

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

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

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

2. • одна дія може частково впливати на результат іншої дії Наприклад, при отриманні звіту про успішність не виключено, що іншим користувачем вироблено видалення із списку одного або декількох студентів, а дані про їхню успішність вже можуть увійти до висновку першого запиту.

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

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

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

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

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

2. • спеціальні (жорсткі) блокування - не дозволяють нікому взагалі, окрім власника цього блокування, звертатися до даних. Спеціальні блокування використовуються, наприклад, для команд, які змінюють зміст або структуру таблиці і діють до кінця транзакції.

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

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

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

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

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

Отже, засоби управління паралелізмом в СУБД визначає те. в якому ступені одночасно подані команди будуть заважати один одному. В сучасних СУБД воно є пристосовуваним засобом, що автоматично знаходить краще розв'язання з урахуванням забезпечення максимальної продуктивності БД і доступності даних для діючих команд.