by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

V$SYSSTAT




V$SYSSTAT

  • 오라클은 성능측정지표로서 활용 가능한 항목들을 선정하고, SQL이 수행되는 동안 지속적으로 그 항목들에 대한 누적통계치를 저장한다.
    인스턴스가 구동된 후부터 현재까지 누적된 수행통계치를 시스템 레벨로 확인하고자 확인할때 사용하는 뷰가 V$SYSSTAT이다.
    (개별 세션별로 확인할 때는 V$SESSTAT, 본인 세션에 대한 수행통계는 V$MYSTAT를 보면된다.)
  • AutoTrace의 Statics옵션을 활성화시켰을 때, 별도 세션을 띄워, v$sesstat를 조회하는 것을 보여주었는데, 이를 시스템레벨로 확인하려면 아래와 같다.
SQL> select name, value
  2  from v$sysstat
  3  where statistic#
  4  in (7, 47, 50, 54, 134, 343, 344, 345, 349, 350);

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
recursive calls                                                      214215
db block gets                                                        160025
consistent gets                                                       92662
physical reads                                                        10629
redo size                                                          18591264
bytes sent via SQL*Net to client                                      55306
bytes received via SQL*Net from client                                24912
SQL*Net roundtrips to/from client                                       137
sorts (memory)                                                         6293
sorts (disk)                                                              0

10 개의 행이 선택되었습니다.


Statistics
----------------------------------------------------------
          8  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
        799  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         10  rows processed

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

v$sysstat나 v$sesstat에 보여지는 값들은 인스턴스 기동 후 또는 세션수립 후 현재까지 누적된 값이므로, 해당 값만으로는 별 의미가 없다.
이를 제대로 활용하는 방법은, SQL수행 전후, 두 구간 사이의 변화량을 구하서 판단하는 것이다.

  • 그럼 변화량은 어찌 구합니까?
  1. (세션1) 특정 Job을 수행할 세션을 열고, 해당 세션 ID를 기억한다.
  2. (세션2)별도 세션을 열어서, 특정 Job 수행전 후의 통계치를 저장할 테이블을 한 개 만든다. 그리고 통계치를 일단 저장-수행전
  3. (세션1)특정 Job을 마구마구 실행
  4. (세션2)다시 통계치 저장-수행후
  5. 저장한 통계를 쿼리해서 두 구간사이의 변화량을 체크하여 분석!!!
(2) Ratio 기반 성능 분석

이 뷰를 쿼리해서, DB의 성능을 체크할수 있는 의미있는 Ratio값들을 구할수 있다.
자주 분석되는 항목은 아래와 같다.
(비율이 높으면 좋은거! 낮으면 문제있는거!)

Buffer NoWait % 버퍼블록을 읽으려 할 때, buffer busy waits대기 없이 곧바로 읽기에 성공한 비율
Redo NoWait % Redo로그를 기록할 공간을 요청하지 않고 곧바로 Redo 엔트리를 기록한 비율
Buffer Hit % 디스크 읽기를 수반하지 않고 버퍼캐시에서 블록찾기에 성공한 비율
Latch Hit % 래치 경합없이 첫번째 시도에서 곧바로 래치를 획득한 비율
In-memory Sort % 전체 소트 수행횟수에서 In-Memory방식으로 소트한 비율
Library Hit % 라이브러리 캐시에 이미 적재된 SQL커서를 생행하거나 오브젝트정보를 읽으려할 때 커서 또는 오브젝트정보가 Heap영역에서 찾아진다면 Hit에 성공한건데, 이 Hit한 비율
Soft Parse % 실행계획이 라이브러리 캐시에서 찾아져 하드파싱을 일으키지 않고 SQL을 수행한 비율
Execute to Parse % Parse Call없이 곧바로 SQL을 수행한 비율. 즉, 커서를 애플리케이션에서 캐싱한 채 반복 수행한 비율
Parse CPU to Parse Elapsd % 파싱 총 소요 시간 중 CPU time이 차지한 비율. 파싱에 소요된 시간 중 실제 일을 수행한 시간비율. 이값이 낮으면 대기시간이 많았다는 뜻
% Non-Parse CPU SQL을 수행하면서 사용한 전체 CPU time중 파싱 이외의 작업이 차지한 비율. 이 비율이 낮으면 파싱에 소비되는 CPU Time이 많은거며, 파싱부하를 줄이도록 애플리케이션을 개선해야함
Memory Usage % Shared Pool내에서 현재 사용중인 메모리 비중
% SQL with executions>1 전체 SQL 개수에서 두번이상 수행된 SQL이 차지하는 비중. 이 비율이 낮으면 Literal 상수값을 이용하는 쿼리수행빈도가 높다는 뜻
% Memory for SQL w/exec>1 전체 SQL이 차지하는 메모리 중 두번이상 수행된 SQL이 차지하는 메모리 비중. 이 비율이 낮으면 Literal 상수값을 이용하는 쿼리수행빈도가 높다는 뜻

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.