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

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

Trigger created.

SQL> insert into Kilnyt values(100);

2 /

insert into Kilnyt values(100)

ERROR at line 1:

ORA-20002: Число ниток не може бути >15

ORA-06512: at "SYSTEM.TRIGKILNYT", line 2

ORA-04088: error during execution of trigger 'SYSTEM.TRIGKILNYT'

SQL> insert into Gazpr (Kilnyt) values(3);

2 /

1 row created.

Слід сказати, що одного разу запущений тригер спичинює

постійну подальшу перевірку умови свого запуску. Якщо умови

змінилися, то треба й перезапустити тригер.

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

1. Які види підпрограм має PL/SQL?

2. Як можна запустити підпрограму на виконання?

3. Які засоби забезпечують зміну або незмінність вхідних

параметрів у тілі підпрограми?

4. Чим відрізняється структура програми мовою PL/SQL від

VBA?

5. Що таке курсор і які є їх види?

6. Чи можна створити запит без курсора?

7. Якими засобами мови PL/SQL забезпечується незалежність

типів змінних програми від типів полів таблиць?

8. Якого виду помилки можна перехоплювати засобами

обробки виняткових ситуацій?

9. Для чого потрібна генерація виняткової ситуації?

10. Для чого служить тригер?

11. Як запускається тригер на виконання?

12. На які події і як реагує тригер?

13. Як перезапустити тригер?

14. Як забезпечується аварійне завершення програми при

виникненні виняткової ситуації?

131

4.7 Розподілені БД

4.7.1 Основні поняття

Розподіленою називається логічно єдина БД, частини якої

(можливо дані одної таблиці) розташовані в декількох вузлах

мережі. В цих вузлах можуть стояти різнотипні комп’ютери з

різними операційними системами. Вони можуть знаходитися за

сотні і тисячі кілометрів одна від другої, але користувачі, в будь-

якому випадку, мають однаковий доступ до всієї інформації.

Вузли являють собою комп’ютери, зв’язані мережею, а не

процесори, які складають багатопроцесорну конфігурацію.

Характер середовища є слабозв’язаний, де кожний вузол має

власну операційну систему і функціонує незалежно.

Основною особливістю розподілення БД є прозорість, тобто

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

користувача, як одна. Всі програми створюються так, ніби вони

працюють з єдиною локальною БД. Їх можна налагодити на одній

БД, після чого розділити її на частини, розташовані в різних вузлах

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

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

обов’язково навіть знати де саме фізично знаходиться інформація,

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

виконують засоби СУБД.

Газонафтопромисловий комплекс являє собою порівняно

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

вуглеводнів, їх транспортування, переробку і доставку готової

продукції до споживача. Характерною особливістю його

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

тобто розташовані на різних територіях. Ці властивості

газонафтових підприємств якраз і складають об’єктивні

передумови широкого застосування розподілених БД.

Існують два способи доступу до віддалених даних:

1– декілька незалежних баз даних, зв’язаних між собою в одну

мережу, з віддаленим виконанням запитів і модифікацією

даних. Кожна з них може працювати самостійно або як

частина головної розподіленої бази даних;

2– реплікована база даних з використанням матеріалізованих

представлень (materialized view), або знімків (snapshots). В

132

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

фрагменти головної розподіленої бази даних.

Основними характеристиками віддалених СУБД є такі:

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

непротирічивість даних, транзакція, яка змінює дані в

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

успішно виконалась обробка у всіх вузлах. У випадку

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

транзакції анулюються;

2– горизонтальна і вертикальна фрагментація. Тобто таблицю

можно розділити на рядки (горизонтально) або на стовпчики

(вертикально), які розташувати в різних вузлах мережі;

3– незалежне дублювання даних, яке дозволяє створювати у

вузлах дублі (копії) даних без зниження продуктивності

програм і порушення цілісності даних;

4– можливість з’єднання таблиць, розташованих у різних

вузлах, та одержання розподілених представлень;

5– оптимизація розподілених запитів. Алгоритми виконання

складних операций (наприклад, з’єднання таблиць) повинні

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

її пропускну здатність, ступінь завантаження, об’єм

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

