ASH(Active Session Histroy)
(1) ASH 등장 배경
이벤트 기반 분석과 Ratio 기반 분석의 문제점
- 시스템에 문제가 있는 것으로 진단되었을 때 그 원인을 찾아 실제 문제를 해결하는 데까지 많은 시간이 소모된다.
- 문제의 원인을 금방 알 수는 있지만, 실제 문제가 된 프로그램 또는 세션을 확인하는 별도의 작업이 필요
따라서 이러한 문제점을 보완하기 위한 기능이 바로 ASH이다.
(2) ASH 동작
- ASH는 Third Party 모니터링 도구 없이 오라클 내에서 세션 레벨로 실시간 모니터링한다.
- 오라클은 현재 접속해서 활동 중인 Active 세션 정보를 1초에 한번씩 샘플링해서 ASH 버퍼에 저장한다.
1. ASH buffer 확인
SQL> select * from v$sgastat where name = 'ASH buffers';
===================================================
POOL NAME BYTES
------------ -------------------------- ----------
shared pool ASH buffers 8388608
===================================================2. ASH 버퍼에 저장된 세션 히스토리 정보
select
sample_id, sample_time --① 샘플링이 일어난 시간과 샘플 ID
, session_id, session_serial#, user_id, xid --② 세션정보, User명, 트랜잭션ID
, sql_id, sql_child_number, sql_plan_hash_value --③ 수행 중 SQL 정보
, session_state --④ 현재 세션의 상태 정보. 'ON CPU' 또는 'WAITING'
, qc_instance_id, gc_session_id --⑤ 병렬 Slave 세션일 때, 쿼리 코디네이터(QC) 정보를 찾을 수 있게 함
, blocking_session, blocking_session_serial#, blocking_session_status --⑥ 현재 세션의 진행을 막고 있는(=블로킹) 세션 정보
, event, event#, seq#, wait_class, wait_time, time_waited --⑦ 현재 발생 중인 대기 이벤트 정보
, p1text, p1, p2text, p2, p3text, p3 --⑧ 현재 발생 중인 대기 이벤트의 파라미터 정보
, current_obj#, current_file#, current_block# --⑨ 해당 세션이 현재 참조하고 있는 오브젝트 정보 / V$session 뷰에 있는 row_wait_obj#, row_wait_file#, row_wait_block# 컬럼을 가져온 것
, program, module, action, client_id --⑩ 애플리케이션 정보
from V$ACTIVE_SESSION_HISTORY;(3) ASH 예시
[예시1]
- 현재 발생 중인 대기 이벤트의 Wait Class가 Application, Concurrency, Cluster, User I/O 일 때만 의미 있는 값이다.
- 예제처럼 직전에 발생한 이벤트(enq:TX - allocate ITL entry)의 오브젝트 정보가 계속 남아서 보이는 경우가 있다.
column current_obj# format 99999 heading 'CUR_OBJ#'
column current_file# format 999 heading 'CUR_FIL#'
column current_block# format 999 heading 'CUR_BLK#'
select to_char(sample_time, 'hh24:mi:ss') sample_tm, session_state
, event, wait_class, current_obj#, current_file#, current_block#
from v$active_session_history
where session_id = 143 and session_serial# = 9;
order by sample_time;========================================================================================
SAMPLE_T SESSION EVENT WAIT_CLASS CUR_OBJ# EUR_FIL# CUR_CLK#
-------- ------- ----------------------------- ------------- -------- -------- --------
15:00:44 WATING enq: TX - row lock contention Application 55765 4 476
15:00:45 WATING enq: TX - row lock contention Application 55765 4 476
15:00:46 WATING enq: TX - row lock contention Application 55765 4 476
15:00:47 WATING enq: TX - row lock contention Application 55765 4 476
15:01:36 WATING enq: TX - allocate ITL entry Conficuration -1 4 476
15:01:37 WATING enq: TX - allocate ITL entry Conficuration -1 4 476
15:01:38 WATING enq: TX - allocate ITL entry Conficuration -1 4 476
15:01:39 WATING enq: TX - allocate ITL entry Conficuration -1 4
========================================================================================[예시2] AWR과 ASH를 활용한 분석 예제 (오라클 10g부터)
v$active_session_history정보를 AWR 내에 보관하므로 과거치에 대한 세션 레벨 분석이 가능하다.(1/10만 샘플링해서 저장)
[AWR과 ASH를 활용한 분석 예제]
- AWR 뷰를 이용해 하루 동안의 이벤트 발생현황을 조회하여 08:15~09:15 구간에서 enq: TM - contention 이벤트가 다량 발생했음을 확인한다.
dba_hist_active_sess_history를 조회해서 해당 이벤트를 많이 대기한 세션을 확인한다.- 블로킹 세션 정보를 통해
dba_hist_active_sess_history를 다시 조회한다. - 블로킹 세션이 찾아지면 해당 세션이 그 시점에 어떤 작업을 수행 중이었는지 확인한다.
- sql_id를 이용해 그 당시 SQL과 실행계획까지 AWR에서 확인한다.
- bloking 세션이 Append Mode Insert를 수행하면서 Exclusive 모드 TM Lock에 의한 경합이 발생했었음을 알 수 있다.
- program, module, action, client_id 등 애플리케이션 정보를 이용해 관련 프로그램을 찾아 Append 힌트를 제거한다.
- 다른 트랜잭션과 동시 DML이 발생할 수 있는 상황에서는 insert문에 Append 힌트를 사용해서는 안 된다는 사실을 개발팀 전체에 공지한다.
도광양회(韜光養晦) ‘빛을 감추고 어둠속에서 힘을 기른다’