Statspack(8i) / AWR(10g)
- 표준화된 방식으로 성능관리를 지원하려고 오라클이 제공하는 패키지이다.
- Ratio 기반 성능진단과 Wait Event기반 성능진단 방법론을 모두 지원한다.
(1) 동적 성능 뷰
- 동적 성능 뷰를 주기적으로 특정 Repository에 저장한다.
- 이를 분석해 오라클 데이터베이스 전반의 건강 상태를 체크하고 병목원인과 튜닝 대상을 식별 하는데 사용한다.
동적 성능 뷰의 종류
v$segstat,v$undostat,v$latch,v$latch_children,v$sgastat,v$pgastat,v$sysstat,v$system_event,v$waitstat,v$sql,v$sql_plan,v$splstats(10g이후) ,v$active_session_history(10g 이후) ,v$osstat(10g 이후)
(2) Statspack / AWR 정보 수집 방법
1. Statspack의 정보 수집 방법 : SQL을 이용한 딕셔너리 조회 방식을 사용한다.
2. ⭐️ AWR의 정보 수집 방법 ⭐️
- DMA(Direct Memory Access)방식으로 SGA를 직접 액세스한다.
- AWR이 부하가 적기 때문에 AWR은 Statspack보다 더 많은 정보를 수집하고 제공한다.
(3) Statspack / AWR 기본 사용법
1. 리포트 경로
- Statspack : @$ORACLE_HOME/rdbms/admin/spreport
- AWR : @$ORACLE_HOME/rdbms/admin/awrrpt
2. 사용 방법
- 성능 진단 보고서를 출력할 때는 측정 구간, 즉 시작 스냅샷 ID와 종료 스냅샷 ID를 어떻게 입력하느냐가 가장 중요하다.
- 매일 시스템의 Load Profile 비교하는 목적이라면 하루 업무 시간을 기준으로 추출한다.
- 문제점을 찾아 성능 이슈를 해결할 목적이라면 peak 시간대 또는 장애가 발생한 시점을 전후해 가능한 한 짧은 구간을 선택한다.
- OS모니터링 도구를 이용해 CPU, 메모리, I/O사용량을 정보를 먼저 수집하고 이를 통해 peak 시간대를 파악한다.
(4) 요약보고서 해석 : Load Profile
==============================================================================
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 0.0 0.0 0.00 0.00
DB CPU(s): 0.0 0.0 0.00 0.00
Redo size: 4,316.6 13,706.9
Logical reads: 252.4 801.4
Block changes: 27.9 88.5
Physical reads: 0.5 1.7
Physical writes: 0.4 1.2
User calls: 2.5 8.1
Parses: 7.0 22.3
Hard parses: 0.5 1.5
W/A MB processed: 0.1 0.2
Logons: 0.1 0.3
Executes: 26.9 85.4
Rollbacks: 0.0 0.0
Transactions: 0.3
==============================================================================Per Second- 각 측정 지표 값을 측정 시간(Snapshot Interval, 초)으로 나눈 것으로 초당 부하 발생량을 의미한다.
Per Transaction- 각 측정 지표 값들을 트랜잭션 개수로 나눈 것이다.
- 이 때 트랜잭션 개수는 commit 또는 rollback 수행 횟수를 단순히 더한 값이다.
(5) 인스턴스 효율성
===================================================================
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.79 In-memory Sort %: 100.00
Library Hit %: 96.27 Soft Parse %: 93.51
Execute to Parse %: 73.91 Latch Hit %: 99.95
Parse CPU to Parse Elapsd %: 104.10 % Non-Parse CPU: 96.51
===================================================================v$sysstat항목과 동일하다.- Ratio 기반 분석항목들은
Execute to Parse %항목을 제외하면 모두 100%에 가까운 수치를 보여야 정상이다.
(6) Shared Pool 사용통계
=============================================
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 62.73 74.90
% SQL with executions>1: 91.42 64.29
% Memory for SQL w/exec>1: 90.66 67.30
=============================================- AWR 리포트 구간 시작 시점의 Shared Pool 메모리 상황과 종료 시점에서의 메모리 상황을 알 수 있다.
(7) Top 5 Timed Events
=================================================================================
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 36 102.2
control file sequential read 1,624 0 0 .9 System I/O
db file sequential read 1,382 0 0 .6 User I/O
log file sync 314 0 0 .3 Commit
SQL*Net break/reset to client 240 0 0 .1 Applicatio
=================================================================================- AWR 리포트 구간 동안 누적 대기 시간이 가장 컸던 대기 이벤트 5개를 알 수 있다.
(8) 이벤트 기반 분석과 Ratio 기반 분석의 문제점
- peak time 전후로 리포트 구간을 짧게 설정해 분석하더라도 시스템 레벨로 측정한 값이기 때문에 대기 이벤트 발생 현황(또는 Ratio)만을 놓고 보면 별 문제가 없어 보이지만 실제 사용자가 느끼는 성능은 매우 느린 경우가 많다.
- 분석한 결과를 바탕으로 실제 성능 문제를 해결할 수 있으려면 세션 레벨의 상세한 분석이 추가로 이루어져야 한다.
도광양회(韜光養晦) ‘빛을 감추고 어둠속에서 힘을 기른다’