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

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

Сервер Oracle використовує відкладену багатоблокову

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

частоти звертання до дискової пам’яті на продуктивність системи.

Термін “відкладена” означає, що відновлення даних, виконане

СУБД, не фіксується негайно в дисковій пам’яті. СУБД чекає, поки

не відбудеться одна з таких подій:

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

числі блоків даних;

– буде потрібно звільнити місце в кеш-буфері для завантаження

нових блоків даних;

– виявлена контрольна точка;

– минув час, заданий процесом DBWR.

У кожному з цих випадків група модифікованих блоків даних

переноситься з кеш-буфера в файли.

Розмір кеш-буфера визначається такими двома параметрами

файлу init.ora: DB_BLOCK_SIZE і DB_BLOCK_BUFFERS. Параметр

DB_BLOCK_SIZE використовується при створенні БД для визначення

розміру блоку Oracle. У свою чергу, параметр DB_BLOCK_BUFFERS

визначає кількість блоків, виділених для кеш-буфера даних.

Загальний обсяг кеш-буфера даних (у байтах) є добутком значень

цих двох параметрів: DB_BLOCK_SIZE * DB_BLOCK_BUFFERS і

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

кеш-буфера. Для кеш-буфера даних немає необхідності виділяти

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

таке раціональне значення обсягу кеш-буфера, при якому пам’ять

використовується найбільше ефективно. Знайти таке значення

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

буфера і фіксуючи, наскільки задане збільшення позначається на

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

можна помітити, що на початку цього процесу збільшення розміру

кеш-буфера досить значно підвищує продуктивність системи, але

потім його вплив поступовий знижується. Тут потрібно мати

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

ресурсу пам’яті для інших керуючих структур СУБД.

Буфер журналу транзакцій. Усі дані про здійснені транзакції

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

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

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

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

заповнення буфера його вміст переноситься у файл журналу

транзакцій.

Розмір буфера журналу транзакцій задається параметром

LOG_BUFFER у файлі init.ora, де вказується розмір буфера в байтах.

Якщо це значення невелике, то процес LGWR дуже часто буде

переписувати інформацію з буфера у файл і тим самим

сповільнювати роботу системи. Однак це буде помітно тільки у

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

Для того щоб гарантувати послідовний характер запису в буфер

журналу, сервер Oracle керує доступом до нього за допомогою

засувів (latch). Засув являє собою блокування процесом Oracle

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

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

виділеної для буфера журналу транзакцій. Таким чином, якщо один

процес “наклав” засув на буфер, інші не можуть звернутися до

нього доти, поки засув не буде знятий.

Кількість транзакцій, дані про які заносяться в журнал

одночасно, сервер Oracle обмежує параметром TRANSACTIONS.

Значення, прийняте системою за замовчуванням, може

змінюватися в залежності від типу операційної системи і апаратних

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

простору, більшого, ніж задано параметром TRANSACTIONS. При

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

використовувати засуви копій журналу транзакцій (redo copy latch).

Параметр _LOG_SIMULTANEOUS_COPIES задає кількість таких

засувів. За замовчуванням значення _LOG_SIMULTANEOUS_COPIES

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

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

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

4.2.2 Фонові процеси Oracle

Для того, щоб СУБД Oracle могла працювати одночасно із