вибирати оптимальний вузол для відповідної операції;

6– розподілення обмеження цілістності даних. Якщо між

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

модифікації основної таблиці автоматично модифікуються й

таблиці, залежні від неї;

7– локальна автономія. Адміністратор БД даного вузла

повністю контролює свою локальну БД, тобто може

працювати незалежно від адміністраторів БД інших вузлів;

8– неперевна обробка. Команда, яка виконується в локальному

вузлі БД, не може бути перервана з іншого вузла, тобто в

кожному вузлі вона виконується незалежно і цілком;

9– незалежність від розміщення. Зміна місця зберігання даних

не змінює програми, які їх обробляють;

10– обробка розподілених транзакцій, що забезпечує

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

яка змінює декілька вузлів;

11– глобальна. обробка взаємних блокувань і конфліктних

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

133

Блокування даних може виконуватися в будь-якому вузлі

БД, тому необхідно виявляти і розв’язувати ситуації, коли

два різні вузли одночасно взаємно блокують один одного;

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

мереживних протоколів, типів СУБД та шлюзів (gateways);

Одним із способів передачі інформації в реплікованих БД є

використання розподілених транзакцій. Розподілена транзакція –

це процес одночасної модифікації даних на одному вузлі

розподіленої БД і передача змінених даних іншим базам даних з

використанням механізму двофазної фіксації змін. Перша фаза є

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

повідомлення про готовність інших БД до внесення змін. Під час

другої фази (фази фіксації) зміни вносяться. Управління

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

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

неможливо.

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

1–система А посилає повідомлення GET READY зв’язаним системам

В і С та робить відмітку в журналі;

2–якщо В або С готові виконати свою частину транзакції, то вони

посилають сигнал “Так”, роблять помітку в локальних журналах

і переходять у стан готовності, інакше посилають “Ні”;

3–система А очікує на всі відповіді. Якщо всі відповіді “Так”, тоді

посилається команда COMMIT. Якщо є хоча б одне “Ні”, то всім

посилається ROLLBACK;

4–B і С зобов’язані виконати команду і повідомити про результат.

Якщо в цей час відбувся збій (наприклад, на В), то після

відновлення працездатності система В, перевіривши журнал і не

знайшовши запису про завершення, знову зв’язується з А і

завершує транзакцію.

Цей метод суттєво завантажує мережу і збільшує її трафік.

Тому розподілену БД слід так проектувати так, щоб дані, які часто

змінюються, знаходилися або в локальній базі, або в одной

віддаленій.

4.7.2 Зв’язок з віддаленою базою даних

Використовувати об’єкти віддаленої БД можна двома

способами, а саме: прямо підключитися до віддаленої БД або

встановити з нею зв’язок. Встановлення зв’язку вигідніше тим, що

134

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

віддаленої БД. Зв’язки можна підтримувати як з базами даних

Oracle, так і з деякими іншими. Звичайно, що і на локальній, і на

віддаленій базі даних повинно бути встановлене спеціальне

програмне забезпечення. Наприклад, обидві обов’язково повинні

мати файл listener.ora.

Для створення зв’язку з віддаленою базою даних необхідно

мати в ній обліковий запис. Для цього облікового запису ім’я

користувача може збігатися з ім’ям користувача, який створює

зв’язок, а може й відрізнятися від нього.

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

CREATE [PUBLIC] DATABASE LINK ім'я_зв'язку_БД

[CONNECT TO ім'я_користувача IDENTIFIED BY пароль_користувача]

USING 'рядок_зв'язку';

Якщо ключове слово PUBLIC опущене, створюється зв’язок,

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

користувачам.

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

ім’я), яке задає специфікації зв’язку. В Oracle 8.0.5.0.0 таким ім’ям

є доменне ім’я або IP-адреса ПК.

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

віддаленої бази в запитах, посилаючись на них у фразі FROM так

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

зв’язку конструкція, яка містить ім’я користувача і пароль,

відсутня, то будуть використані ім’я і пароль поточного

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

до їхніх імен додається ім’я_зв’язку_БД, відділене символом @.

Запити, які використовують зв’язок з віддаленою базою даних,

