Описание как работает ash\awr и что полезного там можно найти

1. Есть ли жизнь без EM(CC)
ИЛИ ЧТО МОЖНО НАЙТИ В ASHAWRV$SESSTATV$SESSION

2. Oracle Midlands #2: ASH Architecture and Advanced Usage - Graham Wood
Awr идет с 10той версии
Используется не только для awr отчетов
• addm отчеты
• sql tuning advisor
• segment advisor (The Segment Advisor identifies segments that have space
available for reclamation. It performs its analysis by examining usage and growth
statistics in the Automatic Workload Repository (AWR), and by sampling the data in
the segment. )
По умолчанию снимок берется 1 раз в час, удержание 8мь дней
посмотреть можно в select * from dba_hist_wr_control ;
обычно ставлю раз в 10-15 минут с удержанием месяц.
если требуется снять снапшот прямо сейчас :
exec dbms_workload_repository.create_snapshot(); параметр flush level ( alltypical)
TOPNSQL - How to Control the Number of SQL Statements and other information
displayed in AWR Report (Doc ID 1357637.1)

3. бывает так, что запрос не попадает в AWR, помочь можно добавив colored_sql
exec dbms_workload_repository.add_colored_sql(sql_id =>'&SQL_ID');
убрать через
exec dbms_workload_repository.remove_colored_sql(sql_id =>'&SQL_ID');
посмотреть текущие в:
SQL> SELECT * FROM wrm$_colored_sql;

5. в AWR попадает не все, по умолчанию идет 1 из 10 sample ( именно по этому стараемся смотреть в
v$active_session_history)
Под капотом:
col PARAMETER format a25; col SESSION_VALUE format a20; col INSTANCE_VALUE format a20;col DEFAULT_VALUE format a20; col DESCRIPTION format a100
select a.ksppinm as Parameter,
b.ksppstvl Session_Value,
c.ksppstvl Instance_Value ,
b.ksppstdf Default_value,
decode(bitand(a.ksppiflg/256,3),1, 'True', 'False') SESSMOD,
decode(bitand(a.ksppiflg/65536,3),1,'IMMEDIATE',2,'DEFERRED',3,'IMMEDIATE','FALSE') SYSMOD,
a.ksppdesc Description
from sys.x$ksppi a, sys.x$ksppcv b , sys.x$ksppsv c where a.indx = b.indx and a.indx = c.indx
and ksppinm like '_ash_%' escape ''
order by a.ksppinm;

6. Из интересного:
_ash_sampling_interval = 1000 The interval that ASH samples, lessened, causing samples to be created
more often than the default of 1000.
_ash_sample_all = False, True results in samples of even inactive sessions to be created, increasing the
amount of ASH data by 10X or more.
_ash_disk_filter_ratio = 10 Set to 1 would result in ASH writing all samples to the AWR instead of 1:10.
_ash_eflush_trigger The percentage above which if the in-memory ASH is full the emergency flusher will
be triggered
Включитьвыключить
Controlling Diagnostic and Tuning Pack Usage (Doc ID 436386.1)
Пересоздать AWR
How to Recreate The AWR ( AUTOMATIC WORKLOAD ) Repository ? (Doc ID 782974.1)

7. Может повлиять на то как отображаются графики в em:
До
alter system set "_ash_sampling_interval"=100 scope=spfile;

8. После
perfomance home и top activity теперь показывают погоду:

9. Для чего обычно используют AWR:
for i in $(ls -1 $ORACLE_HOME/rdbms/admin | grep ^awr); do cat $i| grep | grep -A2 -B1 NAME ; done
awrblmig.sql -- AWR Baseline Migrate
awrload.sql -- AWR LOAD: load awr from dump file
awrextr.sql -- AWR Extract
awrrpt.sql
awrddrpi.sql -- Workload Repository Compare Periods Report
awrgdrpi.sql -- Workload Repository Global Compare Periods Report
awrginp.sql -- AWR Global Input
awrgrpti.sql -- Workload Repository RAC (Global) Report
awrsqrpi.sql -- Workload Repository SQL Report Instance
Особенно «информативны» эти отчеты за сутки.. Или за неделю )))

