Використання засобів автоматичної настройки баз даних Oracle9i, Oracle, Бази даних, статті

Засоби динамічного розподілу пам’яті СУБД Oracle 9i дозволяють створювати самоналагоджувальні бази даних. У даній статті розглядається використання пакету STATSPACK для моніторингу та налаштування (В залежності від потреб обробки в сервері і базі даних) зон пам’яті, розміри яких задаються наступними параметрами: sort_area_size (розмір області сортування), large_pool_size (розмір великого пулу), pga_aggregate_target (максимальна сумарна пам’ять PGA), sga_max_size (максимальний розмір SGA) і db_cache_size (розмір пулу буферів). Ми також розглянемо моніторинг за допомогою пакета STATSPACK використання зон пам’яті та створення інтелектуального механізму для автоматичного реконфигурирования Oracle 9i в залежності від поточних потреб обробки.

Серйозною проблемою в Oracle8i була вимога: всі виділені з’єднання повинні використовувати області сортування однакового розміру, що задається параметром sort_area_size. В Oracle 9i є можливість автоматичного управління розподілом пам’яті PGA. В Oracle введений новий параметр файлу init.ora – pga_aggregate_target. Якщо він встановлений і використовуються виділені (dedicated) з’єднання з Oracle, Oracle 9i буде ігнорувати всі параметри PGA, що задаються у файлі init.ora, включаючи sort_area_size і sort_area_retained_size (розмір пам’яті, що утримується після завершення сортування). Корпорація Oracle рекомендує встановлювати значення параметра pga_aggregate_target, рівне обсягом пам’яті, що залишилася вільною у сервері UNIX після запуску екземпляра (мінус 20% на інші завдання ОС UNIX). Див. рис. 1.

Рис 1. Визначення значення параметра pga_aggregate_target в сервері UNIX.

Після установки параметра pga_aggregate_target Oracle буде автоматично керувати розподілом пам’яті PGA, грунтуючись на конкретних потребах кожного з’єднання з Oracle. В Oracle 9i також можна динамічно модифікувати параметр pga_aggregate_target на рівні примірника за допомогою оператора alter system, тому АБД може динамічно управляти розподілом пам’яті, доступної Oracle 9i.

В Oracle 9i з’явився також ще один новий параметр – workarea_size_policy (політика установки розмірів робочих областей). Якщо в цьому параметрі встановлено AUTO (автоматичний режим), Oracle буде намагатися максимізувати кількість робочих областей, використовуваних для оптимального (optimal) режиму їх обробки, а розмір інших робочих областей буде намагатися задавати достатнім для однопрохідного (one-pass) режиму обробки. Якщо в параметрі workarea_size_policy встановлено MANUAL (ручний режим), з’єднанням буде виділятися пам’ять відповідно до встановленого значенням параметра sort_area_size.

Нові уявлення Oracle 9i для автоматичного керування пам’яттю PGA

В Oracle 9i з’явилося кілька нових уявлень і нових стовпців в існуючих уявленнях, які показують внутрішній розподіл пам’яті в Oracle 9i. Для моніторингу використання пам’яті виділеними сполуками Oracle 9i можна використовувати наступні v $-вистави:


Розглянемо більш докладно нові засоби Oracle 9i і скрипти, які дозволяють розібратися в деталях використання пам’яті PGA.

Використання подання v $ sysstat в Oracle 9i

Наступний запит видає загальна кількість і відсотки кількості виконань в трьох режимах (оптимальному, однопрохідному і багатопрохідному) починаючи із запуску екземпляра.


Work_area.sql

select
name profile,
cnt,
decode(total, 0, 0, round(cnt*100/total)) percentage
from
(
select
name,
value cnt,
(sum(value) over ()) total
from
v$sysstat
where
name like ‘workarea exec%’
);

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

PROFILE                             CNT        PERCENTAGE
———————————– ———- ———-
workarea executions – optimal 5395 95
workarea executions – onepass 284 5
workarea executions – multipass 0 0