сотнею запитів від користувачів, переглядати тисячі (чи навіть

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

високою продуктивністю і надійністю, уся ця робота

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

одна від іншої. Ці програми називаються фоновими процесами,

вони такі:

 PMON і SMON - керування процесами і відновлення бази при її

відкритті;

 DBWR - запис у файли даних змінених блоків;

 LGWR - запис у файли оперативного журналу інформації з

буфера журналу транзакцій;

 ARCH - архівування оперативного журналу транзакцій;

 СКРТ - обробка контрольних точок;

 RECO - для розподілених БД, відновлює незавершені транзакції;

 SPNn - відновлення знімків;

 Pnnn - обслуговування процесів паралельних запитів;

 LCKn - керування паралельними підключеннями до екземпляра.

Крім того, існують процеси User і Server, які виконують

обробку транзакцій кінцевого користувача до БД, і процеси Parallel

Query, відповідальні за обробку паралельних запитів. Ці процеси

не кваліфікуються як фонові, але вони відіграють значну роль у

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

Процеси SMON і PMON. Якщо користувач виключає свій

комп’ютер, не повідомивши про це Oracle, або, наприклад,

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

стосуються безпосередньо бази даних, але можуть спричинити

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

Oracle повинен відповідним чином відреагувати на подібну

ситуацію.

Саме автоматичним вирішенням подібних проблем зайняті

процеси SMON і PMON. PMON – Process Monitor (моніторинг

процесів) виконує автоматичне “прибирання” після раптово

припинених чи аварійно завершених процесів. Воно включає в себе

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

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

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

процесу. Процес PMON також стежить за процесами сервера і

диспетчера та автоматично перезапускає їх у випадку зупинки.

Досить важливу роль відіграє й процес SMON. Після запуску

БД процес SMON (System Monitor – моніторинг системи) виконує

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

вимиканні БД щось недозавершилося, SMON автоматично

запускає незавершені операції. Крім того, SMON стежить за

сегментами БД, фіксує звільнення простору в тимчасових

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

файлах даних. Необхідно відмітити, що, якщо для табличного

простору параметр PCTINCREASE дорівнює 0, то з’єднання

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

значення PCTINCREASE хоча б рівним 1.

Фонові процеси SMON і PMON обов’язкові для

функціонування БД; якщо вони не запущені, то система працювати

не буде.

Процес DBWR. Процес DBWR – Database Writer (запис у базу

даних) відповідає за перенесення змінених блоків, занесених у

dirty-список, з кеш-буфера у файли даних. Замість того, щоб

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

процес DBWR чекає, поки не буде забезпечена хоча б одна з таких

умов:

– виявлена контрольна точка;

– кількість елементів у dirty-списку досягло заданого значення;

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

параметром _DB_LARGE_DIRTY_QUEUE з файлу init.ora;

– минув заданий для процесу DBWR інтервал часу (3 сек).

Далі процес DBWR переглядає dirty-список і всі відзначені в

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

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

швидкісних характеристик дискової пам’яті на продуктивність

системи.

Настроювання фонового процесу DBWR відбувається так же,

як і настроювання всіх процесів – у ході роботи із системою. В БД

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

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

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

процесів DBWR. Для цього у файлі init.ora потрібно установити

відповідне значення параметра _DBWR_TRACING, яке за

замовчуванням дорівнює 1. У більшості випадків необхідність у

додаткових процесах DBWR може виникнути, якщо сервер Oracle

працює в операційній системі, яка не підтримує асинхронний ввід-

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

скільки фізичних дисків використовується для збереження файлів

даних або скільки файлів даних має БД. Слід наголосити, що

модифікувати параметри із символом підкреслення ( _ ) перед

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

наслідки. Перш, ніж змінювати їхні значення, рекомендується

зняти з БД резервну копію.

Для керування доступом до блоків пам’яті в кеш-буфері даних

також використовується механізм засувів. Засув списку LRU керує

обміном буферів у кеші. В дуже активних серверах з безліччю

процесорів між засувами можуть виникнути “гонки”. Якщо

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

_DB_BLOCK_LRU_LATCHES, рівне кількості засувів. Ця кількість не

повинна перевищувати більш, ніж удвічі, кількість процесорів. За

замовчуванням кількість засувів установлюється рівною кількості

процесорів у системі.

Ще одним параметром, який впливає на режим роботи процесу

DBWR є DB_BLOCK_CHECKSUM. Це логічний параметр, установка

якого спричиняє обчислення контрольної суми при кожному

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

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

раніше обчисленою. Розбіжність контрольних сум (підрахованої

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

збій. Така процедура читання-запису даних допомагає відшукати

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

обчислення контрольних сум постійно включеним, оскільки це

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

Процес LGWR (Log Writer – дописувач журналу) відповідає за

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

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

журналу. Цей запис виконується при таких умовах:

– транзакція приймається;

– минає час чекання, заданий для процесу LGWR;

– буфер журналу транзакцій заповнюється на третину;

– процес DBWR завершує перезапис даних з кеш-буфера після

виявлення контрольної точки.

Необхідно відзначити, що Oracle не вважає транзакцію

виконаною доти, поки процес LGWR не перезапише дані про неї з

буфера журналу транзакцій у файл. Повідомлення про виконання

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

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

У роботі процесу LGWR рідко відбуваються якісь збої, тому

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

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

розподіл пам’яті буфера. Але якщо запущений процес СКРТ, і

процес LGWR здійснює обробку контрольних точок, то процеси

LGWR і DBWR змушені витрачати час на перезапис. З іншого

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

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

обробки кожної окремої контрольної точки.

Існує декілька параметрів настроювання інтервалу

проходження контрольних точок і, задаючи їхнє значення,

необхідно враховувати зазначені вище фактори.

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

точок можуть два параметри: LOG_CHECKPOINT_INTERVAL і

LOG_CHECKPOINT_TIMEOUT. При зміні значення параметра

LOG_CHECKPOINT_INTERVAL контрольна точка генерується за

умови, що зазначена кількість блоків операційної системи (ОС)

записується в журнал транзакцій. З іншого боку, при зміні

значення LOG_CHECKPOINT_TIMEOUT контрольна точка генерується

за умови, що минув зазначений (у секундах) інтервал часу.

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

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

параметр LOG_CHECKPOINT_INTERVAL, то зазначена кількість блоків

ОС повинна співпадати з розміром групи журналу транзакцій.

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

Наприклад, якщо значення параметра LOG_CHECKPOINT_INTERVAL

дорівнює 2,5 Мбайт, а розмір групи журналу дорівнює 3 Мбайт,

контрольна точка згенерується в таких випадках: коли в журнал

записані 2,5 Мбайт даних і коли заповнена група журналу (після

наступних 0,5 Мбайт. Отже, друга точка буде згенерована

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

Частоту генерації контрольних точок можна також регулювати

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

такий розмір групи, що заповнюється протягом години, то й умова

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

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

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

почнуть генеруватися дуже часто, і на їхню обробку буде

витрачено порівняно багато часу.

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

LOG_CHECKPOINTS_TO_ALERT. Якщо він установлений, то з

кожною появою контрольної точки буде проставлятися відповідна

оцінка у файлі реєстрації alert.log, який можна буде використати під

час аналізу динаміки генерації контрольних точок.

Процес СКРТ. Як уже було сказано в описі процесу LGWR,

процес СКРТ є додатковим фоновим процесом, який відповідає за

обробку контрольних точок. Якщо його немає, то відновлення

файлів даних і заголовків контрольних файлів виконується

процесом LGWR. Таким чином, СКРТ знижує навантаження на

процес LGWR.

Процес ARCH. Процес ARCH (Archiver - архіватор) відповідає

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

транзакцій в архівні файли журналів транзакцій. Для запуску

процесу ARCH необхідно, щоб база даних працювала в режимі

архівування журналів транзакцій.

Для того щоб процес ARCH запускався автоматично після

відкриття БД, необхідно параметру LOG_ARCHIVE_START у файлі

init.ora привласнити значення TRUE. Сама по собі установка режиму

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

процес ARCH. Тому, якщо немає відповідної установки параметра

LOG_ARCHIVE_START, система “зависне” після заповнення

оперативних файлів журналів і буде чекати, поки процес ARCH не

буде запущений вручну.

Під час перезапису в архів ніякий інший процес не може

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

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

небудь причини процес ARCH не може завершити запис, він буде

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

Процес RECO. Процес RECO відповідає за відновлення

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

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

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

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

адміністратора БД. Процес намагається встановити зв’язок з

віддаленою БД і після встановлення зв’язку вирішити виниклу

проблему.

Процес SNPn. Цей процес займається автоматичним

відновленням знімків (snapshot) БД і запускає процедури відповідно

до розкладу, зафіксованого в пакеті DBMS_JOB. Параметр

_JOB_QUEUE_PROCESSES у файлі init.ora задає кількість запущених

процесів SNPn, а параметр _JOB_QUEUE_INTERVAL визначає

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

перш, ніж виконати завдання.

Процес LCKn. У середовищі з паралельним обслуговуванням

до однієї БД може звертатися безліч екземплярів Oracle. Саме

процес LCKn (Locks - блокування) відповідає за координацію

блокувань, установлених різними екземплярами. Якщо режим

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

необхідність у процесі LCKn відпадає.

Процес Pnnn. Процеси паралельних запитів одержали в системі

найменування Pnnn. Сервер Oracle запускає і зупиняє процеси Pnnn

у залежності від активності роботи з БД і настроювання параметрів

паралельних запитів. Ці процеси беруть участь у формуванні

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

визначається двома параметрами: PARALLEL_MIN_SERVERS і

PARALLEL_MAX_SERVERS, що означає відповідно мінімальну і

максимальну кількість процесів.

Процеси користувача і сервера. Процес сервера аналізує і

виконує передані йому оператори SQL і повертає результат

процесу користувача. Крім того, процес сервера зчитує блоки з

файлів даних і розміщує їх у кеш-буфері даних.

Додатки й утиліти зв’язуються із СУБД за допомогою процесів

користувача. Кожен процес користувача, у свою чергу,

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

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

багатьма.

Кожному процесу користувача виділяється область пам’яті, що

називається глобальною областю процесу – ГОП (Process Global

Area, PGA). Уміст ГОП залежить від режиму підключення процесу

користувача до процесу сервера. У випадку виділеного процесу

сервера в ГОП розміщується інформація про поточний сеанс

роботи користувача, стек і інформація про стан курсора.

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

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

Стек містить локальні змінні. Область стану курсора містить у собі

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

повертає.

Якщо ж процес користувача зв’язаний з розподілюваним

процесом сервера, то інформація про поточний сеанс і поточний

стан курсора зберігається в глобальній системній області (ГСО).

Процеси-диспетчери. Для того, щоб забезпечити використання

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

багатопоточний сервер Multi-Threaded Server – MTS. При

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

як мінімум, один процес-диспетчер. Кількість процесів-диспетчерів

залежить від потреб операційного середовища і задається поряд з

параметрами файлу ініціалізації.

Диспетчер передає запити користувачів у чергу ГСО і повертає

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

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

1. Що таке глобальна системна область?

2. Що таке кеш-буфер пам’яті?

3. Що таке буфер журналу транзакцій?

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

5. Що таке відкладена багатоблокова процедура запису на диск?

6. Для чого використовуються засуви буфера журналу

транзакцій?

7. Перелічіть фонові процеси Oracle

8. Чим відрізняється фоновий процес від процесу користувача?

9. Для чого служать процеси-диспетчери?

10. Опишіть послідовність перенесення даних з кеш-буфера на

диск.

4.3 Транзакції

4.3.1 Анатомія транзакції

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

одиницею роботи СУБД. Розглянемо що відбувається при її

виконанні.

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

підключається до сервера через драйвер SQL*Net. З’єднання до

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

виділений процес, якщо – до поділюваного, то через процес-

диспетчер.

Сервер кешує вираз SQL, який надійшов від користувача, і

порівнює сформований кеш-код з кеш-кодами, раніше

збереженими в розподілюваній області SQL. Якщо в

розподілюваному пулі знайдено точний збіг виразів SQL, то

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

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

виконує аналіз виразу.

Далі сервер перевіряє чи не знаходяться блоки даних, необхідні

для виконання транзакції, у кеш-буфері даних. Якщо блоки не

виявлені в буфері, сервер зчитує їх з файлів і копіює в кеш. Якщо

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

користувачеві.

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

модифікацію даних. Після того, як викликані блоки даних будуть

зчитані в кеш-буфер даних, уже там, у пам’яті, вони

модифікуються, позначаються як “брудні” (dirty) і поміщаються в

dirty-список. Одночасно формується інформація про виконану

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

журнал.

Якщо транзакція відносно коротка (наприклад, відновлення

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

користувачу. Одночасно вона сигналізує процесу LGWR про

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

оперативний файл журналу.

Якщо ж транзакція досить тривала, то відбувається одна з таких

подій:

– інформація про транзакції, що записується в кеш журналу,

заповнила буфер на одну третину. Це змушує процес LGWR

переписати вміст буфера у файл;

– кількість блоків, відзначених у dirty-списку, досягло заданого

значення. Тоді процес DBWR виконує перезапис

модифікованих блоків з кеш-буфера даних у файли даних, що

у свою чергу змушує процес LGWR переписати вміст буфера

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

– виконується контрольна точка БД. При цьому виконуються

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

перезаписи буфера журналу транзакцій у відповідний файл;

– кількість вільних блоків у кеш-буфері зменшилася і досягла

критичної величини. Це також спричиняє перезапис даних з

кеш-буфера у файли;

– виникла невідновна помилка БД. Це змушує припинити

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

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

помилку.

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

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

буфера журналу в оперативні файли журналу. В результаті ці

файли заповнюються. Коли поточний файл заповниться, процес

LGWR почне перезаписувати дані з буфера в інший файл, у той час

як процес ARCH копіює заповнений файл в архів на диску.

Оскільки транзакція вважається завершеною тільки після того, як

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