10. Рассмотрим на примере:

11. Хороший период:

12. Все плохо

13. Посмотрели на рост :
OWNER OBJECT_NAME OBJECT_TYPE Tablespace Name Growth in MB Total Size(MB)
------------------- ------------------------------ ------------ --------------
RTDM_MAIN CR_DATA TABLE USERS 1260,37346 12720
RTDM_MAIN RTDM_APPLICATION TABLE USERS 811,988111 9099
RTDM_MAIN RTDM_APP_ADDRESS TABLE USERS 444,228698 5861
RTDM_MAIN RTDM_BKI_ADDRESS TABLE USERS 431,456848 3027
RTDM_MAIN RTDM_APP_RESULT TABLE USERS 320,561265 3684
RTDM_MAIN DISP_QUEUE TABLE USERS 250,920684 2147
не сильно и выросла , план за хороший и плохой период один и тот же 27109969

14. Imho, более наглядно посмотреть на историю выполнения планов этого запроса:
SNAP_ID NODE BEGIN_INTERVAL_TIME SQL_ID PLAN_HASH_VALUE EXECS AVG_ETIME AVG_LIO AVG_PIO
---------- ------ ------------------------------- ------------- --------------- ---------- ------------ -------------- ----------
39024 1 13.10.15 12:30:03,051 cyq534bwajmtb 2873350031 5 12.895 930,619.8 320,2
…….
41137 1 26.11.15 13:00:10,922 cyq534bwajmtb 27109969 7 6.388 1,064,021.4 0
41140 1 26.11.15 14:30:41,749 cyq534bwajmtb 2 7.487 1,064,121.0 0
41142 1 26.11.15 15:30:54,210 cyq534bwajmtb 2873350031 4 5.309 1,064,017.0 0
41182 1 27.11.15 11:31:00,526 cyq534bwajmtb 3 6.605 1,064,016.3 0
41183 1 27.11.15 12:00:10,075 cyq534bwajmtb 2 5.356 1,064,004.0 0
41323 1 30.11.15 10:00:42,886 cyq534bwajmtb 36 5.673 1,064,040.8 0
41324 1 30.11.15 10:30:58,739 cyq534bwajmtb 7 5.810 1,064,011.4 0
41375 1 01.12.15 12:00:10,761 cyq534bwajmtb 1 5.274 1,064,023.0 0
41375 1 01.12.15 12:00:10,761 cyq534bwajmtb 27109969 1 5.525 1,064,254.0 2
41379 1 01.12.15 14:00:32,980 cyq534bwajmtb 2873350031 1 5.376 1,064,014.0 0
41379 1 01.12.15 14:00:32,980 cyq534bwajmtb 27109969 1 6.725 1,064,204.0 0
41382 1 01.12.15 15:30:59,257 cyq534bwajmtb 1 7.140 1,064,124.0 0
41388 1 01.12.15 18:30:30,805 cyq534bwajmtb 2873350031 1 5.377 1,064,008.0 0
41388 1 01.12.15 18:30:30,805 cyq534bwajmtb 27109969 1 5.785 1,064,265.0 0
41472 1 03.12.15 12:30:35,311 cyq534bwajmtb 2 6.420 1,064,135.5 ,5
41482 1 03.12.15 17:30:50,739 cyq534bwajmtb 2 5.369 1,063,997.5 0
41526 1 04.12.15 15:30:16,445 cyq534bwajmtb 6 5.632 1,064,047.7 0
41527 1 04.12.15 16:00:22,787 cyq534bwajmtb 2 5.261 1,064,013.5 0
41638 1 06.12.15 23:30:17,941 cyq534bwajmtb 4 5.877 1,091,062.5 ,25
REBOOT:
41640 1 07.12.15 03:13:47,869 cyq534bwajmtb 2 36.800 1,091,000.5 1090944,5
41642 1 07.12.15 04:00:49,595 cyq534bwajmtb 3 39.663 1,091,056.7 1091008
41652 1 07.12.15 09:00:11,203 cyq534bwajmtb 1 43.134 1,092,272.0 1092224
41653 1 07.12.15 09:30:14,188 cyq534bwajmtb 1 62.474 1,092,272.0 1092224
41658 1 07.12.15 12:00:35,150 cyq534bwajmtb 7 52.114 1,093,287.1 1092875,43
41659 1 07.12.15 12:30:51,218 cyq534bwajmtb 1540862498 3 93.402 1,101,328.3 1093632,33
41660 1 07.12.15 13:00:09,968 cyq534bwajmtb 27109969 5 6.243 1,094,119.8 0
41661 1 07.12.15 13:30:27,535 cyq534bwajmtb 5 8.505 1,094,519.2 0
41662 1 07.12.15 14:00:39,128 cyq534bwajmtb 2 32.663 1,094,987.0 1932,5
41665 1 07.12.15 15:30:19,663 cyq534bwajmtb 3 28.259 858,350.3 2913,6
41667 1 07.12.15 16:30:37,438 cyq534bwajmtb 4 74.767 1,096,608.3 1095816
41702 1 08.12.15 10:00:51,294 cyq534bwajmtb 2873350031 1 69.031 1,098,113.0 1096288
41702 1 08.12.15 10:00:51,294 cyq534bwajmtb 27109969 1 88.426 1,098,642.0 1096288
41703 1 08.12.15 10:30:20,429 cyq534bwajmtb 1 81.022 1,098,259.0 1096288
41707 1 08.12.15 12:30:23,715 cyq534bwajmtb 4 57.403 1,097,172.0 1096328