АБД може використовувати цей запит для визначення, коли потрібно динамічно змінити значення параметра pga_aggregate_target. Загалом, значення pga_aggregate_target потрібно збільшувати, якщо відсоток кількості виконань в багатопрохідному режимі (workarea executions – multipass) більше 0, і зменшувати, якщо відсоток кількості виконань в оптимальному режимі (workarea executions – optimal) дорівнює 100%.

Використання подання v $ pgastat в Oracle 9i

Подання v $ pgastat містить сумарні статистики (на рівні примірники) використання PGA і роботи автоматичного диспетчера пам’яті (automatic memory manager). Для видачі сумарних статистик для всіх сполук з Oracle 9i можна використовувати наступний скрипт:

check_pga.sql
column name format a30
column value format 999,999,999
select
name,
value
from
v$pgastat
;

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

NAME                                                   VALUE
—————————————————— ———-
aggregate PGA auto target 736,052,224
global memory bound 21,200
total expected memory 141,144
total PGA inuse 22,234,736
total PGA allocated 55,327,872
maximum PGA allocated 23,970,624
total PGA used for auto workareas 262,144
maximum PGA used for auto workareas 7,333,032
total PGA used for manual workareas 0
maximum PGA used for manual workareas 0
estimated PGA memory for optimal 141,395
maximum PGA memory for optimal 500,123,520
estimated PGA memory for one-pass 534,144
maximum PGA memory for one-pass 52,123,520

У цьому висновку з v $ pgastat ми бачимо наступні статистики:

Розширення уявлення v $ process в Oracle 9i

У уявлення v $ process додано декілька нових стовпців, що показують автоматичне виділення процесам пам’яті PGA, включаючи стовпці pga_used_mem, pga_alloc_mem і pga_max_mem. Запит, що видає значення цих стовпців:

select
program,
pga_used_mem,
pga_alloc_mem,
pga_max_mem
from
v$process;

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

PROGRAM                        PGA_USED_MEM PGA_ALLOC_MEM PGA_MAX_MEM
—————————— ———— ————- ———–
PSEUDO 0 0 0
oracle@janet (PMON) 120463 234291 234291
oracle@janet (DBW0) 1307179 1817295 1817295
oracle@janet (LGWR) 4343655 4849203 4849203
oracle@janet (CKPT) 194999 332583 332583
oracle@janet (SMON) 179923 775311 775323
oracle@janet (RECO) 129719 242803 242803
oracle@janet (TNS V1-V3) 1400543 1540627 1540915
oracle@janet (P000) 299599 373791 635959
oracle@janet (P001) 299599 373791 636007
oracle@janet (TNS V1-V3) 1400543 1540627 1540915
oracle@janet (TNS V1-V3) 22341 1716253 3625241

Тут ми бачимо виділену (pga_alloc_mem), використовувану (pga_used_mem) і максимальну (pga_max_mem) пам’ять для всіх з’єднань з Oracle. Ми бачимо запити пам’яті для всіх фонових процесів, а також для індивідуальних сполук.

Зауважимо, запити пам’яті конкретними сполуками можна аналізувати більш детально, поєднуючи уявлення v $ process з таблицею v $ sql_plan.

Використання подання v $ sql_workarea_active в Oracle 9i

Два нових подання показують активну простір робочих областей: v $ sql_workarea і v $ sql_workarea_active. Подання v $ sql_workarea_active містить інформацію про всіх робочих областях, активних в екземплярі в даний момент. Зауважимо, невеликі сортування (менше 65 535 байтів) з уявлення виключені.

select
to_number(decode(SID, 65535, NULL, SID)) sid,
operation_type OPERATION,
trunc(WORK_AREA_SIZE/1024) WSIZE,
trunc(EXPECTED_SIZE/1024) ESIZE,
trunc(ACTUAL_MEM_USED/1024) MEM,
trunc(MAX_MEM_USED/1024) “MAX MEM”,
number_passes PASS
from
v$sql_workarea_active
order by
1,2;

