Если у вас нет Enterprise Edition с Diagnostic Pack, то юзать AWR у вас не получится, а вот Statspack поставить не только можно, но и нужно. Да, он всё ещё присутствует, но к сожалению, практически не развивается. Одна из самых важных секций ‘Top 5 Timed Events’ показывают только события переднего плана (foreground events), по крайней мере, должен показывать. Когда пользовательский процесс ожидает фоновый процесс (background) эта секция должна учитывать только фоновое ожидание, а не активность фоновых процессов, иначе мы получим удвоенный учёт. Фоновая активность включена в события ‘Idle’ (простаивание) чтобы быть исключенной из секции «топ 5». К сожалению, новые версии Oracle DB выпускаются с новыми типами ожидания, которые вы не найдёте в списке событий простоя StatsPack’а.
Например, вот ‘Top 5 Timed Events’ в период с 22:00 по 23:00 без активности приложения:
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ LGWR worker group idle 6 22,049 ###### 65.2 AQPC idle 120 3,602 30014 10.7 heartbeat redo informer 3,568 3,601 1009 10.7 lreg timer 1,195 3,598 3011 10.6 direct path read 31,221 466 15 1.4 -------------------------------------------------------------
Простой и таймеры занимают первые позиции. Прямое чтение с диска кажется минимальным. А использование ЦПУ вообще нет. Очевидно, что здесь, что-то не так.
Statspack использует фиксированный лист событий ожидайний, которые рассматриваются им как ‘Idle’ (простой) и которые он хранит в STATS$IDLE_EVENT. Он пришёл к нам с давних времён, когда ещё не использовались классы. В текущей версии, более реалистичным выглядит список событий ожиданий из V$EVENT_NAME, где class_name=’Idle’ (V$EVENT_NAME where class_name=’Idle’).
Давайте сравним их (используется 12.1.0.1)
Во-первых, у нас есть несколько не-Idle событий, которые рассматриваются Statspack’ом как Idle:
SQL> select s.event statspack_idle_event,v.name,v.wait_class from STATS$IDLE_EVENT s left outer join V$EVENT_NAME v on s.event=v.name where wait_class!='Idle'; STATSPACK_IDLE_EVENT NAME WAIT_CLASS --------------------------------------- --------------------------------------- ---------- null event null event Other SQL*Net message to client SQL*Net message to client Network SQL*Net more data from client SQL*Net more data from client Network KSV master wait KSV master wait Other parallel recovery slave wait for change parallel recovery slave wait for change Other
Цель этого поста не является детальный разбор значения каждого события, но если оно рассматривается как событие простоя, то Statspack должен следовать такому же правилу.
Во-вторых, вы можем проверить события простоя, которых нет в списке у Statspack’а:
SQL> select s.event statspack_idle_event,v.name,v.wait_class from STATS$IDLE_EVENT s right outer join V$EVENT_NAME v on s.event=v.name where wait_class='Idle' and s.event is null;
STATSPACK_IDLE_EVENT NAME WAIT_CLASS
-------------------- ------------------------------------------ ----------
OFS idle Idle
heartbeat redo informer Idle
LGWR worker group idle Idle
Recovery Server waiting for work Idle
Recovery Server waiting restore start Idle
Recovery Server Surrogate wait Idle
Recovery Server Servlet wait Idle
Recovery Server Comm SGA setup wait Idle
parallel recovery coordinator idle wait Idle
recovery sender idle wait Idle
recovery receiver idle wait Idle
recovery merger idle wait Idle
virtual circuit next request Idle
lreg timer Idle
REPL Apply: txns Idle
REPL Capture/Apply: messages Idle
REPL Capture: archive log Idle
PL/SQL lock timer Idle
Emon coordinator main loop Idle
Emon slave main loop Idle
AQ: 12c message cache init wait Idle
AQ Cross Master idle Idle
AQPC idle Idle
Streams AQ: load balancer idle Idle
Sharded Queues : Part Maintenance idle Idle
REPL Capture/Apply: RAC AQ qmn coordinator Idle
iowp msg Idle
iowp file id Idle
netp network Idle
gopp msg Idle
Мы видим, что в поздней версии было введено достаточно много Idle событий.
Получается, что список Statspack’а — устарел, и чтобы его обновить нужно —
delete from STATS$IDLE_EVENT; insert into STATS$IDLE_EVENT select name from V$EVENT_NAME where wait_class='Idle'; commit;
После того, как мы обновили список ожиданий, можно пересобрать отчёт с тех же самых снепшотов и убедиться, что картина в ‘Top 5 Timed Events’ будет более реалистичная:
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ direct path read 31,221 466 15 48.7 CPU time 310 32.4 db file sequential read 49,137 77 2 8.0 SQL*Net vector data to client 15,189 31 2 3.3 enq: TM - contention 1 24 23937 2.5
На самом деле, в период с 22 до 23 были запущены job поддержи dbms_space.auto_space_advisor_job_proc — любит читать ваши таблицы большими кусками, для того, что бы определить если там есть свободное место. Также, не нравятся эти 24 секунды TM lock, в то время когда БД не использовалась. Эта информация была для нас скрыта в изначальном отчёте.
Patch?
Statspack is still supported and there’s a patch to add the following events as idle:
"virtual circuit next request" "AQ Cross Master idle" "AQ: 12c message cache init wait" "AQPC idle" "Emon coordinator main loop" "Emon slave main loop" "LGWR worker group idle" "OFS idle" "REPL Apply: txns" "REPL Capture/Apply: RAC AQ qmn coordinator" "REPL Capture/Apply: messages" "REPL Capture: archive log" "Recovery Server Comm SGA setup wait" "Recovery Server Servlet wait" "Recovery Server Surrogate wait" "Recovery Server waiting for work" "Recovery Server waiting restore start" "Sharded Queues : Part Maintenance idle" "Streams AQ: load balancer idle" "gopp msggopp msg" "heartbeat redo informer" "iowp file id" "iowp msg" "lreg timer" "netp network" "parallel recovery coordinator idle wait" "recovery merger idle wait" "recovery receiver idle wait" "recovery sender idle wait" "imco timer" "process in prespawned state"
(Nice way to be referenced by google for all those improbable wait events, isn’t it?)
However, I think that filing STATS$IDLE_EVENT from V$EVENTNAME, or maybe even replacing it as a view can be a better long term solution. Each version comes with new wait events and it seems that Statspack evolves only through patches.
Update later
I think that this page will become very dynamic as I’ll add idle events when I encounter them.
‘log file parallel write’ is background process by log writer (or rather by log writer slave since 12c, and ‘target log write size’ is the time spend by log writer activity)
insert into STATS$IDLE_EVENT values('log file parallel write');
insert into STATS$IDLE_EVENT values('target log write size');
Источник
https://blog.dbi-services.com/statspack-idle-events/