15. План тот же самый, но PIO выросло
смотрим на чем конкретно висит запрос:
SQL> @ash_sqlmon cyq534bwajmtb 27109969
ID PLAN_OPERATION OBJECT_OWNER OBJECT_NAME WAIT_PROFILE
---------- --------------------------------------------------------- -------------- ------------------------------ ------------------------------------------
0 SELECT STATEMENT ON CPU(4); ON CPU(2);
1 SORT UNIQUE
2 UNION-ALL
3 HASH GROUP BY
4 TABLE ACCESS FULL RTDM_MAIN DISP_QUEUE direct path read(96); ON CPU(20);
5 HASH GROUP BY ON CPU(2);
6 TABLE ACCESS FULL RTDM_MAIN DISP_QUEUE direct path read(81); ON CPU(26); enq: KO - fast object
checkpoint(12); reliable message(1);
7 HASH GROUP BY
8 TABLE ACCESS BY INDEX ROWID RTDM_MAIN DISP_QUEUE
9 INDEX RANGE SCAN RTDM_MAIN QUEUE_BLOCK_IDX
и тут оно, DPR ! бывает для таблиц если
– ее размер >2(3)% sga
– Less than 50% of the blocks of the table is already in the buffercache.
– Less than 25% of the blocks in the buffercache are dirty.
Вероятно, что до рестарта более 50% таблицы было в кеше, после рестарта с текущим профилем нагрузки
таблица уже не попадала в кэш, и , т.к размер превышал 2(3)% sga, чтение шло через DPR
В базе уже был настроен keep пул, поэтому предложил, если этот запрос критичен, то перенести в него
таблицу явно
* Пример: что будет если таблица не войдет в keep pool полностью

16. можно найти( взято из ASH Architecture and Advanced Usage ) время отклика ожиданий класса User I/O:
select event,round (est_dbtime_ms/est_waits,1) as est_avg_latency_ms
from (select event,round(sum(case when time_waited >0 then greatest(1,1000000/time_waited) else 0 end ))
as est_waits,sum(1000) as est_dbtime_ms from v$active_session_history where sample_time > sysdate -50/1440
and wait_class ='User I/O' group by event ) order by 2 desc;
и построить график распределения по времени:
http://goo.gl/W65DeD
Для чего может пригодиться:

