Управління транзакціями

Размещено на http://www.allbest.ru/

Реферат

"Управління транзакціями"



План

1. Транзакції

2. Управління паралелізмом, заснований блокуванні (locks)

3. Рівні ізоляції транзакції

4. Реєстрації бази даних



Огляд

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

Запит користувача, направлений до СУБД (DBMS), є у формі транзакції - послідовністю SQL операторів, які виконуються як одне ціле: або всі або жоден з них. Ми нагадуємо вам, що транзакції на мові SQL були вже представлені в Лекції 3.

В першій частині цієї лекції ми представимо проблеми, які можуть виникати, коли співпадаючі дії транзакцій є вкладеними одна в одною, і як СУБД вирішує такі проблемами. Основою для реалізації транзакції СУБД - це протокол Строгого (абсолютного) 2-фазового Блокування, коротко Абсолютний-2PL.

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



1. Транзакції

Паралелізм

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

SQL оператори, які складають транзакцію, можуть забезпечуватися користувачем в деяких інтервалах часу і залежать від результатів попередніх. Через те, це очевидно, що Система не може зарезервувати повну тривалість обчислення для виконання одної транзакція.

З точки зору СУБД, транзакція - це представлення призначеної для користувача програми і є послідовністю дій читання і запису на базі даних (sequence of read and write operations on the database). Паралелізм є результатом чергування транзакцій читання і запису різних транзакцій одних з одними. Повний результат повинен бути таким, нібито транзакції виконувалися незалежно одна від одної і вчасно. Модуль управління транзакцій приходить працює з організацією паралельного виконання транзакцій користувача.

Коректність і послідовність

Коректність виконуваних транзакцій є першочерговою. Ця коректність підтримується обмеженнями цілісності, визначеними адміністратором системи бази даних (DBA) і конструктором бази даних та перевіряється системою. За визначенням, база даних знаходиться в узгодженому стані (consistent state), коли всі обмеження цілісності задоволені. Не всі умови можуть перевірятися системою. Система може перевірити (в рамках обмежень цілісності) наприклад: чи формат телефонного номера правильний; хоча це не може перевірятися, чи насправді він є телефонним номером людини, чия інформація запам'ятана в базі даних. Обов'язок користувача - переконатися, що введені і оновлені дані відповідають (trustfully correspond) справжнім даним з достатнім ступенем довіри (trustfully correspond) - це визначається конструктором і обмеженнями цілісності, перевіреними системою, може тільки допомогти тут.

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

Аксіома ACID

Є чотири загальні вимоги, які ставлять до кожної СУБД, залежно від того, наскільки вона контролює виконання паралельних транзакцій. Вони названі ACID аксіоматикою, назва якої утворилась як абревіатура з перших букв наступних слів, що означають необхідні властивості: А- Атомарність , C - Послідовність, І - Ізоляція і D - Стійкість ( A - Atomicity, C - Consistency, I - Isolation and D - Durability.

Атомарність (Atomicity) - кожна транзакція є неподільною дією з точки зору користувача: виконуються або всі дії транзакції або жодна з них.

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

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

Стійкість (Durability) - дані, зафіксовані транзакцією, повинні бути доступними навіть в ситуації відмови програми, комп'ютера або носія даних.

Механізми для сумісного використовування ресурсів бази даних

СУБД використовує наступні механізми, які допомагають гарантувати аксіоматику ACID:

блокування (locks) об'єктів - обмеження або навіть відключення іншої дії транзакції на блокованому об'єкті;

реєстрація (log) - занесення всіх змін в базі даних до спеціальної реєстрації, так що в разі потреби має бути можливо:

знищити зміни для незафіксованої транзакції

відновити узгоджений стан бази даних у разі відмови

резервна копія (security copy) дублювання) бази даних - роблять в регулярних інтервалах часу; у разі відмови даних на диску це дозволяє відновити узгоджений стан бази даних.

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

Атомарність транзакції

Транзакція може завершити роботу чотирма способами:

фіксування (committing (COMMIT)) - після закінчення всіх дій.

