ASH(Active Session History)

1. ASH 등장배경

2. ASH 특징

1. 특징
   1. 매초마다 active session을 샘플링하여 메모리에 가지고 있다가 MMON이 30분마다 AWR에 저장
   2. 최대 "10개"까지의 이력 정보만 보관. (cf. 11g의 최대값 : 100)
   3. 별도의 third party 모니터링 도구 없이 오라클 내에서 세션 레벨 실시간 모니터링 가능
      
        즉, SQL 구문의 지연 요인이 되는 실제 wait 이벤트를 확인하고, wait의 원인이 된 파일, 오브젝트, 오브젝트 블록 등 확인 가능
      • Direct Memory Access (DMA) 기능을 이용해 1초에 한번씩 ASH 데이터를 갱신
      • DMA : SQL 을 사용하지 않고, SGA 를 직접 접근하는 기법을 말하는 것으로 오라클 성능 모니터링 툴들에서 보편적으로 사용되는 기법
        
        
2. 장점
   1. 매우 짧은 시간 동안 순간적으로 발생한 문제를 분석하는데 유용
   2. SQL Trace 기능의 대안으로 사용 가능
   3. 상시 활성화되며 성능 오버헤드도 적음
   4. lock, long running transaction, 자원 의존도가 높은 프로세스, SQL 구문 등에 활용 가능
   5. 과거시점 조회 가능, 특정시간대의 발생한 장애 및 성능 저하 원인까지 분석 가능
        (AWR에 v$active_session_history 정보를 1/10만 샘플링해서 저장하므로 가능해짐)
   6. 문제가 되는 대기 이벤트는 일정간격을 두고 지속적으로 발생하므로 샘플링자료만으로 원인 분석 가능
   7. dba_hist_active_sess_history : v$active_session_history에서 정보가 조회 되지 않았을 경우, 이 view를 조회해서 정보 검색
      
      
3. 주의점
   1. ASH 버퍼를 읽는 session에 대해서는 latch요구 하지 않음 : 간헐적으로 일관성 없는 잘못된 정보 조회 가능성 있음
      • ASH 버퍼 : 초단위로 쓰기 발생하므로 latch 사용한다면 경합 발생 가능성이 있음
   2. CURRENT_OBJ# value : wait class에서 "Application, Concurrency, Cluster, User I/O"의 대기 이벤트가 발생한 session에서만 의미 있음
      
      
4. AWR vs ASH

3. ASH 동작

1. 동작 시점
   1. SGA shared pool 에서 CPU당 2MB의 버퍼를 할당 받아 세션 정보를 기록
   2. 활동중인 active 세션 정보를 1초에 한번씩 샘플링해서 ash버퍼에 저장
   3. 30분, 1시간 혹은 버퍼의 2/3가 찰 때마다 디스크(AWR)로 기록
      
      
2. _session_wait_history
   1. Oracle 10g N.F : Active Session History와 함께 Wait History의 개념 등장
   2. v$session_wait_history 뷰를 통해서 Wait Event의 이력을 조회하는 기능
   3. Session이 대기하는 Wait Event를 즉석에서 간편하게 조회 가능
   4. _session_wait_history의 값에 의해 v$session_wait_history에 저장하는 history 길이 결정됨
   5. _session_wait_history 값의 변경 : system level만 가능 (session level 불가)
   6. _session_wait_history 조회

select a.ksppinm,b.ksppstvl from x$ksppi a,x$ksppsv b
      where a.indx=b.indx and substr(a.ksppinm,1,1) = '_' 
and a.ksppinm like '%_session_wait%'
      order by ksppinm;

1. 1. _session_wait_history 변경 : instance 재시작 필요

alter system set "_session_wait_history"=5 scope=spfile;

1. 1. v$session_wait_history 의 이력 조회 : 1 session당 10개의 이력만 조회됨(10g)

select * from v$session_wait_history order by SID;

1. v$active_session_history : ASH 버퍼에 저장된 세션 히스토리 정보 조회
   1. 블로킹 세션 : 현재 lock을 발생시킨 세션 확인 가능
   2. BLOCKING_SESSION_STATUS : Valid, No Holder, Global, Not In Wait, Unknown
   3. 현재 액세스 중인 오브젝트
   4. SQL_ID : 대기 이벤트를 발생시킨 SQL 구문의 ID
   5. Client_id : 웹 어플리케이션과 같은 공유 사용자 환경에서 클라이언트 확인 가능
   6. null value for sql_id : session이 active (on CPU or waiting for a non-idle event) 상태이나 SQL문이 수행이 되는 상태는 아님(??)
   7. SESSION_STATE : wating - 대기 중 / on cpu - 서비스 중
   8. Wait_Time : 해당Wait Event에 대한 Session의 대기시간을 저장
      • Wait_Time = 0 : 대기정보를 수집하는 시점에 해당 대기가 끝나기를 기다림
      • Wait_Time > 0 : 최종대기시간
   9. TIME_WAITED : SESSION_STATE = WAITING일 경우 실제 Waiting 시간
   10. FORCE_MATCHING_SIGNATURE : CURSOR_SHARING = FORCE 일 때 사용됨
   11. QC_SESSION_ID, QC_INSTANCE_ID : Parallel Query의 Coordinator 정보
       
       
       {info:title=Wait Event}
         1. 정의 : CPU를 사용하지 않는 세션은 지원이 사용 가능한 상태로 되거나 어떤 작업이 완료되기를 대기하고 있는데, 이러한 대기와 관련된 이벤트
         2. 특징
           1) 세션이 대기할 때 마다 대기시간(wait time) 증가
           2) Oracle 버전이 올라갈수록 wait 수 빠르게 증가 : 대기 이벤트가 세분화되어 상세한 문제 파악 및 좀더 편리하게 성능 분석과 진단 수행 가능
       {info}

4. 참고 문서

1. 서적(오라클 성능 고도화 원리와해법 I)
2. http://www.oracle.com/technology/global/kr/pub/articles/schumacher_analysis.html
3. http://ukja.tistory.com/97
4. http://kr.forums.oracle.com/forums/thread.jspa?threadID=856003
5. http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_1007.htm#REFRN30299