Приклад виведення цього запиту:

SID OPERATION             WSIZE     ESIZE       MEM   MAX MEM PASS
— ——————— —– ——— ——— ——— —-
27 GROUP BY (SORT) 73 73 64 64 0
44 HASH-JOIN 3148 3147 2437 6342 1
71 HASH-JOIN 13241 19200 12884 34684 1

Тут видно, що в сеансі 44 (див. стовпець SID) виконується хеш-з’єднання (hash-join) і його робоча область обробляється в однопрохідному режимі (стовпець PASS). У цій робочій області в даний час використовується 2 мегабайта пам’яті PGA (стовпець MEM), а до цього було використано до 6.5 мегабайтів пам’яті PGA (стовпець MAX MEM).

Це подання дуже корисно для аналізу поточних операцій з робочими областями, для отримання більш докладної інформації про сеанси це подання можна з’єднувати з уявленнями v $ process і v $ session , Використовуючи для цього стовпець SID.

Аналіз використання пам’яті для конкретних операторів SQL

В Oracle 9i можна отримувати інформацію про використання пам’яті разом з інформацією про плани виконання. Для цього за поданням v $ sql потрібно спочатку визначити адресу потрібного оператора. Наприклад, якщо запит працює з таблицею NEW_CUSTOMER, для визначення адреси можна виконати наступний запит:

select
address
from
v$sql
where
sql_text like ‘%NEW_CUSTOMER’;
88BB460C
1 row selected.

Тепер у нас є адреса і ми можемо вставити його в наступний скрипт для добування інформації про план виконання і використання пам’яті PGA для даного оператора SQL.

plan_mem.sql
select
operation,
options,
object_name name,
trunc(bytes/1024/1024) “input(MB)”,
trunc(last_memory_used/1024) last_mem,
trunc(estimated_optimal_size/1024) opt_mem,
trunc(estimated_onepass_size/1024) onepass_mem,
decode(optimal_executions, null, null,
optimal_executions//”/”//onepass_executions//”/”//
multipasses_exections) “O/1/M”
from
v$sql_plan p,
v$sql_workarea w
where
p.address=w.address(+)
and
p.hash_value=w.hash_value(+)
and
p.id=w.operation_id(+)
and
p.address=”88BB460C”;

Висновок цього скрипта:

OPERATION    OPTIONS  NAME input(MB) LAST_MEM OPT_MEM ONEPASS_MEM O/1/M
———— ——– —- ——— ——– ———- ———- —-
SELECT STATE
SORT GROUP BY 4582 8 16 16 26/0/0
HASH JOIN SEMI 4582 5976 5194 2187 16/0/0
TABLE ACCESS FULL ORDERS 51
TABLE ACCESS FUL LINEITEM 1000

Ця інформація про план виконання і використання пам’яті PGA – нове досягнення в Oracle 9i, яке дозволяє АБД отримувати докладну інформацію про внутрішнє виконанні операторів SQL.

Перехід до самонастраивающейся базі даних Oracle 9i

Нові можливості динамічного управління SGA в Oracle 9i дозволяють використовувати архітектуру, при якій АБД Oracle може виконувати моніторинг використання пам’яті в ОС UNIX та реконфигурировать SGA і зони пам’яті PGA в залежності від поточних профілів використання.

Рівень автоматичної настройки задається новим параметром pga_aggregate_target. В Oracle 9i для управління пам’яттю використовується складний алгоритм, який підвищує швидкість виконання операцій, інтенсивно використовують пам’ять, таких, як хеш-з’єднання і великі сортування.

Зараз АБД Oracle може динамічно перерозподіляти пам’ять.

Зміна конфігурації пам’яті скриптами ОС UNIX

У середовищі UNIX дуже легко планувати запуск завдань, що змінюють конфігурацію пам’яті при зміні характеру обробки. Наприклад, багато баз даних Oracle працюють в денний час в режимі OLTP, а вночі запускаються пакетні завдання для підготовки звітів, інтенсивно використовують пам’ять.

