Архітектура бази даних Oracle

Термін база даних Oracle використовується для позначення фізичної та логічної структур даних спільно зі всією службовою інформацією. Щоб розділити опис логічної організації даних від способів їх зберігання і доступу до них, Oracle використовується дворівнева організація БД. Об'єкти верхнього (логічного) рівня називаються логічними структурами, а об'єкти нижнього (фізичного) рівня – фізичними структурами БД.

Опишемо фізичну організацію БД Oracle. Фізично БД Oracle організована як сукупність файлів, які створюються звичайними засобами операційної системи. Таким чином, основою фізичного рівня є файл.

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

1) файл параметрів ініціалізації;

2) керуючий файл;

3) журнали реєстрації транзакцій;

4) файли трасування.

До призначених для користувача об'єктів фізичного рівня БД відносяться файли даних.

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

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

Файли журналу реєстрації транзакцій діляться на оперативні та архівні. Оперативні файли журналу реєстрації транзакцій використовуються для запису вмісту буфера журналу транзакцій. Ці журнали зберігають відомості про всі транзакції, які так чи інакше пов'язані з змінами вмісту БД і при необхідності можуть бути використані для відновлення БД. Мінімальна кількість оперативних файлів журналу реєстрації транзакцій дорівнює двом. Запис в них проводиться по черзі. Файл журналу реєстрації транзакцій, в який проводиться запис, називається активним. Після заповнення одного файлу журналу реєстрації транзакцій система перемикається на наступний файл, а інформація першого файлу починає перезаписуватися в архівні файли журналу реєстрації транзакцій. Архівні файли журналу реєстрації транзакцій спільно з створюваної регулярно копією БД дозволяють повністю відновити зміст бази, якщо відбудеться перекручення або втрата інформації БД. В цілях забезпечення безперебійної роботи системи створюються групи (як мінімум два) оперативних файлів журналу реєстрації транзакцій, де кожна група складається з безлічі однакових елементів. Як тільки група стає активною, чергова запис у журналі здійснюється паралельно по всі елементи групи.

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

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

Інформація про файли даних, складових фізичний простір БД, зберігається в представленні словника даних DBA_DATA_FILES

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

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

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

Інформаційна частина блоку містить рядки даних. При приміщенні чергової рядка в блок для неї формується внутрішня інформаційна структура Oracle – ROWID, що представляє собою фізичну адресу розміщення рядка. Ця адреса залишається незмінним до видалення рядка або реорганізації сегмента і має формат: BBBBBBBB.RRRR.FFFF, де: BBBBBBBB – шістнадцятковий номер блоку в файлі даних, в якому знаходиться рядок; RRRR – шестнадца

теричный номер рядка в блоці; FFFF – шістнадцятковий номер файла, що містить блок.

Логічна структура БД Oracle складається з компонентів користувача. Форма і призначення об'єктів логічної структури мають сенс тільки в контексті сервера Oracle. До них відносяться табличні простору (tablespace), сегменти (segments) і экстенты (extents).

Табличний простір – це логічний об'єкт, який використовується для групування даних з метою організації більш чіткої структури БД. В одне табличне простір користувач БД може помістити логічні об'єкти, близько пов'язані між собою. Наприклад, всі таблиці, які використовуються одним і тим же додатком, можуть бути об'єднані в одне табличне простір. Фізично табличне простір реалізовано сукупністю одного або декількох файлів даних. Кожен файл даних розміщений в одному табличному просторі і зберігає поточні дані цього простору. Файли даних табличного простору створюються одночасно з створенням табличного простору. При створенні БД створюється табличне простір SYSTEM, що містить файли словника даних і інших службових таблиць і уявлень. Імена табличних просторів, за винятком SYSTEM, можуть вибиратися довільно. Табличні простору можуть бути додані, видалені з БД. Крім цього, додаються табличні простору можуть переводитися в автономне стан (стан блокування) або в оперативне стан (доступні для роботи). Табличне простір SYSTEM не може бути видалено, ні переведено на автономне стан. При формуванні об'єкта БД потрібно вказувати табличне простір, яким воно буде належати. Після цього дані (які, власне, і утворюють об'єкт) будуть зберігатися у файлах даних, які належать вказаним табличного простору. Тому рядки з однієї таблиці, наприклад, можуть зберігатися в декількох файлах даних. Інформація про всіх табличних просторах БД і їх статус зберігається в представленні словника БД DBA_TABLESPACES.

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

