8. Statspack / AWR
2010.06.13 18:26
▣ Statspack/AWR
- Statspack - 8i부터 사용, AWR - 10g 이후 사용
- Ratio 기반과 Wait Event 기반 성능진단 방법 모두 가능
- 동적성능 뷰(Dynamic Performance View)
v$segstat | statistics on shared SQL area. |
v$undostat | aggregate latch statistics for both parent and child latches |
v$latch | aggregate latch statistics for both parent and child latches |
v$latch_children | statistics about child latches. |
v$sgastat | detailed information on the system global area (SGA). |
v$pgastat | PGA memory usage statistics |
v$sysstat | lists system statistics |
v$system_events | information on total waits for an event. |
v$wait_stat | lists block contention statistics |
v$sql | statistics on shared SQL area. |
v$sql_plan | the execution plan information |
v$sql_stats | basic performance statistics for SQL cursors |
v$active_session_history | displays sampled session activity in the database |
v$osstat | displays system utilization statistics from the operating system |
- Statspack과 AWR은 거의 같은 내용이지만 정보 수집 방식에 차이가 있음
- Statspack은 SQL을 이용한 딕셔너리 조회 방식, AWR은 DMA 방식으로 SGA를 직접 접근하므로 더 많은 정보를 수집
- Statspack은 9i에서는 부하때문에 수동으로 수집하나 10g부터는 자동으로 수집(DB 속에 내장된 Datawarehouse, 1시간 주기로 1주일 보관)
▣ Statspack/AWR 기본 사용법
- Statspack은 PERFSTAT 계정에 stats$ 이름의 뷰로 성능 정보를 조회
- @?/rdbms/admin/awrrpt 스크립트 사용 : 표준화된 보고서
- @?/rdbms/admin/spreport 스크립트 사용 : Statspack 이용
- 정해진 기간동안 각 구간별로 SQL 수행횟수(execute count)
select to_char(min(s.begin_interval_time), 'hh24:mi') begin
, to_char(min(s.end_interval_time), 'hh24:mi') end
, sum(b.value-a.value) "execute count"
from dba_hist_sysstat a, dba_hist_sysstat b, dba_hist_snapshot s
where s.instance_number = &instance_number
and s.snap_id between &begin_snap and &end_snap
and a.stat_name = 'execute count'
and b.stat_id = a.stat_id
and b.snap_id = s.snap_id
and a.snap_id = b.snap_id - 1
and a.instance_number = s.instance_number
and b.instance_number = s.instance_number
group by s.snap_id
order by s.snap_id
▣ Statspack/AWR 리포트 분석
- 10g AWR의 경우 보고서 길이가 80 페이지 분량이지만 필요한 부분만 분석한다.
- (분석 사례)
Load Profile ~~~~~~~~~~~~ Per Second Per Transaction --------------- --------------- Redo size: 884.68 5,704.03 Logical reads: 30.62 197.41 Block changes: 4.50 29.02 Physical reads: 0.14 0.91 Physical writes: 0.46 2.95 User calls: 1.16 7.48 Parses: 1.57 10.12 Hard parses: 0.12 0.80 Sorts: 0.89 5.72 Logons: 0.04 0.23 Executes: 4.19 27.04 Transactions: 0.16 |
- per second = 초당 부하 발생량
- per transaction = 지표값 / transaction
- dba_hist_sysstat 뷰에서 얻은 결과로 v$sysstat에서도 구할 수 있음
- (v$sysstat 테이블에서 다음 질의의 결과들 임)
select value rsiz from v$sysstat where name='redo size';
select value rsiz from v$sysstat where name='session logical reads';
...(생략)
% Blocks changed per Read: 14.70 Recursive Call %: 94.71 Rollback per transaction %: 0.00 Rows per Sort: 8.81 |
- % Blocks changed per Read : 읽은 블록중 갱신이 발생하는 비중
- Rollback per transaction % : 최종적으로 커밋되지 못하고 롤백된 트랜잭션 비중
- Recursive Call % : 전체 Call 중 Recursive Call이 차지하는 비중, 사용자정의함수/프로시저를 사용하면 수치가 높아지며 하드파싱에 의해서도 영향 받음
- Rows per Sort : 소트 수행시 평균 몇 건씩 처리했는지 나타냄
Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 100.00 Redo NoWait %: 100.00 Buffer Hit %: 99.54 In-memory Sort %: 100.00 Library Hit %: 96.56 Soft Parse %: 92.04 Execute to Parse %: 62.58 Latch Hit %: 99.98 Parse CPU to Parse Elapsd %: 36.25 % Non-Parse CPU: 86.45 |
- Execute to parse % 항목을 제외하면 모두 100%에 가까움
- Parse CPU to Parse Elapsed가 낮은 값은 Active 프로세스가 동시 폭주하여 과도한 Parse Call 발생
Shared Pool Statistics Begin End ------ ------ Memory Usage %: 43.21 44.52 % SQL with executions>1: 78.09 91.36 % Memory for SQL w/exec>1: 89.58 86.09 |
- AWR 리포트 구간 시자과 끝지점의 메모리 상황
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- CPU time 2 13.6 control file parallel write 606 1 2 8.5 System I/O db file sequential read 224 1 5 7.3 User I/O db file parallel write 592 1 2 6.5 System I/O control file sequential read 751 1 1 3.7 System I/O ------------------------------------------------------------- |
- AWR 리포트 구간 중 누적 대기 시간이 가장 컷던 대기 이벤트 5개
- CPU time은 대기 이벤트가 아니지만 가장 오래 대기를 발생시켰던 이벤트와 점유율 비교를 위하여 표시
- CPU time이 가장 비중이 높으면 DB가 양호한 상태
- latch나 lock이 높으면 이상신호이지만 latch의 경우는 CPU 사용률이 높으면 같이 높아도양호
- 트랜잭션 위주 시스템의 경우는 log file sync 대기 이벤트가 top 5에 있으면 이상 아닐수도 있음
- I/O 관련 이벤트인 db file sequential read, db file scattered read 대기 이벤트가 상위에 있으면 정상일 수 있음, cpu 사용율도 같이 높다면 I/O 튜닝 필요
- 대기 이벤트 상황이 문제가 없어도 성능이 느린 경우가 있을 수 있는데 이경우는 peak time 전후로 시스템 레벨로 구간을 측정하기 때문일 수 있다. 상세한 분석이 필요하며 ASH 기능으로 보완하여 분석한다.
댓글 0
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 67 |
Front Page
 | 운영자 | 2010.05.17 | 154864 |
