메뉴 건너뛰기

bysql.net

8. Statspack / AWR

2010.06.13 18:26

balto 조회 수:12766

▣ 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 기능으로 보완하여 분석한다.

이 게시물을
목록
목록
쓰기
태그