З усіх параметрів для нас є найважливішими ...

З усіх параметрів для нас є найважливішими ...

Параметрів функціонування СУБД, що вказуються в INIT-файлі, як відомо, в Oracle предостатньо. Їх кількість змінюється від версії до версії. На версії 8.1.5 для NT, наприклад, їх 195:

SQL> select count (*) from v $ parameter;
COUNT (*)
---------
195
Це ті, які (не завжди, на жаль, ясно) документовані. Плюс до них можна додати ще 248 недокументірованих:

SQL> select count (*) from x $ ksppi where substr (ksppinm, 1,1) = '_';
COUNT (*)
---------
248
На непідготовленого така велика кількість регулювань роботи системи може подіяти гнітюче, але ж треба додати, що не всі ці параметри незалежні, і що багато хто діє суперечливо один відносно одного.

На щастя, знання всіх 195 параметрів (про недокументованих - особлива розмова), хоча і робить честь адміністратору (якщо тільки такий знайдеться), але зовсім не обов'язково для типових використань системи. Більшість параметрів стають корисними лише в спеціальних, не так вже й часто виникають випадки, що вимагають знання дійсно тонкощів роботи Oracle.

В "звичайної" ж "життя", крім того, не всі параметри рівнозначні. Якісь ви можете правити, і навіть не помічати віддачі, а довгий процес осягнення правил виставлення інших може привести до виграшу в продуктивності, скажімо, всього на 1%.

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

Нижче наводяться деякі INIT-параметри, у складі які впливають на настройку структур в оперативній пам'яті примірника Oracle, на які слід звернути увагу в першу чергу, так як ефект від їх адекватного для ваших умов виставлення здатний привести до зростання продуктивності, істотно перевищує згадуваний 1%.

Ось ці параметри:

Задає максимальне число блоків з даними в SGA. Якщо з диска потрібно прочитати більше буферів, ніж задано в DB_BLOCK_BUFFERS, блоки з SGA скидаються в табличні простору за принципом "перший прийшов - перший пішов" (LRU). Такий порядок, однак, можна індивідуально скасувати для невеликих таблиць (здатних цілком розміститися в SGA самим, і залишити місце іншим).

Розмір змінної частини загальної області (shared pool) даних в байтах. Сприймається Oracle'ом як рекомендація, і практично завжди коригується, виходячи з власних обмежень (це можна перевірити, перевстановити SHARED_POOL_SIZE, і подивившись результат). Змінна частина shared pool використовується як простір для задоволення динамічно що виникають у системи потреб в пам'яті ОЗУ. Якщо розмір shared pool більше необхідного, то через зростання списків вільної пам'яті і при великій динаміці виникають накладні витрати на управління можуть привести до зниження продуктивності системи. Плюс до цього, надто великий розмір SGA може викликати процес сторінкового обміну пам'яті ОЗУ з диском, що гальмує загальну роботу.

Область в shared pool, зарезервована для динамічно виникають запитів великих безперервних ділянок пам'яті в SGA при обробці SQL. За замовчуванням виставляється в 5% від SHARED_POOL_SIZE (вказується в байтах), але в залежності від умов експлуатації це місце може або пропадати, або опинитися в дефіциті. "Рухаючи" параметр SHARED_POOL_RESERVED_SIZE в меншу або більшу сторону (більше 50% Oracle виставити не дозволить), ви не зміните загального розміру shared pool, але можете поліпшити, або погіршити ефективність використання цієї області.

Якщо ви працюєте в NT і не використовуєте сервер "загального користування" (shared), паралельний сервер або роботу з монітором транзакцій, цей параметр за замовчуванням буде виставлений в 0.

Визначає розмір пам'яті, що виділяється кожному призначеному для користувача процесу на сортування (UGA, може бути в розташована в SGA або PGA; використовується, наприклад, при обробці DISTINCT або ORDER BY). Якщо пам'яті не вистачає, буде використовуватися дисковий простір - хороший спосіб «підсадити» роботу системи. Збільшення параметра скоротить число "дискових" угруповань; в той же час об'ємних угруповань диска все одно не уникнути. По закінченню сортування пам'ять повністю повертається в "купу" UGA, тобто неприємними з точки зору витрачання пам'яті є тільки одночасно виконуються декількома процесами сортування.

Задає максимальний розмір пам'яті, динамічно запитуваної у UGA на завершальну фазу процедури сортування, що виконується із залученням дискової пам'яті. По завершенню процедури сортування ця пам'ять повертається, проте в завершальній стадії сортування вона може витрачатися протягом деякого часу процесом на додаток до "основної" пам'яті, регульованою параметром SORT_AREA_SIZE. (В цей час загальна оперативна пам'ять, що витрачається процесом на сортування, може досягти SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)

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

Метою виставлення цього параметра є заклад ще одного спеціального подбуфера, знову-таки порушує стандартний порядок заміщення блоків, але вже протилежним чином. Якщо є великий нечасто використовуваний об'єкт (дуже велика таблиця), можна приписати її до подбуферу RECYCLE, і тоді Oracle "відпустить" його блоки відразу ж після використання (що може дати виграш продуктивності, так як таке звернення до блоку відбудеться нескоро).

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

Володимир Пржиялковского, викладач УКЦ Interface Ltd.

Схожі статті