17. посмотреть нагрузку по cpu из awr:
select start_time,round (100*"'LOAD'"/"'NUM_CPU_CORES'") AS LOAD from
(
select os.INSTANCE_NUMBER,stat_name,sum(os.value) as load,
min(to_date(to_char(s.begin_interval_time,'DD.MM.YYYY hh24.mi.ss'))) as START_TIME,max(to_date(to_char(s.end_interval_time,'DD.MM.YYYY hh24.mi.ss'))) end_time
from DBA_HIST_OSSTAT os join
DBA_HIST_SNAPSHOT s on s.snap_id= os.SNAP_ID
where os.stat_name in ('LOAD','NUM_CPU_CORES','INSTANCE_NUMBER')
group by os.stat_name, (trunc(to_date(to_char(s.begin_interval_time,'DD.MM.YYYY hh24.mi.ss')),'HH24')),os.INSTANCE_NUMBER
)
pivot( max(LOAD) for stat_name in ('LOAD','NUM_CPU_CORES') )
where instance_number=2
order by instance_number,start_time asc ;

18. вытащить топ сегментов за последние N минут
* Пример как такой подход может пригодиться

19. топ запрсов за последние N минут

20. вытащить все фулсканы ( которые попали в ash) за последние сутки
sql> @http://blog.tanelpoder.com/files/scripts/ash/ashtop.sql sql_id,event "sql_plan_operation='TABLE ACCESS' and sql_plan_options='FULL'" sysdate-1/24 sysdate
• Видео от автора ashtopsnapper о том как ими пользоваться
• + http://enkitec.tv/?s=snapper

21. ========
•Unique key можно определить по - object = “-1” и current_file + current_obj#=0
•Foreign key можно определить по наличию существующего current_obj# + current_file + current_obj
•Bitmap index для него current_obj=>0 и file and block = 0
create table tp (id number, parent varchar2(30));
insert into tp values (1, 'first');
insert into tp values (2, 'second');
insert into tp values (3, 'third');
insert into tp values (4, 'forth');
commit;
create table tc (id number, child varchar2(30), p_id number);
insert into tc select rownum, rpad('X',29), mod(level,3)+1 from dual connect by level <=1000000;
commit;
alter table tp add primary key(id);
alter table tc add constraint tc_fk foreign key(p_id) references tp(id);
create bitmap index i_tc_fk_p_id on tc(p_id);
FK
drop index i_tc_fk_p_id;
create index i_tc_fk_p_id on tc(p_id);
=====sess1
insert into tp values (5, 'fifth');
==== sess2
insert into tc values (1000003, 'xxxxxxxxx', 5);
====bitmap index tx lock:
drop index i_tc_fk_p_id;
create bitmap index i_tc_fk_p_id on tc(p_id);
delete from tp where id=5;
delete from tc where id > 1000000;
====sess1
insert into tc values (1000001, 'xxxxxxxxx', 4);
====sess2
insert into tc values (1000002, 'xxxxxxxxx', 4);
===TX
sess1:12:10:08 (1)c##> insert into tp values (5,'asdasdas');
sess2:12:10:36(1)c##> insert into tp values (5,'asdasdas');
Enq: TX demo:

23. про sql_exec_id
SELECT sql_exec_id, sql_id FROM v$session WHERE sid = USERENV('SID' ) ;
В двух словах – счетчик выполений для sql_id

24. Благодаря sql_exec_id легко можно постороить график кол-ва выполнений в разрезе времени по запросам:
select date#,"'1'" as first_node,"'2'" as second_node from (
SELECT TRUNC(sample_time, 'MI') - MOD(TO_CHAR(sample_time, 'MI'), 30) / (24 * 60) as date#,instance_number,
MAX (sql_exec_id) - MIN (sql_exec_id) EXECUTIONS_PER_30_MINUTE
FROM dba_hist_active_sess_history
WHERE sql_id = '77qx41mkwcm92'
group by TRUNC(sample_time, 'MI') - MOD(TO_CHAR(sample_time, 'MI'), 30) / (24 * 60) ,instance_number
order by 1 asc )
pivot
(
sum(EXECUTIONS_PER_30_MINUTE)
for instance_number in ('1' ,'2' )
) order by date# asc;

25. Последний раз про блокировки
Знакомая всем картина
Видим что одна сессия удерживающая блокировку ни чем не занята ( idle )

