Юрчишин В.М., Клим Б.В. і інші. Організація баз даних

Подождите немного. Документ загружается.

журналу у файл, обидва процеси: LGWR і ARCH повинні

працювати без збоїв.

Контрольна точка, інакше – точка зберігання, застосовується

для примусового запису в файл змін, виконаних у БД

довготривалою транзакцією. Практично вона розділює

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

за допомогою такої команди:

SAVEPOINT ім’я точки;

Завершення транзакції може відбуватися неявно при

наступленні однієї з вищеперечислених подій або явно. Для явного

завершення служить команда:

COMMIT WORK;

Слово WORK може бути опущеним. Явне завершення транзакції є

хорошим тоном ведення БД.

Відкот транзакції до точки зберігання або до початкового стану

БД забезпечується за допомогою такої команди

ROLLBACK WORK;

Наведемо такі приклади відкоту транзакції та використання

котрольної точки:

SQL> CREATE TABLE Tab(Pole INTEGER);

Table created

SQL> INSERT INTO Tab VALUES(1);

1 row created

SQL> SELECT COUNT(*) FROM Tab;

COUNT(*)

Отже, була створена таблиця Tab, яка мала одне поле Pole

цілого типу. У це поле було внесено значення 1, тобто таблиця

мала один запис, тому команда SELECT видала значення 1.

SQL> ROLLBACK;

Rollback complete

SQL> SELECT COUNT(*) FROM Tab;

No rows selected

Відбувся відкот транзакції командою ROLLBACK, тобто була

відмінена команда внесення запису в таблицю, тому виконання

команди SELECT завершилося видачею повідомлення про те, що

записи відсутні.

SQL> INSERT INTO Tab VALUES(1);

1 row created

SQL> SAVEPOINT S;

Savepoint created

В таблицю Tab було повторно занесено один запис, після чого

була встановлена контрольна точка з іменем S.

SQL> INSERT INTO Tab VALUES(2);

1 row created

SQL> SELECT COUNT(*) FROM Tab;

COUNT(*)

В таблицю Tab був занесений ще один запис. Оскільки вона

мала два записи, команда SELECT видала число 2.

SQL> ROLLBACK TO S;

Rollback complete

SQL> SELECT COUNT(*) FROM Tab;

COUNT(*)

Відбувся відкот транзакції до контрольної точки S, тому в

таблиці залишився лише один запис, що й видала команда SELECT.

4.3.2 Несуперечність і паралельна обробка

Відмінною рисою СУБД промислового рівня є підтримка

паралельної роботи багатьох користувачів. Користувачі формують

запити на доступ і зміну інформації в базі даних асинхронно, тобто

в довільні моменти часу, без взаємної погодженості дій.

Однією з базових вимог до СУБД є підтримка цілісності даних,

тобто такого стану, коли в довільний момент часу дані адекватно

відображають стан змодельованих у базі об’єктів. Суть проблеми

полягає в тому, що в процесі керування паралельною роботою

СУБД дані можуть бути змінені чи модифіковані не в належній

послідовності. Перелічимо деякі ситуації, які можуть виникнути

через асинхронне виконання дій користувачів:

– “проблема зниклого відновлення” – два користувачі

запитують з бази одні й ті ж дані і використовують для

якихось розрахунків, а потім намагаються їх обновити;

– “проблема проміжних даних” – користувач зробив помилкове

відновлення на основі проміжних даних, внесених іншим

користувачем;

– “проблема рядків-фантомів” – той самий запит, виконаний

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

різних результати.

Рішенням проблеми погодженої зміни бази даних може бути

формування черги користувачів до кожного ресурсу системи

(таблиці, представлення, індекса і т.п.). Його недоліком буде різке

зниження продуктивності. Якщо кількість користувачів

обчислюється десятками чи сотнями, то блокування дефіцитного

ресурсу може спричинити збільшення затрат часу на очікування.

Сервер Oracle використовує інший метод – багатоверсійну

модель даних. Механізм версійності реалізований через сегменти

відкоту, в яких зберігаються старі версії даних. При цьому Oracle

не забезпечує гарантованого читання попередніх версій даних

через можливе їхнє затирання в сегментах відкоту. У випадку

затирання старих версій даних видається помилка "ORA-1555

Snapshot too old, rollback segment too small". Ця ситуація характерна

для складних запитів, які виконуються тривалий час. Чим довше

виконується команда, тим більша ймовірність затирання старих

версій даних, якими вона користується.

Oracle забезпечує несуперечність даних на рівні оператора і на

рівні транзакції. Для явної вказівки технології використання даних

на рівні оператора введено поняття рівня ізоляції, який задається