Як вже було зазначено, бази даних в режимі OLTP повинні мати високе значення параметра db_cache_size, а завдання, інтенсивно використовують пам’ять, повинні мати високе значення параметра pga_aggregate_target.

Наведені нижче скрипти UNIX можуть бути використані для реконфигурирования SGA без зупинки екземпляра. У цьому прикладі ми припускаємо, що у нас окремий сервер Oracle з 8 гігабайтами пам’яті, 20% якої ми резервуємо для UNIX, залишаючи 6 гігабайтів для СУБД Oracle і з’єднань з Oracle. Ці скрипти призначені для роботи в ОС HP / UX або Solaris, як аргумент в них задається $ ORACLE_SID.

Скрипт dss_config.ksh буде запускатися кожен вечір в 6:00 для реконфигурирования Oracle для роботи в режимі DSS (запуск завдань, інтенсивно використовують пам’ять).

dss_config.ksh
#!/bin/ksh
# First, we must set the environmnt …
ORACLE_SID=$1
export ORACLE_SID
ORACLE_HOME=`cat /etc/oratab/grep ^$ORACLE_SID:/cut -f2 -d”:”`
#ORACLE_HOME=`cat /var/opt/oracle/oratab/grep ^$ORACLE_SID:/cut -f2 -d”:”`
export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$PATH
export PATH
$ORACLE_HOME/bin/sqlplus -s /nologin<<!
connect system/manager as sysdba;
alter system set db_cache_size=1500m;
alter system set shared_pool_size=500m;
alter system set pga_aggregate_target=4000m;
exit
!

Скрипт oltp_config.ksh буде запускатися щоранку в 6:00 для реконфигурирования Oracle для роботи в режимі OLTP.

oltp_config.ksh
#!/bin/ksh
# First, we must set the environmnt …
ORACLE_SID=$1
export ORACLE_SID
ORACLE_HOME=`cat /etc/oratab/grep ^$ORACLE_SID:/cut -f2 -d”:”`
#ORACLE_HOME=`cat /var/opt/oracle/oratab/grep ^$ORACLE_SID:/cut -f2 -d”:”`
export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$PATH
export PATH
$ORACLE_HOME/bin/sqlplus -s /nologin<<!
connect system/manager as sysdba;
alter system set db_cache_size=4000m;
alter system set shared_pool_size=500m;
alter system set pga_aggregate_target=1500m;
exit
!

Зауваження: для планування цих подій реконфигурирования можна використовувати пакет dbms_job.

Зараз, коли ми бачимо загальний підхід до зміни конфігурації Oracle, стає зрозуміло, що ми можемо розробити механізм постійного моніторингу запитів процесів Oracle, на підставі якого можна виконувати оператори alter system для реконфигурирования пам’яті залежно від поточних запитів процесів.

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

Oracle 9i розвивається в напрямку створення повністю самонастраивающейся архітектури, але АБД Oracle несуть відповідальність за настройку конфігурації пам’яті відповідно до характеру її використання. Загалом, для визначення часу зміни характеристик роботи можна використовувати запити v $-уявлень і пакет STATSPACK. Ми бачимо три підходи до автоматизації налаштування:

Правила зміни розмірів пам’яті

Існує три умови, що впливають на прийняття рішення про зміну розмірів зон пам’яті Oracle: одне – для кеша буферів, інше – для розділяється пулу, третє – для пам’яті PGA:

Розглянемо кожне умова більш докладно.

Ми можемо захотіти динамічно змінити значення параметра pga_aggregate_target, якщо виконується одна з таких умов:

Зміна значення параметра shared_pool_size