26. займемся анализом:
select cast(min (ash.SAMPLE_TIME) as date) as start#
,round (24*60*(cast (max(ash.SAMPLE_TIME) as date) - cast(min (ash.SAMPLE_TIME) as date) ),2) as duration#
,ash.sql_id,ash.top_level_sql_id,ash.BLOCKING_SESSION as B_SID,ash.BLOCKING_SESSION_SERIAL# as b_serial#
,ash2.SQL_EXEC_ID b_sql_exec_id
,ash.event,do.object_name
,sum(decode(ash.session_state,'ON CPU',1,0)) "CPU"
,sum(decode(ash.session_state,'WAITING',1,0)) - sum(decode(ash.session_state,'WAITING', decode(ash.wait_class, 'User I/O',1,0),0)) "WAIT"
,sum(decode(ash.session_state,'WAITING', decode(ash.wait_class, 'User I/O',1,0),0)) "IO"
,sum(decode(ash.session_state,'ON CPU',1,1)) "TOTAL"
,du.username
,dp.owner||nvl2(dp.object_name,'.'||dp.object_name,null) ||nvl2(dp.procedure_name,'.'||dp.procedure_name,null) as pl_sql_obj
,ash2.machine as blocking_machine
from dba_hist_active_sess_history ash
left join dba_objects do on do.object_id=ash.CURRENT_OBJ#
join dba_hist_active_sess_history ash2 on ash.BLOCKING_SESSION=ash2.session_id and ash.BLOCKING_SESSION_SERIAL#=ash2.session_serial# and ash.SNAP_ID=ash2.SNAP_ID
join dba_users du on du.USER_ID=ash2.USER_ID
left join dba_procedures dp on dp.object_id=ash2.PLSQL_ENTRY_OBJECT_ID and dp.subprogram_id=ash.PLSQL_ENTRY_SUBPROGRAM_ID
where ash.SQL_ID is not NULL
and ash.SAMPLE_TIME > trunc(sysdate)
group by ash.SQL_EXEC_ID,ash2.SQL_EXEC_ID, ash2.machine, ash.session_id,ash.session_serial#,
ash.event,ash.sql_id,ash.top_level_sql_id,ash.BLOCKING_SESSION,ash.BLOCKING_SESSION_SERIAL#, ash2.sql_id ,du.username,
dp.owner||nvl2(dp.object_name,'.'||dp.object_name,null) ||nvl2(dp.procedure_name,'.'||dp.procedure_name,null)
,do.object_name
having sum(decode(ash.session_state,'WAITING',1,0)) - sum(decode(ash.session_state,'WAITING', decode(ash.wait_class, 'User I/O',1,0),0)) >0
and max(ash.SAMPLE_TIME) - min (ash.SAMPLE_TIME) > interval '3' minute
order by 1,ash2.sql_exec_id;

27. На предыдущем слайде зеленым обведено когда сессия сама висела на блокировках:
select count (*),cast(min (SAMPLE_TIME) as date) as start#,
cast(max (SAMPLE_TIME) as date) as end#,
round (24*60*(cast(max (SAMPLE_TIME) as date) -cast(min (SAMPLE_TIME) as date)),3) as dur_in_min#,
sql_id,event,sql_exec_id,BLOCKING_SESSION,BLOCKING_SESSION_SERIAL#
from gv$active_session_history where SESSION_ID=1520 and session_serial#=40745 and sql_exec_id in
(16777279,16777326,1677732,16780460,16777279,16777326,16779119,16780460)
group by sql_id,event,sql_exec_id,BLOCKING_SESSION,BLOCKING_SESSION_SERIAL# order by 2;
в среднем сессии блокируют друг друга по 2 минуты,
но тут видно, что после того, как блокировка ушла и запрос отработал прошло ~2.3 минуты ( 9.45.14 -9.42.37 )
во время которых база держала блокировку блокируя другие сессии , сама при этом ничем не занималась
( ждала ответа от клиента )

28. v$sessionv$sesstatv$sesmetricsnapper

