Статистична інформація рівня сегмента в подію 10046 Oracle 9.2, Інші СУБД, Бази даних, статті

Введення


У версії 9.2 в Oracle додалася можливість отримувати “статистичну інформацію рівня сегмента”. До словника даних було додано декілька уявлень v$, І для збору відповідної інформації можна вибірково включати збір статистики на рівні сегмента. Однак при виконанні трасування за допомогою події 10046 ця статистична інформація теж видається. Мабуть, хоча я і не знайшов ще ніякої певної інформації про це, вона з’явилася в наборі виправлень 9.2.0.2. Оскільки це – статистична інформація “джерела рядків” (“row source” statistics), вона буде входити в рядки STAT. Додаткова інформація – частина інформації про операції доступу до джерела рядків, а саме – поле “op=“. У цій статті ми розберемося, як знайти цю інформацію і як її можна використовувати. У видаваних даних є певні неузгодженості, але, в загальному випадку, ця статистична інформація рівня сегмента дає спеціалісту з аналізу продуктивності додаткову важливу інформацію для вивчення часу виконання транзакції і впливають на нього факторів.


Формат рядка STAT


У файлі трасування події 10046 статистична інформація рівня сегмента видається в рядках STAT. Це – статистична інформація “джерела рядків”, і додаткова інформація входить в загальну інформацію про операції доступу до джерела рядків, в поле “op=“. Ось два приклади, один – з файлу трасування до 9.2, а інший – з файлу трасування 9.2.


Файл трасування до версії 9.2:

STAT #5 id=1 cnt=1 pid=0 pos=0 obj=43135 op=”TABLE ACCESS CLUSTER SEG$ ”

Новий формат файлу трасування 9.2:

STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op=”SORT AGGREGATE (cr=167 r=4 w=0 time=31888 us)”

Зверніть увагу на нову інформацію, “(cr=167 r=4 w=0 time=31888 us)“. Значення”cr=“Відповідає кількості операцій логічного введення-виведення consistent reads, Значення “r=“- Кількості фізичних читань, значення”w=“- Кількості фізичних записів, а значення”time=“Визначає час виконання та одиницю виміру часу (наприклад, us– Мікросекунди). Врахуйте, що логічний введення-виведення “current mode“(Тобто cu= в файлі трасування) не видається.


Статистична інформація рівня сегмента, мабуть, видається тільки для операцій EXEC і FETCH. В контексті рядків STAT для конкретного оператора, дані “накопичуються” (“roll-up”) в ієрархії плану виконання, принаймні, в більшості випадків 2. При інтерпретації інформації рядок STAT з ненульовим значенням “obj=“Ідентифікує статистичну інформацію про доступ до відповідного сегменту. Ці значення будуть” накопичуватися “по ходу плану виконання, і зазвичай рядки STAT з нульовими значеннями “obj=“Будуть підсумовувати статистичну інформацію підлеглих джерел рядків.


Подання статистичної інформації


Отже, що ж можна визначити за цією інформацією? В трасувань файлах версій до 9.2 типова підсумкова інформація в рядку STAT буде мати вигляд (Release 8.1.7.2):

STATEMENT TEXT
select count(*) from dba_users
STATEMENT EXECUTION PLAN
Rows Row Source Operation
——- —————————————————————————————-
1 SORT AGGREGATE
12,047 MERGE JOIN
12,048 SORT JOIN
12,047 NESTED LOOPS
12,048 NESTED LOOPS
12,048 NESTED LOOPS
12,048 MERGE JOIN
10 SORT JOIN
9 NESTED LOOPS
10 TABLE ACCESS FULL USER_ASTATUS_MAP
9 TABLE ACCESS BY INDEX ROWID PROFILE$
162 INDEX RANGE SCAN (object id 43224)
12,056 SORT JOIN
12,047 TABLE ACCESS FULL USER$
24,094 TABLE ACCESS CLUSTER TS$
24,094 INDEX UNIQUE SCAN (object id 43126)
24,094 TABLE ACCESS CLUSTER TS$
24,094 INDEX UNIQUE SCAN (object id 43126)
12,047 TABLE ACCESS BY INDEX ROWID PROFILE$
216,846 INDEX RANGE SCAN (object id 43224)
12,047 SORT JOIN
7 TABLE ACCESS FULL PROFNAME$

Зараз, у версії 9.2, інформація має такий вигляд (Release 9.2.0.2):