1) сегменти даних (data segments);

2) сегменти індексів (index segments);

3) сегменти відкату (rollback segments);

4) тимчасові сегменти (temporary segments).

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

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

Экстенты – це об'єкти інформаційної структури зберігання даних. Кожен сегмент БД складається з одного або декількох небачених. Зовнішня пам'ять для об'єкта БД виділяється порціями з певного числа блоків. У файлах БД ці блоки повинні бути суміжними. Група суміжних блоків називається экстентом. Слід зазначити, що пам'ять для об'єктів виділяється экстентами, які можуть знаходитися на різних дисках. Після виділення экстента об'єкту ці блоки не можуть бути використані іншими об'єктами БД. При створенні об'єкту система Oracle автоматично розподіляє у відповідний сегмент початковий экстент для даного об'єкта. Якщо початковий сегмент повністю заповнюється даними під час роботи з об'єктом, то Oracle автоматично виділяє додаткові экстенты для цього об'єкта. При видаленні інформації экстенты звільняються, але залишаються пов'язаними з об'єктом (за винятком розміри сегмента відкату і тимчасового сегмента) до тих пір, поки не буде виконана операція видалення об'єкта. Наприклад, якщо видалити всі рядки таблиці, то розподілені їй блоки все одно залишаються закріпленими за цією таблицею. Таблицю потрібно видалити (оператор DROP) або скорочено (оператор TRUNCATE), щоб звільнити зовнішню пам'ять, виділену таблиці. Видалення об'єктів може призвести до фрагментації. В системі Oracle усуненням фрагментації займається системний монітор SMON. Коротко опишемо призначення перерахованих типів сегментів.

Сегменти даних призначені для зберігання звичайних таблиць і кластерних таблиць, отже, містять рядки таблиць даних. Экстенты для таблиці можуть бути виділені з різних файлів, але ці файли повинні обов'язково належати одному табличного простору. Однієї таблиці відповідає один сегмент.

Сегменти індекс ів служать для зберігання індексів – це спеціальні таблиці, які містять інформацію з ключового стовпця таблиці і ідентифікатор номера рядка – ROWID.

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

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

1) створення індексу;

2) використання фраз ORDER BY, DISTINCT чи GROUP BY в операторі SELECT; 3) використання операторів роботи з множинами UNION, INTERSECT, MINUS; 4) створення з'єднань таблиць;

5) використання деяких типів підзапитів.

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

1 1.5. АРХІТЕКТУРА ПРИМІРНИКА БАЗИ ДАНИХ ORACLE

Примірник бази даних (Database Instance) Oracle являє собою сукупність складного комплексу взаємодіючих процесів і певних структур оперативної пам'яті. Кожна БД Oracle має зв'язаний з нею примірник, причому до тих пір, поки не буде використовуватися опція Oracle Parallel Server, для БД формується лише один примірник. Організація примірника дозволяє СУБД обслуговувати безліч типів транзакцій, ініційованих одночасно великою кількістю користувачів, і в той же час забезпечувати високу продуктивність, цілісність і безпеку даних. Процеси примірника. Всі процеси, що працюють з БД Oracle, можна поділити на системні і користувальницькі. Системні процеси Oracle діляться на дві категорії: серверні процеси і фонові процеси. Користувальницькі процеси запускаються користувачами БД, які для здійснення доступу до БД використовують прикладні засоби Oracle, такі як, наприклад, інтерактивну середу SQL*Plus, генератор звітів Oracle Reports, генератор форм Oracle Forms, або різні прикладні програми. Кожен процес користувача підключається до процесу сервера, який може бути жорстко пов'язаний з одним процесом користувача, або розділятися між багатьма користувацькими процесами. Серверний процес аналізує і виконує передані йому оператори SQL і повертає результати призначеного для користувача процесу. Крім того, серверний процес зчитує блоки даних з файлів даних і розміщує їх в кеш-буфері даних. Фонові процеси Oracle працюють у фоновому режимі. Вони виконують різні функції, необхідні для підтримки роботи БД, а також здійснюють асинхронний ввід-вивід даних. Фонові процеси поділяють на обов'язкові та необов'язкові.