29. Пример (орфография сохранена :] )
Смари, там есть медленый запрос при обращении на страницук stat.html, требуется чтобы когда мы её
запросим, ты посмотрел на временной виртушке со стендбайной базой на новой площадке xxxxxxx и сказал
потом можно ли вообще что-то сделать с этим запросом или нет :) я тебя сейчас в чат подключу, ок?

30. смотрим что там есть:
select ss.INST_ID,sc.session_id||','||ss.serial# as sid_serial,CASE WHEN ss.state != 'WAITING' THEN 'WORKING' ELSE 'WAITING' END AS state,
CASE WHEN ss.state != 'WAITING' THEN 'On CPU / runqueue' ELSE ss.event END as sw_event ,
ss.sql_id,ss.seconds_in_wait,ss.USERNAME,ss.program,sc.cpu,sc.PHYSICAL_READS, sc.LOGICAL_READS,
round (sc.PGA_MEMORY/1024/1024,1) as PGA_MEM_MB,sc.HARD_PARSES ,sc.SOFT_PARSES
from gV$SESSMETRIC sc
join gv$session ss on ss.sid=sc.session_id and ss.inst_id=sc.inst_id
where (sc.LOGICAL_READS >0 and sc.CPU=0) or sc.cpu >0 or sc.PGA_MEMORY/1024/1024 >20
order by sc.cpu asc
Видим что сессий ни разу не одна

31. Что дальше ?
exec sys.dbms_system.set_ev(&sid,&serial, 10046, 12,'');
Будет, но позже  для сравнения

32. Для начала посмотрим чем занималась сессия snapper’ом

33. можно предположить что:
Физических чтений нет совсем, все тягается из кеша ( 364.77 MBs )
Выборка почти вся по индексам
consistent gets from cache (fast path) – фича 11g для уменьшения LIO в NL соединении
table fetch by rowid Number of rows that are fetched using a ROWID (usually recovered from an index)
index range scans per second (the statistic index scans kdiixs1 shows that)
На 70 выполнений 75 round trip – получали не большой набор данных [ count (*) ]
Ооочень долго ждем клиента

34. конкретно по топу запросов:
@plan_id 6xhjsj4vujst9
@plan_id caaajx1n91b6q
@plan_id 57z74hjxwggvg
@plan_id 7rw96uyszysuu
@plan_id fj6b6ra6n09g1

35. Подтвердим выводы запросом по ash :
select TRUNC(SAMPLE_TIME, 'MI') time, ash.sql_id, ash.event, sum(decode(ash.session_state,'ON CPU',1,0)) "CPU",
sum(decode(ash.session_state,'WAITING',1,0)) - sum(decode(ash.session_state,'WAITING', decode(en.wait_class, 'User I/O',1,0),0)) "WAIT" ,
sum(decode(ash.session_state,'WAITING', decode(en.wait_class, 'User I/O',1,0),0)) "IO" , sum(decode(ash.session_state,'ON CPU',1,1)) "TOTAL",
substr (s.sql_text,1,100) textfrom v$active_session_history ash left join v$event_name en on en.event#=ash.event# left join v$sql s on
s.sql_id=ash.sql_id join v$session ses on ash.session_id=ses.sid and ash.session_serial#=ses.serial#where 1=1 --ash.SQL_ID is not NULLand
ses.sid=&1and ash.SAMPLE_TIME > sysdate - &2/(24*60)group by ash.sql_id , ash.event,substr (s.sql_text,1,100) ,TRUNC(SAMPLE_TIME, 'MI')order by
TRUNC(SAMPLE_TIME, 'MI') desc;

36. тоже самое из трассировок:
tkprof s00pgp_ora_2494.trc s00pgp_ora_2494.trc.res sort=exeela
из 180 секунд трассировки база работала 57 секунд,
132 секунды ждали от клиента
за те 57 секунд база успела прогнать 173 запроса

37. Еще не все  можно вытащить информацию более наглядно:
TRCANLZR (TRCA): SQL_TRACE/Event 10046 Trace File Analyzer - Tool for Interpreting Raw SQL Traces (Doc ID 224270.1)

38. Mailto:bushmelev.aa@gmail.com
Skype: bushmelev_aa