РІВНІ ІЗОЛЯЦІЇ

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

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

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

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

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

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

і дане питання коротко розглядається в цьому розділі

Може бути визначено щонайменше пять різних рівнів ізоляції, але в [1610],

в стандарті SQL і в СУБД DB2 підтримуються лише чотири Взагалі кажучи, чим вище рівень ізоляції, тим менше ступінь втручання транзакцій в роботу один одного (і тим нижчий ступінь розпаралелювання), а чим нижче рівень ізоляції, тим більше ступінь втручання (і вище ступінь розпаралелювання) В якості ілюстрації розглянемо два рівня, підтримуваних в СУБД DB2, – стабільність курсору і повторюване читання Максимальним рівнем є повторюване читання (Repeatable Read – RR) якщо всі транзакції діють на цьому рівні, то всі графіки стають впорядковувати На відміну від цього, при використанні іншого рівня, а саме стабільності курсору (Cursor Stability – CS) дотримуються наступні умови:

■ якщо транзакція А отримує можливість звернутися до деякого кортежу6 t і в результаті

■ набуває блокування на t, а потім

■ звільняє структури адресації, застосовувані для доступу до кортежу t без його оновлення, і тому

6 Така можливість у транзакції зявляється завдяки такій установці курсора, коли він вказує на кортеж (як було описано в розділі 4), звідси і походить назва стабільність курсора. Але з метою уточнення необхідно вказати, що в СУБД DB2 купується блокування Т1 кортежу t фактично є блокуванням оновлення (Update – U), а не блокуванням S (див [421])

■ не має права продовжувати свою блокування до рівня X, то

■ дане блокування може бути звільнена без очікування кінця транзакції

Але слід враховувати, що тепер деяка інша транзакція в може оновити кортеж t і зафіксувати зміну Якщо надалі транзакція А повернеться на деякий попередній етап своєї роботи і знову прочитає кортеж t (слід зазначити, що при цьому відбувається порушення протоколу двофазної блокування), то виявить внесене зміна і тому фактично зіткнеться з несумісним станом бази даних З іншого боку, при повторюваний читанні (RR) всі блокування кортежів (а не тільки блокування X) утримуються до кінця транзакції і тому тільки що зазначена проблема не виникає

З цього випливають наведені нижче висновки

1 Зазначена проблема є не єдиною, яка може виникнути при використанні рівня CS ми тут привели її опис лише тому, що вона є найбільш очевидною Але, на жаль, з цього опису випливає, що рівень RR нібито потрібно лише в тому порівняно малоймовірному випадку, якщо в деякій певній транзакції буде потрібно двічі зчитувати один і той же кортеж З іншого боку, є вагомі аргументи на користь того, що рівень RR завжди є більш прийнятним у порівнянні з CS транзакція, виконан няемие в умовах застосування CS, не є двофазної і тому (як було описано в попередньому розділі) її упорядочіваемость більше не можна гарантиро вать Але інший вагомий контрвисновок полягає в тому, що рівень CS забезпечує більшу ступінь розпаралелювання, ніж RR (тим Проте, справедливість цього твердження є вірогідною, але не обовязковою)

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

3 У будь-якій реалізації, яка підтримує будь-який рівень ізоляції нижче мак симально, повинні бути, як правило, передбачено деякі засоби яв ного управління паралельністю, що дозволяють користувачам створювати свої додатки так, щоб гарантувалася безпека експлуатації бази даних в відсутність подібних гарантій з боку самої системи (зазвичай явно заданий ниє оператори LOCK) Наприклад, в СУБД DB2 передбачений явно заданий опе ратор LOCK TABLE, який дає можливість користувачам, що працюють на рівні менше максимального, набувати явних блокування, що перевершують ті, що придбаваються в DB2 автоматично для дотримання вимог ті кущего рівня (До речі, слід зазначити, що в стандарті SQL не передбачені подібні явно задані механізми управління паралельністю, як описано в розділі 1611)

Крім того, необхідно враховувати, що наведене вище опис рівня RR як максимального рівня ізоляції відноситься до реалізації повторюваного читання в СУБД

DB2 На жаль, в стандарті SQL термін повторюване читання використовується для позначення рівня ізоляції, який є строго нижчими, ніж максимальний рівень (про це також сказано в розділі 1611)

Фантоми

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

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

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

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

Отже, в даному випадку в обох транзакціях застосовувалася сувора двофазна блокування і все ж таки сталося щось неправильне, а саме: у транзакції А було виявлено те, чого не існувало при першому її виконанні, – фантом Внаслідок цього упорядочіваемость була порушена (очевидно, що в даному випадку чергується виконання не еквівалентно ні послідовності спочатку А, потім в, ні послідовності Спочатку в, потім А)

Але заслуговує на особливу увагу те, що розглянута тут проблема не має нічого спільного з двофазної блокуванням як такої Швидше, ця проблема полягає в тому, що в транзакції А не було заблоковано те, що логічно повинно було бути заблоковано замість блокування лише трьох наявних рахунків клієнта Джо в ній фактично потрібно було заблокувати безліч всіх рахунків, що належать Джо або, іншими словами, рахунків, відповідних предикату власник рахунку – Джо (Див [166] і [1613]) 7 Якби можна було забезпечити таку можливість, то транзакції в довелося б перейти в стан очікування після здійснення в ній спроби ввести новий

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

рахунок (оскільки в, безумовно, довелося б зажадати блокування на цей новий рахунок, а таке блокування увійшла б у суперечність з блокуванням, що належить транзакції А) Хоча з причин, описаних в [1512], в більшості сучасних систем не дозволені блокування предикатів як така, у них все одно, як правило, вдається уникнути виникнення фантомів завдяки блокуванню шляхи доступу, який використовується для звернення до досліджуваних даними Наприклад, якщо у випадку використання тих рахунків, які належать Джо, шляхом доступу є індекс на імені клієнта, то система може заблокувати запис в цьому індексі, що відноситься до клієнта Джо Таке блокування запобігає виникненню фантомів, оскільки для створення такого фантома потрібне оновлення шляхи доступу (у даному прикладі записи індексу) і тому придбання блокування X на такий шлях доступу Додаткові відомості на цю тему наведені в [1512]

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*