підкоряються таким обмеженням:

– максимальна кількість зв’язків з віддаленими базами, які

можна використовувати в одному запиті, визначається

значенням параметра OPEN_LINKS файлу параметрів init.ora;

– використання команд мови маніпулювання даними INSERT,

DELETE, UPDATE вимагає наявності на сервері спеціальних

можливостей, реалізованих компонентом Distributed Options.

Розглянемо приклад визначення зв’язку nafta_link, який

використовує обліковий запис користувача user1 з паролем userstud

у віддаленій базі даних, зумовленою рядком зв’язку

135

mmm. Після успішного створення зв’язку з віддаленою базою даних

можна виконати запит до її таблиці Tab, як це показано прикладі:

SQL> CREATE DATABASE LINK nafta_link;

2 CONNECT TO user1 IDENTIFIED BY userstud

3 USING 'mmm

’

;

Database link created.

SQL> SELECT * FROM Tab@nafta_link;

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

мати привілей DROP ANY DATABASE LINK. Оператор знищення

зв’язку має такий синтаксис:

DROP [PUBLIC] DATABASE LINK ім'я_зв’язку_БД ;

Параметр PUBLIC задається, якщо зв’язок був загальним.

4.7.3 Синоніми

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

об’єктів бази даних. Як правило, синоніми створюються для

таблиць, представлень і послідовностей. Наявність синонімів

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

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

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

дані. Наприклад, синонім можна використати для того, щоб

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

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

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

CREATE [PUBLIC] SYNONYM [ім’я_схеми.]ім’я_синоніма

FOR [ім’я_схеми2.]ім’я_ об’єкта[@ім’я_зв’язку_БД];

Ключове слово PUBLIC означає, що синонім буде доступний

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

користувачу, який його створив.

Синонім повинен мати ім’я, відмінне від інших об’єктів даного

користувача. Параметр ім’я_синоніма – ім’я синоніма повинен

відповідати угодам з найменувань об’єктів Oracle. Параметр

ім’я_схеми задає ім’я існуючої в БД схеми. Для створення синоніма

136

в довільній схемі потрібні відповідні привілеї. Якщо ім'я_схеми для

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

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

Параметр ім’я_зв’язку_БД означає, що зв’язок з віддаленою БД

уже існує. Якщо параметр ім’я_схеми опущений, то синонім

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

зв’язком з віддаленою базою даних.

Параметр ім'я_схеми2 задає ім’я схеми, у якій знаходиться

об’єкт, для якого створюється синонім, а параметр ім’я_об’єкта

вказує на цей об’єкт.

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

або мати привілей DROP ANY SYNONYM. Оператор вилучення

синоніма має такий синтаксис:

