Базы данных Oracle - статьи
в предыдущем примере итоговую статистическую
Если сравнить полученную в предыдущем примере итоговую статистическую информацию по объектам с представленной ниже реальной статистической информацией уровня оператора, можно увидеть, что общее количество логических чтений для всех сегментов равно количеству логических чтений в ходе операций 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?
Следующий пример показывает использование ввода-вывода как 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
Третий, и последний, пример показывает, что выдаваемая статистическая информация не всегда соответствует предполагаемой. В этом примере обратите внимание, что в 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, который снова проигнорирован в статистической информации уровня сегмента.
