AWR 스냅샷

한 구간의 성능 문제를
세 단계로 좁힌다

섹션을 따로 암기하기보다, 같은 스냅샷 구간을 어떤 초점으로 읽는지 이해하는 것이 핵심입니다.

같은 구간을 보는 서로 다른 질문

전체가 바빴는가?에서 시작해 어디서 기다렸는가?를 찾고, 마지막에 어떤 SQL이 그 부하를 만들었는가?로 내려갑니다.

1 기준선

전체 부하를 먼저 본다

스냅샷 구간이 평소보다 얼마나 바빴는지 확인해야, 이후의 대기 이벤트와 SQL 통계를 과하게 해석하지 않게 됩니다.

Load Profile Instance Activity Stats

DB Time, 논리적/물리적 읽기, 트랜잭션 활동량으로 그 구간의 전체 압력을 잡습니다.

2 병목

느린 이유는 단순히 “느리다”가 아니라 어떤 종류의 대기였는지로 나뉩니다. 이 단계에서 병목의 성격을 정합니다.

Top 5 Timed Events

I/O, 락, 커밋 대기 같은 병목 원인을 구분해야 원인 SQL을 올바르게 좁힐 수 있습니다.

3 개선 대상

같은 “나쁜 SQL”이라도 오래 걸린 SQL, 읽기가 많은 SQL, 너무 자주 실행된 SQL은 개선 방향이 서로 다릅니다.

Elapsed Time Gets Executions

대기 원인을 만든 SQL을 고르는 단계입니다. 그래서 AWR 읽기는 항상 전체 부하에서 시작해 SQL로 내려옵니다.

핵심: AWR는 숫자 목록이 아니라, 하나의 스냅샷 구간을 전체 현황 → 병목 원인 → 원인 SQL로 좁혀 가는 구조의 보고서입니다.