DROP [PUBLIC] SYNONYM [ім'я_схеми.]ім'я_синоніма;

Тут необов’язкове ключове слово PUBLIC визначає факт

вилучення загального синоніма. Параметр ім'я_синоніма визначає

ім’я синоніма, який вилучається. Змінити синонім можна,

скасувавши його і призначивши заново.

4.7.4 Знімки

Знімок – це поіменована вибірка з однієї або декількох таблиць

чи представлень, зазвичайно розташованих у віддаленій БД, яка

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

знімка в рамках прийнятої технології, а саме: формування знімка

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

деякого розкладу. Використовуючи знімки, адміністратор БД

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

даних, які реально необхідні для виконання їхньої роботи.

Для того щоб механізм знімків працював, на серверах локальної

і віддаленої баз даних повинен бути встановлений пакет

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

відновлення знімків. Для створення знімків, які використовують

таблиці і представлення віддаленої БД, необхідно, щоб сервер був

установлений з додатковими можливостями.

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

синтаксис:

CREATE SNAPSHOT [ім'я_схеми.]ім'я_знімка

137

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

STORAGE розмір_пам'яті

[REFRESH [FAST | COMPLETE | FORCE]

[START WITH дата_1 ][NEXT дата_2 ]]

[FOR UPDATE] AS запит;

Ключове слово TABLESPACE визначає ім’я табличної області, у

якій буде розміщений знімок. Якщо значення цього параметра не

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

замовчуванням для користувача – власника схеми, яка містить

знімок.

Ключове слово STORAGE визначає обсяг зовнішньої пам’яті, яка

виділяється під знімок. Для великих знімків доцільно явно

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

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

Ключове слово REFRESH визначає технологію відновлення

знімка. Якщо заданий параметр COMPLETE, то для відновлення

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

Якщо задано параметр FAST (швидке відновлення), то для

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

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

файлі знімка. Параметр FORCE (використовується за

замовчуванням) означає, що рішення про технологію відновлення

знімка приймається системою (зазвичайно це швидке відновлення).

Ключове слово START WITH визначає дату першого

автоматичного відновлення знімка за допомогою параметра дaтa_1.

Природно, що параметр дaтa_1 повинен мати тип дати.

Ключове слово NEXT визначає за допомогою параметра дата_2

інтервал між автоматичними відновленнями знімка. Якщо ключове

слово REFRESH опущене, то автоматичного відновлення даних

знімка не відбувається. Також не відбувається автоматичного

відновлення даних знімка, якщо опущені ключові слова: START

WITH і NEXT. Тобто, зміни в майстрі-таблиці не поширюються на

дані знімка автоматично.

Ключове слово FOR UPDATE означає, що дані знімка можна

змінювати. Слово AS запит включає в знімок рядок, який є

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

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

не містить ключових слів ORDER BY або FOR UPDATE.

Для модифікації знімка можна скористатися командою ALTER

SNAPSHOT.

138

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

1. Перечисліть способи доступу до віддалених БД

2. Перечисліть основні характеристики віддалених БД

3. Що таке реплікація даних і які вона надає переваги та має

недоліки?

4. Чим характерна розподілена транзакція?

5. Опишіть механізм двофазної фіксації змін у БД, виконаних

розподіленою тразакцією.

6. Які умови повинні задовільняти БД для того, щоб вони могли

бути зв’язними?

7. Зі скількох зв’язаних БД можна одержати інформацію однією

командою?

8. Як можна дізнатися про кількість дозволених зв’язків з

віддаленими БД?

9. Інформацію якого виду можна одержати зі зв’язаних БД?

10. Що таке синонім і для чого він служить?

11. Що таке знімок і для чого він використовується?

12. Як забезпечується оновлення знімка?

13. Що таке швидке відновлення знімка?

139

5 Адміністрування БД

5.1 Адміністратор БД

DBA – Database Administrator або АБД – адміністратор бази

даних. Він одноосібно відповідає за її стан і має такі обов’язки:

 установка нового програмного забезпечення – це основний

обов’язок DBA. Він полягає в установці нових версій Oracle,

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

адміністрування СУБД;

 конфігурування програмного й апаратного забезпечення (разом

із системним адміністратором);

 досягнення безпеки. Це теж один із основних обов’язків DBA.

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

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

квотами, аудит, вирішення проблем безпеки та ін.;

 настройка продуктивності і моніторинг системи. DBA повинен

постійно перевіряти продуктивність СУБД, а при необхідності

виконувати настроювання. Навіть добре побудована система має

потребу в постійній перевірці і періодичному перенастроюванні;

 резервне копіювання і відновлення системи. Головна задача

DBA – зберігати дані в системі. Щоб робити це ефективно,

необхідно розробити процедуру резервного копіювання і

стратегію відновлення даних. Дуже важливо періодично

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

відновлення БД;

 процедура планового обслуговування. У задачу DBA входить

також обов’язок складання календара обслуговування СУБД.

Найкраще робити обслуговування СУБД вранці або у вихідні

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

відмови БД. В обслуговування входять архівування, тестування і

настроювання;

 локалізація неполадків. У випадку збою СУБД в обов’язки DBA

входить відновлення працездатності чи допомога в рішенні цієї

проблеми. Слід також передбачувати проблеми, які можуть

виникати в майбутньому;

 відновлення системи після збою. Оскільки збій системи

спричиняє втрату користувачами доступу до своїх даних, DBA

зобов’язаний якнайшвидше відновити роботу системи. Добре

підготовлений DBA має план відновлення системи після збою.

140