대기 이벤트와 래치 경합
프로세스가 공유 메모리(SGA)의 버퍼 캐시(Buffer Cache), 라이브러리 캐시(Library Cache) 등에서 정보를 읽으려면 래치(Latch) 를 반드시 획득해야 한다.
- 래치를 획득하는 과정에서 경합(Contension) 이 발생하면 대기 이벤트(Wait Event) 가 나타난다.
- 반대로, 래치 없이(또는 즉시 획득하여) 바로 읽을 수 있으면 대기 이벤트가 나타나지 않는다.
대기 이벤트는 프로세스가 작업을 진행하기 위해 CPU를 OS에 반환하고 Sleep 상태로 진입한 원인을 기록하기 위해 개발되었다.
프로세스가 cpu 를 os 에 반환하고 Sleep 상태로 들어가는 대표적인 원인 / 대기 이벤트가 나타나는 대표적인 예는 다음과 같다.
프로세스 SLEEP 이 발생했을 때 대기 이벤트가 기록되므로, 둘의 발생원인은 사실상 대응관계
| 프로세스 SLEEP | 대기 이벤트 | |
|---|---|---|
| CPU 를 OS에 반납 | 그 원인을 기록하기 위함 | |
| 원인1 | 필요한 특정 리소스를 다른 프로세스가 사용 중이어서, 요청 후 작업이 끝나기를 기다리는 경우 | SGA 공유 메모리에서 특정 자원을 액세스 하려고 래치를 획득하는 과정에 다른 프로세스와 경합이 발생하거나 |
| 원인2 | 다른 프로세스에게 작업을 요청하고 해당 작업이 완료되기를 기다릴 때 | 디스크로부터 블록 I/O 를 요청하거나 |
| 원인3 | 프로세스가 할 일이 없을떄 | 클라이언트로부터 다음 작업 요청이 오기를 기다리는 경우 |
(풀이 17) shared pool, library cache 관련 대기 이벤트 Shared Pool에서 특정 오브젝트 정보 또는 SQL 커서를 위한 Free Chunk를 할당받으려면 shared pool latch(= shared pool 래치) 를 획득해야 한다. latch: shared pool 대기 이벤트는 이 shared pool 래치를 할당받는 과정에서 발생하는 경합과 관련 있으며, 하드 파싱(Hard Parse) 이 동시에 심하게 발생할 때 주로 나타난다.
또한,
library cache lock, library cache pin 대기 이벤트는 주로 SQL 수행 도중 DDL을 수행할 때 나타난다.
free buffer waits는 서버 프로세스가 버퍼 캐시에서 Free Buffer를 확보하지 못해 DBWR에게 공간 확보를 요청한 뒤 대기할 때 나타난다.
log file sync는 COMMIT을 전달받은 서버 프로세스가 LGWR에게 로그 버퍼를 Redo Log 파일에 기록해 달라고 요청한 뒤 대기할 때 나타난다.
(풀이 18) 대기 이벤트 기반 분석과 OWI, AWR 대기 이벤트를 기반으로 세션 또는 시스템 전체에서 발생하는 병목과 원인을 찾아 문제를 해결하는 방법론을 대기 이벤트(Wait Event) 기반 분석, 또는 응답 시간 분석(Response Time Analysis) 이라고 한다.
Ratio 기반 분석 방법론의 한계를 극복하기 위해 대기 이벤트 기반 분석이 대두되었다.
OWI(Oracle Wait Interface): Response Time Analysis 방법론을 지원하기 위해 오라클이 제공하는 기능/인터페이스의 통칭
AWR(Automatic Workload Repository): 성능 관련 데이터를 주기적으로 수집하여 Ratio 기반 분석과 대기 이벤트 기반 분석을 모두 지원하는 오라클 성능관리 표준 도구
(정답 19) Response Time Analysis의 응답 시간 정의 Response Time Analysis 성능관리 방법론은 병목 현상과 그 원인을 찾아 해결하는 과정 전반을 다루며, DB 서버의 응답 시간을 아래처럼 정의한다.
Response Time = Service Time + Wait Time
= CPU Time + Queue Time
여기서,
Service Time(CPU time): 프로세스가 정상적으로 동작하며 실제 일을 수행한 시간
Wait Time(Queue time): CPU를 OS에 반환하고 Sleep 상태로 대기한 시간
정답: 19
(풀이 20) AWR의 특징(요지) AWR은 일정 주기로 성능 정보를 수집해 저장하고, 이를 통해 하루/주 단위 등으로 시간대별 성능 저하(피크 구간) 를 파악하는 데 유용하다. 수집된 데이터는 dba_hist_ 계열 뷰 등을 통해 조회할 수 있다.
(중간에 섞인 문장들은 “AWR은 SGA 직접 조회보다 빠르게 수집/표준 보고서를 제공한다”는 취지로 복구됨)
(풀이 21) AWR 보고서 요약(Report Summary)에 포함되는 대표 항목 버전마다 조금씩 다르지만, AWR 보고서 앞부분의 Report Summary에는 보통 다음이 포함된다.
Cache Sizes(캐시 크기)
Load Profile(부하 프로파일)
Instance Efficiency(인스턴스 효율성)
Top Wait Events(최상위 대기 이벤트)
I/O Profile / I/O 통계
SQL 통계(Top SQL 등)
(풀이 22) Soft Parse %, Execute to Parse %, CPU to Parse Elapsed % Soft Parse %: 실행계획을 라이브러리 캐시에서 찾아 하드 파싱 없이 SQL을 수행한 비율
공식: (전체 Parse Call 횟수 − 하드 파싱 횟수) / 전체 Parse Call 횟수 × 100
Execute to Parse %: Parse Call 없이 곧바로 SQL을 수행한 비율
애플리케이션에서 커서를 캐싱하여 Execute만 반복 수행하는 비율을 의미
CPU to Parse Elapsed %: Parse 총 소요시간 중 CPU time이 차지한 비율
값이 낮다면 Parse 과정에서 대기가 많이 발생했음을 의미
정답: 23 (문맥상 해당 문제 번호의 정답 표시가 “23”으로 붙어 있음)
(풀이 23) 세션 레벨 분석과 ASH 도입 배경 시스템에 문제가 생겼을 때 원인(어떤 프로그램/어떤 세션/어떤 SQL)을 빠르게 특정하려면 세션 레벨 성능 분석이 필요하다.
동적 뷰만으로는 한계가 있고,
SQL Trace는 상세하지만 시스템 부하가 크며 파일 단위로 수집되어 통계적 접근이 어렵고, 수동 활성화가 필요해 “문제가 지나간 뒤”가 되는 경우가 많다.
이를 해소하기 위해 오라클 10g에서 ASH(Active Session History) 기능을 도입했다.
활동 중인 Active 세션 정보를 1초에 한 번 샘플링해서 SGA의 ASH 버퍼에 저장
버퍼가 차거나 일정 시간이 지나면 디스크에 기록되어 AWR로 이동
조회 뷰:
v$active_session_history : 메모리(ASH 버퍼)에 있는 비교적 최근 이력
dba_hist_active_sess_history : AWR로 이동한 더 과거 이력
ASH를 이용하면 현재뿐 아니라 과거 시점의 장애/성능 저하를 세션 레벨로 분석할 수 있다.