відкат назад (doing rollback (ROLLBACK)) - відміна всіх виконуваних дій.

зупинка СУБД (stopped by DBMS) - може зупинятися СУБД (перерватися нею) і пізніше повторно запускатися (наприклад завдяки блокуванню).

зупинка завдяки відмові серверу або диска (stopped due to a server or disk failure) - до моменту її завершення. Коли Система запускається знову після відмови, відслідковуються зміни, що зроблені трансакцією і виконані до моменту відмови, а потім відмінені системою (тому що транзакція була перервана посередині).

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

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

Давайте подивимося на наступний простий приклад проблеми накладання (чергуванння) дій двох співпадаючих транзакцій.

Приклад

T1: BEGIN A=A+100, B=B-100 END

T2: BEGIN A=1.06*A, B=1.06*B END

транзакція програма паралелізм аксіоматика

Інтуїтивно, транзакція T1 передає $100 з рахунку B на рахунок А. Транзакція T2 збільшила значення обох рахунків на 6%.

Коректніше (точніше), почергове (перехресне) виконання обох транзакцій повинне бути еквівалентне серійного виконання спочатку Т1, а потім Т2, або серійного виконання T2, а потім T1. В цьому прикладі в обох випадках, результат є тим же.

Результат паралельного виконання окремих транзакцій може визначатися не унікально.

Нижче запропоновано варіант коректного (з точки зору отриманого результату) перехресного виконання обох транзакцій (під назвою список):

T1: A=A+100, B=B-100

T2: A=1.06*A, B=1.06*B



Нижче, є некоректний список (через некоректний результат):

T1: A=A+100, B=B-100

T2: A=1.06*A, B=1.06*B

СУБД не враховує значення специфічності опрацювання даних. З точки зору СУБД, другий план має вигляд:

T1: R(A), W(A), R(B), W(B)

T2: R(A), W(A), R(B), W(B)

де:

R(A) означає об'єкт А - читання даних,

W(A) означає об'єкт А - запис даних. З точки зору управління транзакціями, важливі ще дві дії:

- фіксовання (Commit)- ухвалення транзакції і

- відкат назад (Rollback) - знищення транзакції

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

Список виконання транзакції

Список (реєстр) (schedule)- це послідовне впорядкування операцій читання і запису на об'єктах бази даних за допомогою почергового запуску транзакцій.

Серійний список (serial schedule) - це список, який вставляє у виконання транзакції послідовність: спершу йдіть дії однієї транзакції, потім дії другої транзакції, і т.п.

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

Впорядкований список (serializable schedule) - це список, який рівноцінний до деякого серійного списку. Серійний список правильний за визначенням, так що впорядкований список також правильний як рівноцінний до правильного. Сповіщення про те, що:

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

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

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

Приклад

Нижче є список (розглядався раніше), який не є впорядкованим:

T1: R(A), W(A), R(B), W(B)

T2: R(A), W(A), R(B), W(B)



Факт, про те, що це не впорядкований список, може утримувати (не припускати) від перегляду так званого залежного графа дій транзакції.Коли запис змінної А трансакцією Т1 проводиться перед читанням змінної В транзакцією T2 ми проводимо лінію з T1 до T2 і позначаємо її міткою і так само робимо з B. Причина цього з'являється через невпорядкованості результатів від циклу залежного графа. Результат T2 залежить від T1 і навпаки. Немає рівноцінного списку, який повинен упорядкувати порядок виконання обох транзакцій - переміщення всіх дій однієї транзакції перед іншим.

Визначення еквівалентності списку і те, що звідси також випливає визначення впорядкованого списку, є семантичним символом, який складний для того, щоб використовуватися на практиці. Є також синтаксичні наближення семантичної властивості впорядкування. Їх представлення є за межами цієї лекції - вони входять у Вправи 3-5.

Небажані особливості паралельного виконання транзакції

При аналізі паралельного виконання транзакції там є також інші особливості (незалежно від впорядкованості) на які ми подивимося зараз.

Читання незафіксованих даних - "чорнове читання"