Обов'язкові фонові процеси присутні в будь-якій конфігурації екземпляра Oracle і до них ставляться чотири процесу.

1. Процес DBWR (Database Writer), здійснює запис модифікованих блоків даних з кеш-буфера даних назад в БД.

2. Процес LGWR (Log Writer), здійснює запис інформації з буфера журналу транзакцій, розташованого в оперативній пам'яті, оперативні файли журналу транзакцій.

3. Процес SMON (System Monitor) – системний монітор, який здійснює моніторинг примірника БД

. 4. Процес PMON (Process Monitor) – монітор процесів, контролює процеси примірника.

Опишемо необов'язкові фонові процеси.

1. CKPT (Checkpoint Process) – процес контрольної точки. Він обробляє подію «контрольна точка», що виникає в системі при певних умовах. Цей процес може бути присутнім в будь-якій конфігурації екземпляра Oracle.

2. ARCH (Archiver) – процес запису журналу архіву. Він забезпечує копіювання оперативних файлів журналів транзакції в архівні файли при їх заповненні. Цей процес може бути присутнім в будь-якій конфігурації екземпляра Oracle.

3. Dnnn (Пошук), n = 0, 1,..., 9, – процеси-диспетчери. При обслуговуванні користувальницьких процесів розділяються серверними процесами, одним або декількома, вони виконують синхронізацію взаємодії серверних і користувальницьких процесів.

4. RECO (Recoverer) – процес відновлення. Він відповідає за відновлення незавершених транзакцій в розподіленій БД в конфігурація екземпляра Oracle Distributed

5. SNPn (Snapshots Process), n = 1, 2,..., 9, A,..., Z, – ці процеси використовуються для отримання знімків віддалених БД у випадку розподіленої БД в конфігурація екземпляра Oracle Distributed.

6. LCKn (Parallel Server Lock Process), n = 0, 1,..., 9, – процеси блокування. Ці процеси в конфігурації екземпляра Oracle Parallel Server відповідають за координацію блокувань БД, що встановлюються різними екземплярами Oracle.

7. Pnnn, n = 0, 1,..., 9, – процеси паралельних запитів. Ці процеси використовуються в конфігурації екземпляра Oracle Parallel Query для обслуговування паралельно виконуваних частин запитів.

Структури пам'яті примірника. Кожному користувачу процесу виділяється область пам'яті, яка називається глобальної областю процесу (process global area) і скорочено позначається PGA. Вміст PGA залежить від режиму підключення користувацького процесу до процесу сервера. Якщо користувальницький процес взаємодіє з виділеним серверним процесом, то в PGA розміщується інформація про поточний сеанс роботи користувача, стек і інформація про стан курсору. Інформація про поточному сеансі, в свою чергу, включає дані, необхідні для системи забезпечення безпеки, та дані про використовуваних ресурсах. В стеку містяться локальні змінні, а в області стану курсору – поточна інформація про розташування курсору, повертаються рядки і зворотний код курсору. Якщо ж користувальницький процес пов'язаний з поділяється серверним процесом, то інформація про поточний час та поточний стан курсору зберігається в глобальній системної області.

Крім того, для всіх процесів виділяється загальна область пам'яті, яка називається глобальною областю системи (system global area – SGA). В SGA зберігаються структури пам'яті, необхідні для маніпулювання даними, аналізу пропозицій SQL і кешуванням транзакцій. Ця область колективна, тобто до неї одночасно має доступ безліч процесів, які можуть зчитувати та модифікувати містяться в ній дані.