З досвіду роботи з Oracle8 ми знаємо, що для визначення правильності встановлення розміру розділяється пулу можна використовувати кілька запитів. Коефіцієнт непопадання в бібліотечний кеш (library cache miss ratio), що представляє собою відношення кількості перезавантажень бібліотечного кеша (library cache reloads) до кількості влучень (pins), дозволяє визначити необхідність зміни розмірів поділюваного пулу.

Загалом, якщо значення коефіцієнта непопадання в бібліотечний кеш перевищує 1%, потрібно розглянути питання про збільшення значення параметра shared_pool_size. Непотрапляння в бібліотечний кеш виникають під час розбору і підготовки планів виконання операторів SQL. Виконання операторів SQL складається з двох фаз: фаза розбору і фаза виконання. Під час фази розбору Oracle спочатку перевіряє, чи міститься розібране уявлення оператора в бібліотечному кеші. Якщо не міститься, Oracle виділить в бібліотечному кеші поділювану область SQL, а потім виконає розбір оператора. Під час виконання Oracle перевіряє, міститься Чи розібране уявлення оператора в бібліотечному кеші. Якщо не міститься, Oracle виконає повторний розбір оператора, а потім виконає сам оператор.

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

rpt_lib_miss.sql
set lines 80;
set pages 999;
column mydate heading “Yr. Mo Dy Hr.” format a16
column c1 heading “execs” format 9,999,999
column c2 heading “Cache Misses/While Executing” format 9,999,999
column c3 heading “Library Cache/Miss Ratio” format 999.99999
break on mydate skip 2;
select
to_char(snap_time,”yyyy-mm-dd HH24″) mydate,
sum(new.pins-old.pins) c1,
sum(new.reloads-old.reloads) c2,
sum(new.reloads-old.reloads)/
sum(new.pins-old.pins) library_cache_miss_ratio
from
stats$librarycache old,
stats$librarycache new,
stats$snapshot sn
where
new.snap_id = sn.snap_id
and
old.snap_id = new.snap_id-1
and
old.namespace = new.namespace
group by
to_char(snap_time,”yyyy-mm-dd HH24″)
;

Висновок з скрипта показаний нижче. Сам скрипт легко пристосувати для оповіщення АБД про надмірну кількість непопадання в бібліотечний кеш.

                               Cache Misses
Yr. Mo Dy Hr. execs While Executing LIBRARY_CACHE_MISS_RATIO
—————- ———- ————— ————————
2001-12-11 10 10,338 3 .00029
2001-12-12 10 182,477 134 .00073
2001-12-14 10 190,707 202 .00106
2001-12-16 10 2,803 11 .00392

Пакет STATSPACK дозволяє видавати деталізовані звіти про поведінку об’єктів бібліотечного кеша. У цьому прикладі ясно видно: брак пам’яті бібліотечного кеша спостерігається щоранку з 9:00 до 10:00. В такому випадку ми можемо на цей період часу динамічно реконфигурировать бібліотечний кеш, збільшивши його розмір (параметр shared_pool_size) за рахунок зменшення розміру кеша буферів (параметр db_cache_size ).

Зміна розміру кеша буферів

Наступний нижче звіт STATSPACK показує, коли значення коефіцієнта влучень в кеш буферів падає нижче заданого порогового значення. Це дуже корисно для визначення періодів часу, коли виконуються запити в режимі DSS, так як велика кількість повних переглядів великих таблиць призводить до зменшення коефіцієнта влучень в кеш буферів. Цей скрипт також видає звіт про всіх трьох буферах даних, включаючи пули KEEP (утримує) і RECYCLE (реціклірующій), і його можна пристосувати для підготовки звітів про окремі пулах, так як пул KEEP повинен завжди мати достатню кількість блоків даних для кешування всіх рядків таблиць, а пул RECYCLE повинен мати дуже низький коефіцієнт попадання в кеш. Якщо значення коефіцієнта попадання в кеш буферів менше 90%, можна збільшити значення параметра db_cache_size (db_block_buffers в Oracle8i і більш ранніх версіях).