STATEMENT TEXT
select count(*) from dba_users
STATEMENT EXECUTION PLAN
Rows Row Source Operation
——- —————————————————————————————-
1 SORT AGGREGATE (cr=167 r=4 w=0 time=31888 us)
36 MERGE JOIN (cr=167 r=4 w=0 time=31863 us)
36 SORT JOIN (cr=164 r=3 w=0 time=30441 us)
36 TABLE ACCESS BY INDEX ROWID PROFILE$ (cr=164 r=3 w=0 time=29994 us)
649 NESTED LOOPS (cr=163 r=3 w=0 time=25712 us)
36 NESTED LOOPS (cr=161 r=3 w=0 time=22979 us)
36 NESTED LOOPS (cr=87 r=3 w=0 time=21223 us)
36 MERGE JOIN (cr=13 r=3 w=0 time=19489 us)
9 SORT JOIN (cr=6 r=3 w=0 time=18519 us)
9 TABLE ACCESS BY INDEX ROWID PROFILE$ (cr=6 r=3 w=0 time=18313 us)
163 NESTED LOOPS (cr=5 r=2 w=0 time=11319 us)
9 TABLE ACCESS FULL USER_ASTATUS_MAP (cr=3 r=1 w=0 time=1278 us)
153 INDEX RANGE SCAN I_PROFILE (cr=2 r=1 w=0 time=9769 us) (object id 139)
36 SORT JOIN (cr=7 r=0 w=0 time=837 us)
36 TABLE ACCESS FULL USER$ (cr=7 r=0 w=0 time=420 us)
36 TABLE ACCESS CLUSTER TS$ (cr=74 r=0 w=0 time=1535 us)
36 INDEX UNIQUE SCAN I_TS# (cr=2 r=0 w=0 time=206 us) (object id 7)
36 TABLE ACCESS CLUSTER TS$ (cr=74 r=0 w=0 time=1563 us)
36 INDEX UNIQUE SCAN I_TS# (cr=2 r=0 w=0 time=145 us) (object id 7)
612 INDEX RANGE SCAN I_PROFILE (cr=2 r=0 w=0 time=1219 us) (object id 139)
36 SORT JOIN (cr=3 r=1 w=0 time=1283 us)
1 TABLE ACCESS FULL PROFNAME$ (cr=3 r=1 w=0 time=936 us)

На основі цієї інформації ми можемо отримати статистику по сегментам і визначити внесок кожного сегмента у використання ресурсів на етапах EXEC і FETCH виконання оператора. З урахуванням представленого вище прикладу, для кожного сегмента отримуємо наступну статистику:

                                                                 Elapsed
Object ID LIO (cr=) Physical Reads Physical Writes Time(sec)
———— ————— ————— ————— —————
94 2 1 0 0.011276
139 4 1 0 0.010988
16 144 0 0 0.002747
280 3 1 0 0.001278
95 3 1 0 0.000936
22 7 0 0 0.000420
7 4 0 0 0.000351
———— ————— ————— ————— —————
Total 167 4 0 0.027996

Ці підсумкові дані були отримані за допомогою описаного раніше підходу. У рядку STAT кожного оператора буде ідентифікатор (параметр id=) Рядки і ідентифікатор батьківського рядки (параметр pid=). Самая верхній рядок в ієрархії буде мати ідентифікатор 1 та ідентифікатор батьківського рядки, рівний 0. Рядки STAT з ненульовим значенням “obj=“Будуть містити статистичну інформацію про доступ до відповідного сегменту. Ці значення будуть накопичуватися за ієрархією плану виконання, і, звичайно, рядки STAT зі значеннями 0 у параметра “obj=“Будуть підсумовувати статистичні показники своїх породжених джерел рядків.


Перевірка статистичної інформації


Приклад 1


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

STATEMENT STATISTICS
Action Count CPU Elapsed PIO Blks LIO Blks Consistent Current Rows
——- —– ———- ———– ——– ——– ———- ——- ——–
PARSE 1 0.090000 0.142649 6 149 149 0 0
EXEC 1 0.000000 0.000465 0 0 0 0 0
FETCH 2 0.020000 0.031909 4 167 167 0 1
——- —– ———- ———– ——– ——– ———- ——- ——–
Total 4 0.110000 0.175023 10 316 316 0 1