Глобальна область системи складається з наступних компонентів:

1) роздільний пул (shared pool);

2) кеш-буфер бази даних (database buffer cache);

3) буфер журналу транзакцій (redo log buffer).

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

Роздільний пул кешує інформацію, використовувану при розборі і виконанні операторів SQL. Роздільний пул містить два основних розділи: кеш бібліотек і кеш словника даних.

Кеш бібліотека зберігає текст SQL-виразів, формати лексичного аналізатора і план виконання пропозицій SQL. Крім того, тут же містяться заголовки пакетів PL/SQL і процедур, які можуть спільно використовуватися користувацькими процесами. Сервер Oracle використовує кеш бібліотек для підвищення швидкості виконання операторів SQL. Коли передається чергове SQL-вираз, сервер в першу чергу переглядає кеш в пошуках такого виразу, переданого раніше. Якщо воно знайдено, то використовується відповідне йому дерево лексичного аналізу та план виконання запиту, що позбавляє від необхідності формувати їх повторно. Кеш бібліотек містить і загальні області SQL, і локальні області SQL. Спільна область SQL включає дерево лексичного аналізу та план виконання SQL-вирази, а локальна область – інформацію, яка залежить від поточного сеансу роботи. Це можуть бути приєднані змінні, параметри оточення, стеки і буфери, необхідні при виконанні. Локальна область формується для кожної ініційованої транзакції і звільняється після того, як закривається відповідний курсор. Використовуючи ці структури пам'яті, сервер Oracle може повторно використовувати інформацію, загальну для всіх виразів SQL, а інформація, специфічна для даного сеансу, може бути обрана з локальної області. Локальна область SQL ділиться в свою чергу на перехідну (persistent) і область часу виконання (runtime). При цьому перехідна область містить інформацію, яка зберігає своє значення і може бути використана кількома виразами SQL, а область часу виконання – тільки інформацію для вираження, що виконується в поточний момент.

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

Кеш-буфер даних складається з буферів БД і зберігає інформацію, завантажену з БД серверними процесами. Всі модифікації над даними реалізуються в кеш-буфері. Є список, який відстежує частоту звернень до зберігаються в кеш-буфері блоків даних. Сервер переносить дані на диск відповідно до порядку їх розміщення в списку LRU (Least Recently Used, дослівно – «найбільш давно використовувалися»). Цей список відстежує звернення до блоків даних та враховує частоту звернень. Коли виконується чергове звернення до блоку даних, що зберігається в кеш-буфері, він поміщається в той кінець списку, який називається MRU (Most Recently Used – «тільки що використані»). Якщо серверу потрібно місце в кеш-буфері для завантаження нового блоку з диска, він звертається до списку LRU і вирішує, який із блоків перенести на диск, щоб звільнити місце для нового блоку. Блоки, найбільш віддалені у списку від MRU, найімовірніші кандидати на вилучення з кеш-буфера. Таким чином, найдовше залишаються в кеш-буфері ті блоки, до яких звернення виконується найчастіше. Модифіковані блоки називаються «брудними» (dirty) і поміщаються у відповідний dirty-список. У цьому списку відслідковуються всі модифікації блоків даних, виконані за час їх перебування в кэшбуфере і не зафіксовані на диску. Коли Oracle отримує запит на зміну даних, відповідні зміни виконуються в області кеш-буфера, а відомості про зміни в блоках заносяться в dirty-список; одночасно дані про виконані операції вносяться в журнал транзакцій. У подальшому при зверненні до блоків даних, які потрапили в dirty-список, будуть зчитуватися вже модифіковані значення, хоча самі дані можуть до цього часу ще не бути записані на диск. Сервер використовує відкладену многоблочную процедуру запису на диск з метою підвищення продуктивності. Відкладена процедура означає, що оновлення даних, виконане Oracle, не фіксується негайно в дисковій пам'яті. Перенесення цих dirty-блоків тому в БД здійснюється процесом DBWR при настанні одного з визначених подій, таких як «контрольна точка», «вивантаження файлу» та ін.

