o. Ratio 기반 분석 방법론의 한계점

시스템에 문제점이 있는 것으로 진단되었을 때 그 원인을 찾아 실제 문제를 해결하는게 까지 많은 시간이 소요된다.

대기 이벤트 기반 분석 방법론 또한 마찬가지다.

o. SQL Trace에게 부족한 점

가장 상세한 세션 레벨 분석이 가능하지만 시스템에 큰 부하를 주며 파일 단위로 정보가 수집되어 통계적 접근이 어렵다.

또한 수동 설정이기 때문에 이미 문제가 종료된 후에 시작하는 경우가 많다.

o. ASH의 탄생

오라클 내에서 세션 레벨 실시간 모니터링을 가능케 하는 강력한 기능

OWI의 활용성을 극대화시켜준다.

그림 1

Active 세션 정보를 1초에 한번씩 샘플링하여 ASH버퍼에 저장한다.

SGA Shared Pool에서 CPU당 2MB의 버퍼를 할당받아 세션 정보를 기록하며

1시간 또는 버퍼의 2/3가 채워질때마다 디스크로 기록한다. (AWR에 저장)

o. v$active_session_history

ASH버퍼에 저장된 세션 히스토리 정보를 조회할 수 있다.

그림 2

이 뷰를 통해 대기 이벤트, 블로킹 세션, 현재 엑세스 중인 오브젝트 정보 등을 확인할 수 있다.

블로킹 세션을 확인하여 현재 lock을 발생시킨 세션을 찾아 빨리 해소시킬 수 있다.

o. 오브젝트 정보 해석 시 유의할 점

현재 발생 중인 대기 이벤트의 Wait Class가 Application, Concurrency, Cluster, User I/O 일때만 의미가 있다.

Configuration으로 인한 대기 이벤트는 v$active_session_history로 조회가 되지만 함께 출력되는 오브젝트에

Lock이 걸렸다고 판단해서는 안된다. (그런 경우 오브젝트 번호가 -1로 출력되며 간혹 직전에 발생한 오브젝트 정보가

조회되는 경우도 있으므로 주의해야 한다.)

그림 3

초 단위로 쓰기가 발생하는 ASH버퍼를 읽을때,

래치를 사용한다면 경합이 생길 수 있기 때문에 오라클은 ASH 버퍼를 읽는 세션에 대해서 래치를 사용하지 않는다.

그로 인해 간혹 일관성 없는 잘못된 정보가 나타날 수 있다.

o. ASH 기능

현재 뿐 아니라 과거 시점에 발생한 장애 및 성능 저하 원인까지 세션 레벨로 분석이 가능하다.

Statspack은 이미 문제의 세션이 종료된 후에야 보고서를 생성 및 분석이 가능했다. 

v$active_session_history 정보를 AWR에 저장하므로 과거치에 대한 세션 레벨 분석이 가능해졌고 1/10 샘플링 저장한다.

(이것은 SGA를 DMA방식으로 엑세스 하기 때문에 가능해진 일이라고 본다.)

문제가 되는 대기 이벤트는 일정 간격을 두고 지속적으로 발생하기 때문에 샘플링 정보로도 충분히 분석이 가능하다.

만약, v$active_session_history로 정보가 찾아지지 않는다면

이미 AWR에 저장된 것이므로 dba_hist_active_sess_history를 조회하면된다.

o. ASH와 AWR을 활요한 분석 예시

그림 4

(1) dba_hist_system_event 결과, 08:15~09:15 사이세 enq: TM-contention 이 다량 발생하였다.

(2) dba_hist_active_sess_history에서 해당 이벤트를 많이 대기한 세션을 확인한다.

(3) 블로킹 세션 정보를 통해 dba_hist_active_sess_history를 다시 확인한다.

해당 세션이 그 시점에 어떤 작업을 수행중이었는지 확인하고 sql_id를 통해 당시 SQL과 실행계획까지 확인가능하다.

위 예시에서는 블로킹 세션이 Append Mode Insert를 수행하면서 Exclusive mode TM lock에 의한 경합이 발생하고 있다.

(4) 어플리케이션 정보를 이용해 관련 프로그램을 찾아 Append 힌트를 제거한다.