09. ASH (Active Session History)

1. 기존 성능 분석의 문제점

\- 기존에 제공 되던 동적 성능 뷰(V$) 만으로는 문제를 빨리 찾기가 힘들었다.
\- SQL Trace로는 상세한 분석은 가능하나 시스템에 부하도 많이 가고, 분석 완료하는데 시간이 오래걸려 확인하려는 순간 상황이 종료 될 수 있다.

2. 10g New feature ASH 기능

\- 기존의 성능분석으로 인한 어려움을 개선하고자 AWR의 ASH 기능이 나오게 되었다.
\- 별도의 모니터링 툴 없이 세션 레벨의 실시간 모니터링이 가능하게 되었다.
\- v$active_session_history 뷰를 이용해 ASH Buffer에 저장된 세션 정보를 조회할 수 있다.

\- 특징

 : 현재 접속중인 Active 세션 정보를 1초에 한번씩 샘플링해서 ASH Buffers에 저장한다.
 : SGA의 Shared Pool에 CPU당 2MB의 Buffer를 할당한다.
 : 1시간 or Buffer의 2/3가 찰때 Disk에 기록한다. (AWR에 저장한다.=>SYSAUX Tablespace)
 : 초단위로 쓰기가 발생하기 때문에 경합을 피하기 위해 Latch가 없다. (일관성이 잘못될 가능성이 있다.)
 : 1/10만 샘플링해서 저장.(문제가 되는 대기 이벤트는 일정간격을 두고 지속적으로 발생하기 때문에 샘플링 된 자료만으로도 원인을 찾는데 큰 지장이 없다)
 : v$active_session_history 뷰를 조회했을 때 정보가 찾아지지 않는다면 이미 AWR에 쓰여진 것으로 dba_hist_active_sess_history뷰를 조회하면 된다.

-- CPU 갯 수 별 ASH Buffers 의 크기 --


* 8cpu *

SQL> select * from v$sgastat where name ='ASH buffers';

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  ASH buffers                  16777216


* 1cpu *

SQL> select * from v$sgastat where name ='ASH buffers';

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  ASH buffers                   2097152

3. v$active_session_history 조회시 주의사항

 

\- v$active_session_history 조회시 Wait Class가 Application, Concurrency, Cluster, User I/O 일 때만 의미 있는 값이다.
\- 예를 들어, ITL 슬롯 부족 때문에 발생하는 enq:TX - allocate ITL entry 대기 이벤트는 Configuration에 속하므로,v$active_session_history 뷰를 조회할 때 함께 출력되는 오브젝트에 Lock이 걸렸다고 판단해서는 안된다.
\- 대개 그럴 때는 오브젝트번호가 \-1로 출력되지만 직전에 발생한 이벤트의 오브젝트 정보가 계속 남아서 보이는 경우가 있으므로 잘못 해석하지 않도록 주의해야 한다.
  

4. 성능분석 예시

(1) AWR 뷰를 이용해 하루 동안의 이벤트 발생현황을 조회해 본다.
(2) 특정 구간(08:15~09:15 )에서 enq: TM - contention 이벤트가 다량 발생한 것이 확인 되었다.
(2) dba_hist_active_sess_history를 조회해서 해당 이벤트를 많이 대기한 세션을 확인 한다.
(3) 블로킹 세션 정보를 통해 dba_hist_active_sess_history를 다시 조회한다.
(4) 블로킹 세션이 찾아지면 해당 세션이 그 시점에 어떤 작업을 수행 중이었는지 sql_id를 이용해 그 당시 SQL과 실행계획까지 확인 할 수 있다.(v$sql과 v$sql_plan까지 AWR에 저장되기 때문이다.)
(5) 해당 SQL문의 원인분석 후 해결책을 개발자 또는 개발팀 전체에 공지하여 문제를 해결토록 한다.