04 V$SYSSTAT

 

오라클은 성능 측정 지표로서 활용 가능한 항목들을 선정하고, SQL이 수행되는 동안 지속적으로 그 항목들에 대한 누적 통계치를 저장한다.

 

V$sysstat

         인스턴스 기동 후 현재까지 누적된 수행 통계치를 시스템 레벨로 확인하고자 할 때

 

V$ sesstat

         개별 세션별로 확인할 때

 

V$mystat

         현재 접속해 있는 본인 세션에 대한 수행통계

 

V$statname을 조회해 보면, 9i 기준 264개, 10g 기준 380개, 11g 기준 469개 측정 항목 확인

 

오라클 10g부터는 라이브러리 캐시에 캐싱돼 있는 SQL 커서에 대한 실행계획은 물론 Row Source별 수행통계까지 손쉽게 출력해 볼 수 있도록 기능이 확장되었다.

 

Autotrace의 statistics 옵션을 활성화시켰을 때 사용했던 통계 항목들을 시스템 레벨로 확인

 

SQL> select name,value from v$sysstat

where statistic# in (7,47,50,54,134,335,336,337,341,342);

 

NAME                                                             VALUE    

---------------------------------------------------------------- ---------

recursive calls                                                  505424851

db block gets                                                     7.8e+009

consistent gets                                                   3.2e+010

physical reads                                                    4.8e+009

redo size                                                         2.2e+012

workarea executions - multipass                                          0

parse time cpu                                                      311639

parse time elapsed                                                 1531008

frame signature mismatch                                                 0

execute count                                                    385642318

 

10 rows selected.

 

본서를 모두 읽고 나면 최소한 여기 나열된 항목들에 대해서는 정확한 의미를 파악할 수 있다.

 

 

(1) 시스템 수행 통계 수집 및 분석

 

V$sysstat이나 v$sesstat에 나타나는 값들은 인스턴스 기동 후 또는 세션 수립 후 현재까지 누적된 값이므로 그 값의 크고 작음만으로 의미 있는 정보를 얻기는 어렵다.

제대로 활용하는 방법은, 두 구간 사이의 변화량을 구해 SQL 수행 도중에 내부적으로 어떤 일들이 발생했는지를 판명하는 것이다.

 

 

< 작업 수행 도중 오라클 내부적으로 어떤 일들이 일어났는지 알아 내는 방법 >

 

1.     작업을 수행할 세션과는 별도의 세션에서 v$sesstat 정보를 저장

2.     작업 세션에서 SQL이나 일련의 배치 Job을 수행

3.     작업이 완료되면 별도의 세션에서 v$sesstat 정보를 저장

4.     수집된 수행통계를 쿼리해 두 구간 사이의 증분을 구해보면 작업 수행 도중 오라클 내부적으로 어떤 일들이 일어났는지를 알 수 있다.

 

시스템 레벨로도 v$sysstat 정보를 주기적으로 수집해 저정해 두면 구간 분석을 통해 시스템 전반의 시간대별 Load Profiling이 가능하다.

 

 

(2) Ratio 기반 성능 분석

 

수집된 수행 통계 자료를 이용해 DB의 전반적인 건강상태를 체크할 수 있는 의미 있는 Ratio 값들을 구할 수 있다.

 

자주 분석되는 항목 (주로 공유 리소스 사용빈도와 경합 발생 비율을 점검)

 

Buffer NoWait %

Redo NoWait %

Buffer Hit %

Latch Hit %

In-memory Sort %

Library Hit %

Soft Parse %

Execute to Parse %

Parse CPU to Parse Elapsd %

% Non-Parse CPU

Memory Usage %

% SQL with executions>1

% Memory for SQL w/exec>1

 

 

Buffer NoWait %          

버퍼블록을 읽으려 할 때, buffer busy waits대기 없이 곧바로 읽기에 성공한 비율

 

Redo NoWait %

Redo로그를 기록할 공간을 요청하지 않고 곧바로 Redo 엔트리를 기록한 비율

이 비율이 낮으면 로그 스위칭이 느리거나 너무 자주 발생함을 의미

 

Buffer Hit %     

디스크 읽기를 수반하지 않고 버퍼캐시에서 블록찾기에 성공한 비율

 

Latch Hit %      

래치 경합없이 첫번째 시도에서 곧바로 래치를 획득한 비율

Library Hit %    

라이브러리 캐시에 이미 적재된 SQL커서를 생행하거나 오브젝트정보를 읽으려할 때 커서 또는

오브젝트정보가 Heap영역에서 찾아진다면 Hit에 성공 비율

Get hit율과 Pin hit율로 나누어짐

Get hit율은 Parse 단계와 관련이 있으며 이 수치가 낮다면 하드파싱 또는 최초 로드가 발생한

경우임

 

Soft Parse %     

실행계획이 라이브러리 캐시에서 찾아져 하드파싱을 일으키지 않고 SQL을 수행한 비율

 

Execute to Parse %       

Parse Call없이 곧바로 SQL을 수행한 비율. 즉, 커서를 애플리케이션에서 캐싱한 채 반복 수행한

비율

n-Tier에서 이 값이 일반적으로 값이 낮게 나타남

 

Parse CPU to Parse Elapsd %      

파싱 총 소요 시간 중 CPU time이 차지한 비율. 파싱에 소요된 시간 중 실제 일을 수행한 시간

비율

이값이 낮으면 대기시간이 많았다는 의미로서 Shared Pool과 라이브러리 캐시 경합이 많았다는

것을 의미하며 대개 하드파싱 부하때문임

초당 하드파싱 횟수가 거의 나타나지 않는데 이 Ratio가 낮은 수치를 기록한다면 Parse Call 자체

가 많아 발생한는 경합임

 

% Non-Parse CPU         

SQL을 수행하면서 사용한 전체 CPU time중 파싱 이외의 작업이 차지한 비율. 이 비율이 낮으면

파싱에 소비되는 CPU Time이 많은거며, 파싱부하를 줄이도록 애플리케이션을 개선해야함

 

In-memory Sort %        

전체 소트 수행횟수에서 In-Memory방식으로 소트한 비율

 

Memory Usage %         

Shared Pool내에서 현재 사용중인 메모리 비중

 

% SQL with executions>1          

전체 SQL 개수에서 두번이상 수행된 SQL이 차지하는 비중. 이 비율이 낮으면 Literal 상수값을

이용하는 쿼리수행빈도가 높다는 것을 의미

 

% Memory for SQL w/exec>1      

전체 SQL이 차지하는 메모리 중 두번이상 수행된 SQL이 차지하는 메모리 비중. 이 비율이 낮으

면 Literal 상수값을 사용하는 쿼리에 의해 Shared Pool이 낭비되고 있음을 의미

 

 

지금까지 살펴본 Ratio 기반 성능진단 항목들은 DB 전반의 건강상태를 체크하기 위해 오랫동안 사용돼 온 것들이고 아직까지도 매우 유용한 지표로서 활용되고 있다.

 

다만, 이 값들은 문제가 발견되었을 때 그 원인을 분석하는 데에 취약하다는 단점이 있다.