користувачем. Він дозволяє знайти деякий компроміс між

ступенем ізоляції й ефективністю роботи. Існують такі чотири рівні

ізоляції:

–

SERIALIZABLE – під час однієї транзакції одержимо ідентичний

запит, незалежно від інших паралельно виконуваних

транзакцій. Результати будуть такими, ніби транзакції

виконувалися послідовно;

–

REPEATABLE READ – повторюване читання. Транзакція не має

доступу до проміжних чи остаточних результатів інших

транзакцій, які виконують відновлення даних. Однак під час

транзакції можна побачити рядок, доданий у базу даних

іншою транзакцією. Тому той самий запит, виконаний двічі

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

–

READ COMMITTED – завершене читання. Транзакція не має

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

остаточні результати інших паралельно виконуваних

транзакцій можуть бути доступні. Протягом транзакції двічі

можна виконати запит і знайти, що окремі записи були

змінені іншим додатком;

–

READ UNCOMMITTED – незавершене читання, дозволяє читати

“брудні дані”.

Несуперечність даних на рівні транзакції забезпечується

командою:

SET TRANSACTION рівень несуперечності даних;

Всього є такі три рівні несуперечності даних:

–

READ WRITE – читаються дані, зафіксовані іншими

транзакціями під час виконання даної транзакції. Такою є

кожна транзакція за замовчуванням;

–

READ ONLY – транзакція лише для читання, в її середині

допустимі лише запити. Видаються дані, які знаходилися в

базі даних на момент початку транзакції;

–

ISOLATION LEVEL SERIALIZABLE – теж видаються дані, які

знаходилися в базі даних на момент початку транзакції. Якщо

декілька користувачів одночасно змінюють одні й ті ж дані,

то результати їхньої роботи виглядають так, ніби вони

працювали послідовно один після другого.

Запитання для самоконтролю

1. Що таке транзакція?

2. Для чого служить контрольна точка?

3. Що таке dirty-список?

4. Що відбувається під час завершення транзакції?

5. Що відбувається під час відкоту транзакції?

6. Розрізніть журнал реєстрації транзакцій, буфер і файл

журналу транзакцій

7. Що таке багатоверсійна модель даних?

8. Як забезпечується несуперечність даних при паралельній

роботі користувачів?

4.4 Аутентифікація користувача

4.4.1 Користувачі БД

Користувачем є об’єкт Oracle, який може виконувати дії над

об’єктами БД відповідно до існуючої технології. Оператор

визначення користувача має такий синтаксис:

CREATE USER ім'я_користувача IDENTIFIED BY пароль | EXTERNALLY