*********************************************************** * Коли коефіцієнт попадання в буфер падає нижче 20%,  * Слід збільшити значення параметра db_cache_size
***********************************************************
yr. mo dy Hr. Name bhr
————- ——– —–
2001-01-27 09 DEFAULT    45
2001-01-28 09 RECYCLE    41
2001-01-29 10 DEFAULT    36
2001-01-30 09 DEFAULT    28
2001-02-02 10 DEFAULT    83
2001-02-02 09 RECYCLE    81
2001-02-03 10 DEFAULT    69
2001-02-03 09 DEFAULT    69

Тут ми бачимо періоди часу, для яких можна динамічно збільшити значення параметра db_cache_size. В даному випадку це можна робити щодня з 8:00 до 10:00 (за рахунок зменшення значення параметра pga_aggregate_target ).

Використання подання Oracle 9i v $ db_cache_advice

В Oracle 9i з’явилося нове уявлення v $ db_cache_advice, яке дозволяє прогнозувати ефект від збільшення розміру кеша буферів. Це подання показує передбачувані непотрапляння в кеш буферів для дванадцяти потенційних розмірів кеша буферів в діапазоні від 10% поточного розміру до 200% поточного розміру.

Ця нова можливість дуже схожа на кошти Oracle7, використовувані для прогнозування ефекту від збільшення розміру кеша буферів. Для цього в Oracle7 використовувалися уявлення x $ kcbrbh (оцінка влучень в кеш) і x $ kcbcbh (оцінка непопадання в кеш).

Так само, як і в Oracle7, для збору статистик в поданні v $ db_cache_advice потрібна додаткова пам’ять. Для включення збору статистик потрібно встановити в параметрі db_cache_advice файлу init.ora значення “on” чи “ready”. Їх можна встановлювати динамічно (без зупинки примірники) оператором alter system.

Попередження: якщо АБД встановлює dba_cache_advice = on, Oracle для збору статистик буде використовувати сторінки розділяється пулу, що може надати небажаний вплив на бібліотечний кеш. Наприклад, якщо в параметрі db_cache_size встановлено 500 Мб, Oracle буде використовувати істотний обсяг пам’яті розділяється пулу. Щоб уникнути цієї проблеми, потрібно попередньо в файлі init.ora встановити db_cache_advice = ready. В такому випадку Oracle буде виділяти пам’ять під час запуску екземпляра.

Після включення збору статистик (dba_cache_advice = on) і досить тривалого часу роботи бази даних для видачі прогнозу можна видати наступний запит:

column size_for_estimate
format 999,999,999,999
heading “Cache Size (m)”
column buffers_for_estimate
format 999,999,999
heading “Buffers”
column estd_physical_read_factor
format 999.90
heading “Estd Phys/Read Factor”
column estd_physical_reads
format 999,999,999
heading “Estd Phys/ Reads”
select
size_for_estimate,
buffers_for_estimate,
estd_physical_read_factor,
estd_physical_reads
from
v$db_cache_advice
where
name = “DEFAULT”
and
block_size = (SELECT value FROM V$PARAMETER
WHERE name = “db_block_size”)
and
advice_status = “ON”;

Висновок з скрипта показаний нижче. Зауважимо ще раз, що діапазон значень – від 10% поточного розміру кеша буферів до 200% поточного розміру.

                                Estd Phys    Estd Phys
Cache Size (MB) Buffers Read Factor Reads
—————- ———— ———– ————
30 3,802 18.70 192,317,943
é 10% поточного розміру
60 7,604 12.83 131,949,536
91 11,406 7.38 75,865,861
121 15,208 4.97 51,111,658
152 19,010 3.64 37,460,786
182 22,812 2.50 25,668,196
212 26,614 1.74 17,850,847
243 30,416 1.33 13,720,149
273 34,218 1.13 11,583,180
304 38,020 1.00 10,282,475
é Поточний розмір
334 41,822 .93 9,515,878
364 45,624 .87 8,909,026
395 49,426 .83 8,495,039
424 53,228 .79 8,116,496
456 57,030 .76 7,824,764
486 60,832 .74 7,563,180
517 64,634 .71 7,311,729
547 68,436 .69 7,104,280
577 72,238 .67 6,895,122
608 76,040 .66 6,739,731
é 2-й розмір