| 66 |
4. Prefetch
| balto | 2010.07.10 | 28432 |
| 65 |
5. 오라클 Lock
| 휘휘 | 2010.06.07 | 26365 |
| 64 |
2. DB 버퍼 캐시
| 휘휘 | 2010.05.24 | 21916 |
| 63 |
3. SQL 트레이스
| balto | 2010.06.06 | 21175 |
| 62 |
1. 기본 아키텍처
[1] | 휘휘 | 2010.05.23 | 19898 |
| 61 |
2. 트랜잭션 수준 읽기 일관성
| 휘휘 | 2010.06.07 | 19566 |
| 60 |
5. Undo
| 토시리 | 2010.05.31 | 18648 |
| 59 |
11. Shared Pool
| 실천하자 | 2010.05.31 | 18510 |
| 58 | 9. Static vs. Dynamic SQL [1] | balto | 2010.07.04 | 18342 |
| 57 |
4. Array Processing 활용
| 휘휘 | 2010.07.05 | 18238 |
| 56 | 1 장. 오라클 아키텍처 | 운영자 | 2010.05.20 | 17840 |
| 55 |
5. Fetch Call 최소화
| 휘휘 | 2010.07.05 | 16839 |
| 54 | 9. ASH(Active Session History) | 실천하자 | 2010.06.14 | 15604 |
| 53 |
2. SQL 처리과정
| 휘휘 | 2010.06.28 | 15338 |
| 52 | 3. 버퍼 Lock [1] | 휘휘 | 2010.05.24 | 15225 |
| 51 | 1. Explain Plan | 실천하자 | 2010.06.06 | 14662 |
| 50 |
6. 바인드 변수의 부작용과 해법
| 실천하자 | 2010.06.28 | 14658 |
| 49 | 8. PL/SQL 함수 호출 부하 해소 방안 | 토시리 | 2010.07.11 | 14022 |
| 48 | 7. Result 캐시 | 휘휘 | 2010.07.19 | 12969 |