[DEFAULT TABLESPACE ім'я_табличної_області1]

[TEMPORARY TABLESPACE ім'я_табличної_області2]

[QUOTA число_одиниць [К|M]| UNLIMITED ON ім'я_табличної_області]

[PROFILE ім'я_профілю];

Параметр ім'я_користувача задає ім’я, під яким користувач

реєструється в системі. Ключове слово BY означає, що пароль буде

зазначений явно параметром пароль. Якщо заданий параметр

EXTERNALLY, то сервер перевіряє відповідність зареєстрованого

операційною системою користувача до користувача Oracle.

Конструкція DEFAULT TABLESPACE вказує ім’я табличної

області iм’я_табличної_області1 користувача. Якщо вона не

зазначена, то за замовчуванням для об’єктів користувача буде

використовуватися таблична область SYSTEM. Зважаючи на те, що

в табличній області SYSTEM розміщений словник даних,

використовувати її для користувальницьких об’єктів недоцільно.

Конструкція TEMPORARY TABLESPACE вказує системі ім’я

табличної області ім'я_табличної_області2, відведеної для тимчасових

сегментів користувача. Тимчасові сегменти використовуються для

збереження проміжних даних. Багатокористувацька система

пред’являє підвищені вимоги щодо продуктивності та захищеності,

тому табличні області для тимчасових сегментів і для об’єктів

користувача бажано рознести по різних фізичних носіях. Якщо

ключове слово TEMPORARY TABLESPACE не зазначене, то за

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

таблична область SYSTEM, що теж не бажано.

Ключове слово QUOTA задає обмеження на простір у конкретній

табличній області. Максимально допустимий простір задається

параметром число_одиниць у мегабайтах (М), кілобайтах (К) або в

байтах, якщо не зазначено ні М, ні К. Слово UNLIMITED дозволяє

користувачу замовляти об’єм простору без обмежень. При

реєстрації користувача можна використовувати ключове слово

QUOTA декілька разів і визначити для користувача допустимий

простір у декількох табличних областях.

Ключове слово PROFILE призначає користувачу профіль

ім'я_профілю. Якщо ключове слово PROFILE не зазначено, то

користувачу приписується профіль DEFAULT.

Для реєстрації користувачів необхідно мати привілей CREATE

USER.

Розглянемо приклад створення користувача user1, який має

пароль stud і якому призначена таблична область nafta з розмірами в

1 мегабайт, та дозволом на використання табличної області gas

місткістю в 500 кілобайт.

SQL> CREATE USER user1 IDENTIFIED BY stud

2 DEFAULT TABLESPACE nafta

3 QUOTA 1M ON nafta

4 QUOTA 500K ON gas;

Оператор зміни користувача Oracle використовує такий

синтаксис:

ALTER USER ім'я_користувача IDENTIFIED BY пароль|EXTERNALLY

[DEFAULT TABLESPACE ім'я_табличної_області1]

[TEMPORARY TABLESPACE ім'я_табличної_області2]

[QUOTA число_одиниць [К|М]| UNLIMITED ON ім'я_табличної_області]

[PROFILE ім'я_профілю];

Розглянемо приклад, який ілюструє заміну пароля на newstud

користувача user1:

SQL> ALTER USER user1 IDENTFIED BY newstud;

Для вилучення користувача необхідно мати привілей DROP

USER, оператор вилучення має такий синтаксис:

DROP USER ім'я_користувача [CASCADE];

Параметр ім’я_користувача задає ім’я користувача в системі.

Якщо зазначене ключове слово CASCADE, то автоматично

вилучаються всі його об’єкти, всі обмеження цілісності, які мають

посилання на первинні й унікальні ключі таблиць. Представлення,

синоніми, функції і процедури, які посилаються на об’єкти

користувача, позначаються як недійсні. Якщо ключове слово

CASCADE не зазначене, а в схемі користувача містяться якісь його

об’єкти, то повертається повідомлення про помилку. Також буде

видано повідомлення про помилку, якщо користувач підключений

у момент спроби його вилучення. Розглянемо приклад, який

ілюструє виконання операції вилучення користувача:

SQL> DROP USER user1;

DROP USER user1

ERROR at line 1:

ORA-01922: CASCADE must be specified to drop 'user1'

SQL> DROP USER user1 CASCADE;

User dropped.

Кожен користувач Oracle повинен мати спеціальний

ідентифікатор: ім’я, яке інакше називають точкою входу.

Створення нового ідентифікатора здійснюється уповноваженим

користувачем або адміністратором за допомогою вищеописаного

речення CREATE USER. З позиції СУБД джерела, які пред’явили

ідентифікатор, нерозрізненні. Тобто, користувачем може бути як

реальна людина, що сидить за терміналом, так і прикладний

процес, для системи обидва об’єкти тотожні.

Заново створений користувач не має ніяких прав на виконання

операцій з об’єктами системи. Наприклад, при спробі одержати

доступ до системи командою CONNECT система відкине спробу

доступу, видавши повідомлення про відсутність необхідних прав

доступу в користувача. Для успішної реєстрації в системі

адміністратор повинен надати користувачу привілей на утворення

сеансу за допомогою такої команди:

GRANT CREATE SESSION TO ім'я_користувача;

Приклад взаємодії користувача із системою: реєстрація

користувача user1 з паролем stud (нагадаємо, що користувач system

є системним, тому має для цього всі права і привілеї):

SQL> CONNECT system/manager @Komp1416;

Connected.

SQL> CREATE USER user1 IDENTIFIED BY stud;

User created.

SQL> CONNECT user1/stud @Komp1416;

ERROR: ORA-01017: invalid username/password;

logon denied

Warning: You are no longer connected to ORACLE.

SQL> CONNECT system/manager@Komp1416;

Connected.

SQL> GRANT CREATE SESSION TO user1;

Grant succeeded.

SQL> CONNECT user1/stud @Komp1416;

Connected.

У цьому прикладі був створений користувач user1. Він ще не

мав ніяких прав, тому під час його спроби під’єднатися до БД

система не тільки видала повідомлення про помилку, але й

розірвала з’єднання з користувачем system.

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

сервер Oracle запускає на виконання стандартну процедуру, яка

забезпечує підтвердження дійсності або аутентифікації. Звичайно,

що для підтвердження дійсності користувач повинен ввести

пароль. У Oracle підтримується також варіант винесення

процедури аутентифікації на рівень операційної системи. У цьому

випадку сервер вибирає ідентифікатор користувача з інформації

сеансу його роботи з операційною системою і на основі цієї

інформації дозволяє чи забороняє користувачу підключення.

4.4.2 Привілеї

Привілеєм (privilege) є дозвіл на виконання в системі

визначеної дії. Не маючи відповідного привілею, користувач не

може ні одержати доступ до даних, ні виконати якусь дію.

Сервер бази даних має певний набір привілеїв, вони можуть

змінюватися: призначатися нові або скасовуватися старі. Множина

базових привілеїв визначена в стандарті ANSI SQL, крім того, в

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

70 типів.

В Oracle реалізовано принцип мінімальних привілеїв, суть

якого полягає в тому, що користувачу повинно бути явно

дозволено виконання кожної дії в системі. Тобто немає жодної дії,

дозволеної користувачу за замовчуванням.

Усі привілеї можуть бути розділені на два класи: системні

(system privelege) і доступу до об’єктів (object privelege).

Системний привілей надає користувачу право на виконання

певної операції в базі даних. Наприклад, користувач із системним

привілеєм ALTER TABLESPACE може змінювати будь-яку табличну

область, за винятком деяких обмежень на табличну область

SYSTEM. Користувач із системним привілеєм SELECT ANY TABLE

може виконувати вибірку з будь-якої таблиці БД. Оскільки

системні привілеї пов’язані з можливістю виконання глобальних

змін у базі даних, їхнє надання повинно ретельно плануватися.

Привілей доступу до об’єкта дозволяє користувачу

виконувати певну операцію над визначеним об’єктом, наприклад,

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

формувати будь-які запити до даної таблиці, але не має права

модифікувати дані цієї таблиці чи формувати який-небудь запит до

іншої таблиці.

Привілеї доступу до об’єкта керують роботою користувача бази

даних з конкретним об’єктом. Наприклад, адміністратор може

керувати списком користувачів, які мають право виконувати

вибірку з конкретної таблиці. Для цього він надає привілеї SELECT

на таблицю конкретним користувачам чи ролям. Аналогічно можна

надати на таблицю повноваження INSERT, UPDATE та DELETE.

Механізм привілеїв доступу до об’єкта надає адміністратору

можливість детально керувати доступом до інформації бази даних.

Необхідно відзначити важливий принцип: у своїй схемі (з

об’єктами, власником яких є користувач) дозволені будь-які

операції, тобто зі своїми таблицями, представленнями,

збереженими програмами і т. п. користувач вільний робити що

завгодно. Якщо привілеїв виявилося досить, щоб створити об’єкти,

то навіть після скасування привілеїв користувач, як і раніше, зможе

робити будь-які дії з уже існуючими об’єктами. З цієї причини

відсутні системні привілеї DROP TABLE, DROP VIEW і т.п. (існують

DROP ANY TABLE, DROP ANY VIEW). Різниця між привілеями, у

назвах яких є присутнім або відсутнім ключове слово ANY, полягає

в тому, що в першому випадку можна робити дії з об’єктами в

інших схемах, а в другому – тільки у своїй.

Цей принцип можна використовувати для побудови захисту

даних від несанкціонованого доступу, створивши, наприклад, всі

об’єкти додатка в одній схемі і скасувавши користувачу-власнику

привілей CREATE SESSION та надавши необхідні привілеї іншим

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

доступу до всіх даних додатка відразу. Зрозуміло, що при цьому

слід обмежено використовувати системні привілеї, такі як SELECT

ANY TABLE і системні облікові записи.

Для надання системних привілеїв конкретному користувачу

використовується команда GRANT. Користувач, який видав

команду GRANT, повинен мати всі системні привілеї, тобто

системний привілей GRANT ANY PRIVILEGE. Його можна надати

користувачу за допомогою команди:

GRANT GRANT ANY PRIVILEGE TO ім'я_користувача;

Оператор визначення системних привілеїв використовує такий

синтаксис:

GRANT перелік_системних_привілеїв

ТO перелік_користувачів або PUBLIC

[WITH ADMIN OPTION];

Повний список значень параметра перелік_системних_привілеїв

можна знайти в розділі документації Oracle Server SQL Reference.

Розглянемо декілька прикладів.

Нехай користувачу user1 наданий системний привілей CREATE

TABLE, тоді команда створення таблиці Таb проходить успішно.

Спроба створити таблицю Таb у схемі користувача user2

відкидається системою. Після надання привілею CREATE ANY TABLE

ця операція виконується успішно.

Приклад, який ілюструє цей протокол взаємодії користувача з

системою Oracle, має такий вигляд:

SQL> CONNECT user1/stud @Komp1416;

Connected.

SQL> CREATE TABLE Tab(Pole1 NUMBER);

Table created.