Главная | Обратная связь | Поможем написать вашу работу!

Засоби обробки транзакцій

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

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

Синтаксис цих команд дуже простій, щоб залишити всі зміни постійними використовують

COMMIT WORK/

а для відміни зміни ROLLBACK WORK;

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

а повернення до звичайної діалогової обробки запитів - за допомогою команди

SET AUTOCOMMIT OFF;

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

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

Наприклад, виникла необхідність у видаленні даних про студента Полякова з таблиці STUDENTS. Очевидно, що при цьому потрібне що-небудь зробити з його оцінками за умови, що обмеження зовнішнього ключа відсутнє. Логічне розв'язання буде полягати в тому щоб встановити поле SNUM для записів з його оцінками, в NULL значення і лише після цього виконувати видалення. Це можна реалізувати таким чином:

UPDATE USP

SET SNUM = NULL WHERE SNUM = 3412;

DELETE FROM STUDENTS WHERE SNUM = 3412;

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

В стандарті ANSI/ISO визначена модель транзакцій, а також вказані задачі операторів COMMIT і ROLLBACK. Згідно стандарту вважається, що транзакція автоматично починається з виконання користувачем або програмою першого оператора SQL. Далі відбувається послідовне виконання інших операторів SQL до тих пір, поки транзакція не завершиться одним з чотирьох способів:

• команда COMMIT завершує виконання поточної транзакції, причому зміни, внесені в БД, стають постійними. Нова транзакція починається безпосередньо після COMMIT:
• команда ROLLBACK відміняє виконання поточної транзакції, зроблені зміни відміняються, а нова транзакція починається безпосередньо після ROLLBACK;
• успішне завершення програми обробки даних вважається успішним закінченням транзакції, неначебто була виконана команда COMMIT. Нова транзакція не починається, т. до. програма закінчилася:
• неуспішне завершення програми вважається неуспішним закінченням транзакції, неначебто був виконана команда ROLLBACK. Нова транзакція не починається, оскільки програма закінчилася

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

В СУБД SQL Server використовується дещо розширена модель транзакцій, що надає користувачам додаткові можливості. При цьому використовуються команди:

• BEGIN TRANSACTION - повідомляє систему про початок транзакції. На відміну від стандартної моделі, початок транзакції задається явно за допомогою цієї команди:
• COMMIT TRANSACTION - повідомляє систему про успішне закінчення транзакції. Після виконання цієї команди всі зміни, зроблені в БД протягом транзакції, стають постійними, проте нова транзакція не починається; • SAVE TRANSACTION - створює усередині транзакції точку збереження. СУБД зберігає стан БД в поточній крапці і привласнює збереженому стану ім'я точки збереження, яке указується в операторі;
• ROLLBACK TO SAVEPOINT - відміняє зміни, зроблені в БД після точки збереження, повертаючи транзакцію до місця, де був виконаний оператор SAVE TRANSACTION.
• ROLLBACK - відміняє всі зміни, зроблені в БД після оператора BEGIN TRANSACTION.

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

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

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

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

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

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

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

UPDATE USP

SET OCENKA = 3 WHERE PNUM = 2003;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛЕКЦІЯ№

ПЛАН

1. Представлення

2.Створення, видалення і оновлення представлень

Представлення

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

Розглянемо приклад створення уявлення на основі відношення SP (Оцінки), приведеного на мал. 1. 11

СТВОРИТИ УЯВЛЕННЯ VIEW1

ДЛЯ (SP.OCENKA >= 3) [NAME, SN, OCENKA]

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

У прикладі створюється уявлення VIEW1. яке складається з трьох атрибутів - NAME, SN і OCENKA, причому вибиратимуться тільки ті кортежі, для яких оцінка буде більше або рівно 3, - грубо кажучи, інформація по успішних студентах. З таким уявленням користувач може працювати, як з реально існуючим.

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

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

Реструктуризація даних має на увазі, що інформація залишається та ж, але змінюється її розташування, наприклад, за рахунок перегруповування атрибутів відносин. Припустимо, що відношення SP через які-небудь причини необхідно розділити на два - SPO і SPP, що приведене на мал. 1.23.

SPP
SN	PN	NAME

Мал. 1.23. Структура відносин SPO і SPP

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

СТВОРИТИ УЯВЛЕННЯ SP SPP З'ЄДНАТИ З SPO

Будь-яка призначена для користувача програма після цього замість відношення SP використовуватиме створене уявлення для маніпуляції з даними.

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

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

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

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

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

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

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

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

⇐ Предыдущая 1 2 345 6 7 8 Следующая ⇒