Перевірка реального часу виконання (elapsed time) для статистичної інформації рівня сегмента являє собою цікаву проблему. Якщо подивитися на реальний час виконання операцій EXEC і FETCH, І відняти процесорний час (CPU), отримуємо значення 0.012374 секунди, або 12374 us. Якщо потім подивитися на загальний час виконання в нашій статистиці за сегментами, там можна побачити значення 0.027996 секунди, або 27996 us, Але, якщо повернутися і проаналізувати загальний час за всіма джерелами рядків (тобто time=31888 us), То виходить трохи менше, ніж загальний час виконання операцій EXEC і FETCH, 0.032374 секунди, або 32374 us. В цьому є сенс, якщо врахувати, що загальний час виконання у статистичній інформації рівня сегментів включає процесорний час (CPU time), необхідне для доступу до джерела рядків (тобто логічного вводу-виводу), а не тільки час виконання фізичного введення-виведення. Слід також зазначити, що в цьому випадку не було вводу-виводу “current mode”, але докладніше про це – в наступному прикладі.


Давайте розглянемо ще пару прикладів. Що станеться, якщо є логічний введення-виведення current mode (Тобто cu= в операціях EXEC або FETCH), Або у статистичній інформації на рівні оператора будуть ненульові значення і для EXEC, і для FETCH?


Приклад 2


Наступний приклад показує використання вводу-виводу як consistent mode (cr=), Так і current mode (cu=) В ході операції EXEC при виконанні оператора. При вивченні статистичної інформації рівня оператора і підсумків по сегментам можна побачити, що сервер Oracle на рівні сегмента повідомляє тільки про введення-виведення consistent mode. У цьому прикладі ненульові значення будуть тільки в операціях EXEC, А в попередньому прикладі вони були тільки в операціях FETCH. Схоже, для операції PARSE статистична інформація рівня сегмента не видається.

STATEMENT TEXT
delete from dependency$ where d_obj#=:1
STATEMENT STATISTICS
Action Count CPU Elapsed PIO Blks LIO Blks Consistent Current Rows
——- —– ———- ———– ——– ——– ———- ——- ——–
PARSE 6 0.020000 0.012211 1 43 43 0 0
EXEC 6 0.010000 0.019214 3 38 16 22 4
FETCH 0 0.000000 0.000000 0 0 0 0 0
——- —– ———- ———– ——– ——– ———- ——- ——–
Total 12 0.030000 0.031425 4 81 59 22 4
STATEMENT EXECUTION PLAN
Rows Row Source Operation
——- —————————————————————————————-
0 DELETE (cr=3 r=2 w=0 time=7656 us)
1 TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=3 r=0 w=0 time=63 us)
1 INDEX RANGE SCAN I_DEPENDENCY1 (cr=2 r=0 w=0 time=37 us) (object id 127)
Elapsed
Object ID LIO (cr=) Physical Reads Physical Writes Time(sec)
———— ————— ————— ————— —————
127 2 0 0 0.000037
96 1 0 0 0.000026
———— ————— ————— ————— —————
Total 3 0 0 0.000063

Приклад 3


Третій, і останній, приклад показує, що видається статистична інформація не завжди відповідає передбачуваної. У цьому прикладі зверніть увагу, що в SQL-операторі використана конструкція “FOR UPDATE“, І в джерелах рядків ми отримуємо ситуацію, коли інформація не накопичується, як можна було очікувати.

STATEMENT STATISTICS
Action Count CPU Elapsed PIO Blks LIO Blks Consistent Current Rows
——- —– ———- ———– ——– ——– ———- ——- ——–
PARSE 1 0.000000 0.001438 0 0 0 0 0
EXEC 1 0.000000 0.000430 0 4 3 1 0
FETCH 2 0.000000 0.000143 0 3 3 0 1
——- —– ———- ———– ——– ——– ———- ——- ——–
Total 4 0.000000 0.002011 0 7 6 1 1
STATEMENT TEXT
select mynum from andy
where mynum = 99
for update
STATEMENT EXECUTION PLAN
Rows Row Source Operation
——- —————————————————————————————-
1 FOR UPDATE (cr=3 r=0 w=0 time=113 us)
2 TABLE ACCESS FULL ANDY (cr=6 r=0 w=0 time=276 us)
Elapsed
Object ID LIO (cr=) Physical Reads Physical Writes Time(sec)
———— ————— ————— ————— —————
30536 6 0 0 0.000276
———— ————— ————— ————— —————
Total 6 0 0 0.000276

Зверніть увагу, що тепер у нас є введення-виведення consistent read як для операції EXEC, Так і для FETCH. Ми також виконали один логічний введення-виведення current mode в ході операції EXEC, Який знову проігноровано у статистичній інформації рівня сегмента.


Висновок


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


 

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


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

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

Ваш отзыв

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

*

*