Транзакція T2 читає і кінець кінцем змінює незафіксованим ще дані транзакції T1 (отже потенційно некоректно). Транзакція T1 може потім хотіти відкату (rollback) дії після того, як T2 зафіксує їх. Внизу є список такого типу.

T1: R(A), W(A), R(B), W(B), Commit/Rollback

T2: R(A), W(A), R(B), W(B), Commit

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

Не дуже часто, але іноді транзакції "підробки" використовуються, щоб перевірити деякі гіпотези ("що повинно трапитися, якщо Kowalski став директором? повинна наша компанія збанкрутувати?") а потім відбувається відкат (rollback) такої транзакції. Протягом такої транзакції стан бази даних може повністю не відповідати реальності (користувач бази даних, наприклад, може прочитати, що компанія знаходиться в стані банкрутства).

Читання без повторень unrepeatable - читання зафіксованих даних

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

T1: R(A), R(A), W(A)

T2: R(A), W(A),Commit

Специфічний список, що подано вище, є впорядкованим як еквівалент до серійного списку: спершу T2, потім T1.

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

Транзакція Т1 змінює дані і не фіксує їх. Незабаром, транзакція T2 змінила ті ж дані і зафіксувала зміни. Нижче є список цього типу і він не є впорядкованим!



T1: W(A), W(B)

T2: W(A), W(B),Commit

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

Список відновлень

Список, який дозволяє повертати назад (відкатувати) (rollback) кожну транзакцію, названий списком відновлень (recoverable schedule). Відновлюваність (повернення назад) критична для виконання властивостей атомарності і стійкості.

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

Зараз ми запропонуємо вирішення проблеми, як гарантувати генерацію і виконання списків, які є як впорядкованими і перезаписуваними (serializable and recoverable).



2. Управління паралелізмом, заснований блокуванні (locks)

Основні види блокувань

Основний механізм, який запобігає конфлікти протягом паралельного виконання транзакцій, є блокування, створені на об'єктах. Є два види блокувань:

Блокування із забезпеченням сумісного доступу (блокування без монополізації) (типу S) (Shared lock (of type S))- дає транзакції відкритий доступ до ресурсу, наприклад окремі транзакції можуть читати рядки однієї таблиці одночасно. Якщо транзакція встановлює таке блокування, інші транзакції можуть також встановити блокування без монополізації, але не можуть встановлювати блокування іншого типу, яким є наприклад виняткове блокування. Дія встановлення блокування із забезпеченням сумісного доступу на об'єкт А, позначається як S(A).

Блокування з метою забезпечення взаємовиключаючого доступу (блокування з монополізацією) (типу X) (Exclusive lock (of type X)) - дає а транзакції монопольні права виконання зміни об'єкту. Тільки одна транзакція може мати монопольне блокування, встановлене на об'єкті і протягом цього часу, на нього не може бути встановлено ніяких інших блокувань, навіть блокувань із забезпеченням сумісного доступу. Дія установки монопольного блокування на об'єкт А, позначається X(A).

Є метод для установлення блокувань який гарантує генерацію гарантій і реалізацію списків, які є впорядкованими і пере записуваними (serializable і recoverable). Він широко використовується СУБД. Нижче його представлено у формі загального протоколу установки блокувань на об'єктах.

Протокол Строгого Двофазового Блокування (Strict -2PL):

Кожна транзакція повинна отримати блокування S відкрите на об'єкт перед тим, як зчитає цей об'єкт і блокування X (монопольне) на об'єкт перед тим, як запише в нього.

Якщо транзакція утримує блокування на об'єкті X, ніяка інша транзакція не має права встановити інші блокування (ні типу S ні X) на цьому об'єкті.

Якщо транзакція утримує блокування S на об'єкті, ніяка інша транзакція не має права встановити блокування X на цьому об'єкті.

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