Буфер журналу транзакцій зберігає дані про транзакції до тих пір, поки вони не будуть переписані в оперативний файл журналу транзакцій. Це типовий циклічний буфер – він заповнюється від початку до кінця, і потім нова інформація знову записується в початок буфера. Після заповнення вміст буфера процесом LGWR переноситься в оперативний файл журналу транзакцій. Для того щоб гарантувати послідовний характер запису в буфер журналу, сервер Oracle управляє доступом до нього за допомогою засувок (latch). Така засувка являє собою не що інше, як блокування процесом Oracle певної структури в пам'яті – аналогічно блокування файлу або рядка таблиці. Процес блокує сторонні звернення до пам'яті, виділеної для буфера журналу транзакцій. Таким чином, якщо один процес наклав засувку на буфер, інші не можуть звернутися до нього до тих пір, поки фіксатор не буде знятий. Сервер Oracle обмежує кількість транзакцій, дані про яких заносяться в журнал одночасно.

11.6. ФОРМУВАННЯ БАЗИ ДАНИХ І ЕКЗЕМПЛЯРА ORACLE

База даних Oracle відкривається в три етапи.

1. Формування екземпляра Oracle (передустановочна стадія).

2. Установка БД примірником (настановна стадія).

3. Відкриття БД (стадія відкриття).

Примірник Oracle формується на предустановочной стадії запуску системи.На даній стадії зчитується файл параметрів Init.ora, запускаються фонові процеси і ініціалізується SGA. Цей файл визначає параметри конфігурації примірника, зокрема розмір структур пам'яті, кількість і тип фонових процесів. Ім'я екземпляра встановлюється у відповідності зі значенням змінної оточення Oracle_SID і необов'язково повинне збігатися з ім'ям БД (але, як правило, збігається). Наступна стадія настановна. Значення параметрів керуючого файлу з Init.ora визначають параметри БД, яка встановлюється екземпляром. Примірник Oracle створює табличне простір SYSTEM, словник даних, один сегмент відкоту і два оперативних файлу журналу транзакцій. На цій стадії доступ до керуючого файлу відкритий і можлива модифікація даних. На останній стадії відкривається БД. Примірник отримує винятковий доступ до файлів БД, імена яких зберігаються в керуючому файлі, і через нього вони стають доступні користувачеві. Якщо на другому або третьому етапах відбудеться збій, то формується так званий «порожній» примірник Oracle, який сам буде функціонувати, але доступ до БД буде відсутній.

У процесі формування можуть бути отримані примірники Oracle різної конфігурації:

1) примірник з типовою структурою;

2) конфігурація Parallel Server;

3) конфігурація Distributed;

4) конфігурація Parallel Query.

Розглянемо докладніше різні конфігурації примірників.

Примірник з типовою структурою включає основні фонові процеси і при необхідності до них додаються процес архівації – ARCH і/або процес контрольної точки – CKPT.

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

Конфігурація Distributed використовується у випадку розподіленої БД. Вона являє механізми розвиненого симетричного тиражування, які забезпечують можливість поширювати дані по окремих екземплярів (по фізичним БД) за допомогою знімків і відстрочених транзакцій. Операції тиражування плануються в черзі завдань і виконуються у фоновому режимі. На додаток до процесів блокування ця опція вимагає наявності щонайменше одного фонового процесу оновлення знімка (SNP – snapshot) для виконання робіт, поставлених у чергу. Ця опція вимагає, щоб фоновий процес відновлення RECO завершував розподілені транзакції, які закінчилися аварійно із-за відмов мережі або примірника. Конфігурація ParallelQuery використовується в тому випадку, якщо комп'ютер, на якому встановлений екземпляр Oracle, має в наявності кілька процесорів. В цьому випадку додатково запускаються процеси Pnnn – процеси паралельних запитів. Процеси Pnnn використовуються для реалізації паралельного виконання окремих частин запиту і приймають участь у формуванні індексів і таблиць.