Тут при збільшенні кількості буферів не спостерігається ніяких пікових змін дискового вводу-виводу і маргінальних трендів. Це дуже типово для сховищ даних, в яких читаються великі таблиці в режимі повного перегляду. Отже, немає ніяких “оптимальних” значень параметра db_cache_size. Іншими словами, Oracle проявляє “ненаситний апетит” при споживанні буферів даних: чим більше значення параметра db_cache_size, тим менше буде операцій дискового введення-виведення. [В Керівництві по оптимізації продуктивності Oracle 9i за аналогічним прикладом робиться більш помірний висновок: збільшення поточного розміру кеша не призведе до значного підвищення продуктивності. – Прим. А.П.Соколова.]

Як правило, потрібно налаштовувати всю доступну пам’ять сервера, значення параметра db_cache_size слід встановлювати по точці “скорочуються доходів” (diminishing returns) – точки, після якої збільшення кількості буферів блоків даних не призводить до істотного збільшення коефіцієнта попадання в кеш буферів (рис. 2). Цей підхід дозволяє АБД Oracle визначати оптимальну кількість буферів.

Рис. 2. Визначення оптимального значення параметра: db_cache_size.

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

Порада: для збору статистик в поданні v $ db_cache_advice потрібне попереднє виділення буферів даних (включається установкою параметра db_cache_advice), тому може бути доцільним тільки одноразове включення збору статистик для визначення оптимального розміру кеша буферів. Пам’ятайте: для збору аналогічної інформації ви можете використовувати коефіцієнт попадань в кеш буферів даних.

У більш складних базах даних Oracle 9i можна управляти не тільки кількістю буферів блоків, але і розміром блоків. Наприклад, деякі блоки можуть бути дуже великими, що дозволить зменшити конкуренцію вводу-виводу. Пам’ятайте: витрати на введення-виведення блока розміром 32К не суттєво перевищують витрати на введення-виведення блока розміром 4К. Якщо програма “кластеризуються” записи в блоках бази даних, проектувальник бази даних для мінімізації вводу-виводу може прийняти рішення про збільшення розміру деяких блоків даних. Більш докладно про використання блоків даних різного розміру див. розділ 8 Концепцій).

Коли потрібно починати динамічну реконфігурацію

Якщо ви за допомогою своїх скриптів виявили перезагруженную область пам’яті, вам потрібно буде прийняти рішення про вибір області пам’яті, розмір якої можна зменшити, щоб розширити перезагруженную область пам’яті. У таблиці 1 показані порогові умови ініціювання динамічного зміни розмірів областей пам’яті.


















Область пам’яті  Умова перезагруженності  Умова недозагруженности 
Розділяється пул Непотрапляння в бібліотечний кеш Немає непотрапляння
Кеш буферів даних Коефіцієнт попадання <90% Коефіцієнт попадання> 95%
Сумарна пам’ять PGA Багато багатопрохідним обробки 100% оптимальної обробки

Таблиця 1. Граничні умови динамічного перерозподілу пам’яті.

На практиці вибір області пам’яті, розмір якої можна зменшити, полягає у виборі між поділюваним пулом і сумарною пам’яттю PGA (див. рис. 3). Справа в тому, що розмір розділяється пулу майже завжди менше розміру пам’яті для буферів даних і PGA.

Рис. 3. Типова конфігурація пам’яті баз даних Oracle.

Висновок

Засоби автоматичної настройки Oracle 9i надають АБД безприкладну можливість керування розмірами зон пам’яті будь-яких компонентів SGA і PGA. У міру розвитку Oracle 9i будуть розроблятися механізми автоматичної реконфігурації пам’яті залежно від потреб обробки.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*