Всі блокування, що утримаються транзакцією, будуть відблоковані одночасно із її завершенням (з відкатом чи фіксацією (rollback або commit).

Пункт 2 і 3 повторюють визначення блокувань S таі X - ми даємо їх для повного перегляду. Помітьте важливість останнього покажчика протоколу.

Твердження.

Протокол Strict-2PL гарантує генерацію впорядкованих та пере записуваних (відновлюваних) списків (rollback або commit).

Протокол Strict-2PL - називають дво-фазним, тому що він визначає дві фази кожного виконання транзакції, пов'язаного із блокуваннями:

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

2. транзакція виконує COMMIT/ROLLBACK і одночасно відпускає всі блокування, що утримує.

Встановлення і відпускання блокувань - дві фази, відокремлені в часі.

Давайте перевіримо, чи протокол Strict-2PL генерує тільки списки, які вільні від аномалій (некоректностей, помилок).

Не може траплятися незафіксоване читання (An uncommitted read), тому що для того, щоб змінити значення об'єкту, транзакції доведеться встановити блокування X і від того моменту часу і аж доти, поки блокування не буде відпущене в кінці транзакції, ніяка інша транзакція не має доступу до блокованого об'єкту (навіть, щоб прочитати його).

Читання без повторень (An unrepeatable read) також не може траплятися, тому що з першим читанням, транзакція встановлює блокування S (або X) на об'єкті, що зчитується, і відпускає це блокування по завершенню. Протягом цього часу ніяка інша транзакція не отримає доступ, щоб встановити блокування X на цьому об'єкті змінити його.

Переписування незафіксованих змін (Overwriting uncommitted changes) також не може мати місця, тому що запис на об'єкті вимагає попередньої установки блокування X на ньому і ніяка інша транзакція не може ні прочитати і записати на цьому об'єкті поки не настане кінець транзакції.

Давайте підсумовуватимемо результати нашого вивчення у формі висновку.

Висновок

Протокол Strict-2PL не дозволяє з'явитися аномаліям незафіксованого читання, читання без повторень unrepeatable і переписування незафіксованих даних (uncommitted read, unrepeatable read and overwrite of uncommitted data).

Примітка

Умова 5 протоколу Strict-2PL може полегшувати утримання його властивостей двофазності та упорядкованості. Замість:

- Блокування, що утримує транзакція, розблоковуються, коли транзакція закінчена.

І ми можемо підсумувати:

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

Ми отримуємо двофазний протокол блокувань, який визначений, як 2PL, що також, приводить до впорядкованих списків. При його використовуванні, ми можемо стикатися з проблемою знищення транзакції. Коли транзакція T1 випускає блокування на об'єкті then інша транзакція T2 може робити деяких змін до цього об'єкту і зафіксувати ці зміни. Більш пізня транзакція T1 може хотіти виконати дію ROLLBACK, що повинне вимагати знищення також транзакції T2, яка вже зафіксована! Таким чином 2PL протокол не гарантує відновлюваність списків.

Управління транзакціями

Модуль управління транзакцією (Transaction management module) діє на транзакції, об'єкти бази даних і на записи реєстрації. Він будує і використовує структури даних для запам'ятовування даних про взаємозв'язки об'єктів бази даних, транзакції і записи реєстрації одним між одним:

транзакції (опрацювання таблиці в оперативній пам'яті) і об'єкти (база даних) (transactions (transaction table in RAM) and objects (database)) сполучені зв'язком: "транзакція утримує конкретизоване блокування на об'єкті бази даних" (звичайно блокована ціла сторінка, де розміщено об'єкт, а не тільки об'єкт безпосередньо);

транзакції (опрацювання таблиці в оперативній пам'яті) і записи реєстрації (transactions (transaction table in RAM) and log records) сполучені взаємозв'язком: "остання дія, виконувана транзакцією, описана в записі" реєстрації (ця інформація потрібна, щоб почати дію відкату (відмни) (rollback) транзакції і відновлення після відмови серверу).

Ми пропустимо деталі алгоритмів, що використовуються в модулі управління транзакціями, оскільки вони є за межами цієї лекції.

Блокування

Протокол Strict-2PL не гарантує, що виконання транзакції закінчить. Така ситуація може з'явитися, коли ми випробовуємо блокування - коли дві або більше транзакцій блокують об'єкти одна одної, які необхідні, щоб продовжувати їх дії. Наприклад, транзакція T1, блокує об'єкт А і транзакція T2 блокує об'єкт B. В наступному кроці T1 хоче блокувати об'єктний B і T2 хоче блокувати об'єкт А. Обидві транзакцій зупинили своє виконання, очікуючи події завершення блокування об'єкту іншою трансакцією.

Блокування - це цикл транзакцій, кожна з яких циклічно чекає на те, аби інша транзакція відпустила блокування. Є три шляхи, щоб вирішити проблему блокування:

попередження тупика (deadlock prevention)

виявлення блокування (deadlock detection)

конкретизації часу очікування на блокування (specifying timeout for waiting for a lock)

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

Виявлення блокування означає пошук, транзакції, яка в очікуванні для того, щоб відпустити блокування і перевірити, якщо там, є цикл.

Попередження тупика - метод часу очікування.

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

Проблема перевантаження

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

Протокол Strict-2PL (в поточній формі, вигляді) правильний, згідно з умовою про те, що база даних є фіксованим, незмінним набором об'єктів. Ми зараз розглядатимемо приклад, в якому Протокол Strict-2PL дає невпорядкований список (non-serializable).

T1 блокує всі сторінки, що містять записи працівників з E.Job='SALESMAN' і показує тих, хто є з найвищою платнею (E.Sal 3000).

ПотімT2 вставляє нового працівника: E.Job='SALESMAN', E.Sal 3500.

T2 видаляє менеджера (E.Job='MANAGER') з найвищою платнею (наприклад E.Sal 5000) і фіксує.

T1 блокує всі сторінки, що містять записи працівника з E.Job='MANAGER' і показує ті, що є з найвищою платнею (наприклад E.Sal 4500).

Ми не можемо упорядковувати виконання цих двох транзакцій!

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

3. Рівні ізоляції транзакції

Ми пояснимо, як вони виконуються СУБД.

1. SERIALIZABLE (впорядкування) - транзакція T читає тільки ті об'єкти, чиї зміни зафіксовані; якщо немає прочтианого значення, або того, яке змінювалось би за допомогою T, то воно може змінюватися іншою транзакцією поки закінчення T; результати оператора SELECT, обчисленого транзакцією T, не зміняться, поки T не закінчить роботу.

Блокування множин транзакції T для читання і запису об'єкту згідно протоколу Strict-2PL, плюс його множина блокувань типу S на множинs результуючих рядків, що утворились внаслідок виконання операторів SELECT (виконують за допомогою блокування індексного вузла або за допомогою блокування цілої таблиці).

2. REPEATABLEREADS (ПОВТОРНЕ ЧИТАННЯ) - транзакція T може прочитати тільки ті об'єкти чиї зміни зафіксовані; якщо немає значення для читання або зміни за допомогою T може змінюватися іншою транзакцією, поки T закінчить роботу. Транзакція T одержує блокування для читання і запису об'єкту згідно протоколу Strict-2PL. Немає блокувань, встановлених на множинах рядків, що виникли, в результаті виконання операторів SELECT.

3. READCOMMITED (ЧИТАННЯ ЗАФІКСОВАНЕ) - транзакція T може прочитати тільки ті об'єкти, чиї зміни зафіксовані; жодне значення, змінене T, не може змінюватися іншою транзакцією, поки T закінчить роботу. Транзакція T одержує блокування X, щоб виконувати зміни і утримує їх, поки це закінчено роботу. Щоб виконувати читання, він одержує блокування S. Після закінчення читання, блокування негайно відпускається (без очікування того, щоб транзакція закінчилася). В реалізації Oracle для того, щоб прочитати об'єкт, не потрібне отримання блокувань S. Замість того, щоб для читання встановлювати блокування S, Oracle використовує особливість багатоверсійності (яку опишемо пізніше). В Oracle, рівень READCOMMITED (ЧИТАННЯ ЗАФІКСОВАНЕ), дозволяє підтримувати вищий рівень паралелізму, ніж в Стандарті, тому що це дозволяє прочитати об'єкти, навіть якщо інша транзакція встановила блокування X на цьому об'єкті (який не дозволений в Стандарті).

4.READUNCOMMITED (ЧИТАННЯ НЕ ЗАФІКСОВАНЕ) - транзакція T читає будь-які об'єкти в будь-якої миті; T не робить ніяких записів.

Транзакція не встановлює будь-які блокування, але не має ніяких прав змінити дані в базі даних.

Оптимістичне блокування

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

Фаза 1: Транзакція читає потрібні дані до локальних буферів і виконує зміни на них без установки будь-яких блокувань.

Фаза 2: Сканування транзакції на предмет того, чи виконувані нею операції читання/запису не суперечать тим операціям читання/запису, що виконуються у вже зафіксованих транзакцій. Якщо вони не виконуються, відбувається запис змін з локальних буферів до глобальних і транзакцію зафіксована. Якщо вони виконуються, та ж транзакція повторно запускається ще раз - це не є необхідним для скасування (відкату назад (rollback)) зміни бази даних, тому що жоден не зроблений.

Тільки протягом реалізації Фази 2 є потреба установки блокувань X на всіх об'єктах, що були змінені.

Дані Multi-versioned (мульти-версійність даних)

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

4. Реєстрації бази даних

В реєстрації бази даних, інформація про дії, виконувані на базі даних іншими транзакціями, запам'ятовується так само, як і інша, додаткова інформація про події, що мають місце в базі даних.

Кожний запис реєстрації має призначений номер LSN (порядковий номер реєстрації), який її ідентифікує. Наприклад, запис реєстрації, що описує зміну в базі даних, є наступної форми:

<operation type, transactionID, pageID, offset, length, before-image, after-image, previousLSN>

Окрім зміни даних, записи реєстрації створені також для інших дій, як наприклад: фіксування транзакції, знищення транзакції (committing a transaction, undoing a transaction). Є два види реєстрацій: знищити реєстрацію і перезаписати реєстрацію (undo log and redo log). Знищення реєстрації (undo log) пов'язаний з видаленням транзакції і з особливістю мультиверсійності (multi-versioning) даних.З другого боку, зміна реєстрацію (redo log) пов'язана з оновленням бази даних після відмови серверу або носія даних. Обидві реєстрацій обслуговують різні цілі таким чином вони запам'ятовуються окремо: знищення реєстрації з даними в базі даних і зміна реєстрації на іншому носії даних, ніж файли даних. В деяких системах тільки використовуються зміна реєстрації, яка завжди включає інформацію, що дозволяє знищення змін.

Знищення реєстрації

Для того, щоб бути спроможним виконувати дію ROLLBACK, СУБД вписала всі зміни спеціальну реєстрацію, названу в Oracle, сегментами знищення (undosegments). Дана реєстрація (undosegments) запам'ятовується в базі даних разом з даними. Коли є необхідність забрати транзакцію, система читає назад всю інформацію про зміни, зроблені транзакцією, і відновлює попередні значення даних в базі даних.

Знищте мультиверсійної реєстрації

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

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

Система утримує протилежний викликаний номер зміни системи SCN. Кожна зафіксована транзакція збільшує цей лічильник одним. Значення SCN може братися розглядатися (вважатися) як ідентифікатор зафіксованої транзакції. Кожна сторінка містить число транзакції SCN, яка недавно, робила зміни до сторінки.

Алгоритм оцінки запиту

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

Якщо s_SCN<= q_SCN потім поточний вміст сторінки використовується в обчисленнях.

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

В подібний спосіб виконується транзакція READONLY.

Реєстрація змін і перезапису

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

Правило WAL

Даним, що змінені транзакцією, не доведеться записуватися на диск з оперативної памті в момент закінчення транзакції (COMMITT/ROLLBACK), але вони можуть записуватися:

перед завершенням (потім ми поговоримо про стратегію крадіжки фрейма (framestealing));

або пізніше після завершення (потім ми поговоримо про безсилу стратегію (noforce)).



Висновок

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

Размещено на Allbest.ru