Dynamic Performance View

  • 여러 Dynamic Performance 뷰가 PGA_AGGREGATE_TARGET Parameter의 값 Tuning을 돕는 정보를 제공

h3.종류
\- V$SYSSTAT 및 V$SESSTAT
\- V$PGASTAT
\- V$PROCESS
\- V$SQL_WORKAREA_ACTIVE
\- V$SQL_WORKAREA
\- V$PAG_TARGET_ADVICE

  • V$SYSSTAT : SYSTEM LEVEL에서 인스턴스 가동 후 각 STATISTICS의 누적치 통계
  • V$SESSTAT : 현재 로그인 한 SESSION LEVEL에서의 STATISTICS의 누적치 통계
  • V$MYSTAT : 현재 접속되어 있는 자신의 SESSION 수행통계
Ex) T1 시점에서 아래의 5개 세션이 로그인 되어 있고, 각 세션의 user commits가 발생된 회수가 아래와같다. T1 시점에서 V$SESSTAT 를 조회하면 아래의 발생 수치를 확인

SESSION A 10회
SESSION B 5회 **
SESSION C 20회 **
SESSION D 15회 **
SESSION E 30회

T2 시점에서 아래의 5개 세션이 로그인 되어 있고, 각 세션의 user commits가 발생된 회수가 아래와같다.

T2 시점에서 V$SESSTAT 를 조회하면 아래의 발생 수치를 확인

SESSION A와 E는 로그인이 유지되어있으므로 위의 10 와 30회는 의미없음

SESSION A 20회 **
SESSION E 50회 **

T2에 V$SYSSTAT를 조회하면 각 세션별로 발생된 user commits 누적치 합계
: 110 회

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

V$SYSSTAT 이나 V%SESSTAT에 나타난 값만으로는 의미 있는 결과를 알기 힘듬.
이들은 두 구간사이의 변화량을 분석하는 것으로 어떤 일들이 발생했는가를 판명하는 것이다.
다음과 같은 방법으로 정보수집 스크립을 만들수도 있다. (해당 SID를 알아야 한다.)

\- 수집용 테이블 생성

SQL> create table sess_stat
as
select 1 no, statistic#, value
from v$sesstat
where sid = 170;

Table created.

\- 수집하려는 배치작업이 종료된 후.. 별도 세션에서 다음의 Insert문을 실행한다.

SQL> insert into sess_stat
select 2 no, statistic#, value
from v$sesstat
where sid = 170;

347 rows created.

\- 다음의 스크립트로 두 구간사이의 증분을 구해 상태를 알아 볼수 있다.

select b.statistic# stat#, b.name, (b.value - a.value) delta_value
from (
select n.statistic#, n.name, b.value
from v$statname n, sess_stat b
where b.statistic# = n.statistic#
and b.value > 0
and b.no = 2
) b, sess_stat a
where a.no = 1
and a.statistic# = b.statistic#
and (b.value - a.value) > 0
order by delta_value desc;

2) Ratio 기반 성능 분석
위에서 수집된 자료를 이용하여 전반적인 DB건강상태를 체크할수 있다.
아래는 주로 이용 되는 항목들이다. (공유리소스사용빈도, 경합발생비율 등)
1. Buffer NoWait%
: 버퍼블록을 읽으려 할 때, Buffer Busy Waits(대기 없이 곧바로 읽기에 성공)한 비율

2. Redo NoWait%
: Redo로그를 기록할 공간을 요청하지 않고 (곧바로 Redo 엔트리를 기록)한 비율을

3. Buffer Hit%
: (디스크 읽기를 수반하지 않고)버퍼캐시에서 블록찾기에 성공한 비율

4. Latch Hit%
: 래치 (경합없이 첫번째 시도에서 곧바로 래치를 획득)한 비율

5. Library Hit%
: (파싱부하)와 관련 있는 항목.
라이브러리 캐시에 이미 적재된 SQL커서를 생행하거나 오브젝트정보를 읽으려 할 때
(커서 또는 오브젝트정보가 힙(Heap)영역에서 찾아지는 비율

  • 자세한 내용은 4장에서 다를 것.

6. Soft Parse%
: (파싱부하)와 관련 있는 항목.
실행계획이 라이브러리 캐시에서 찾아져 (하드파싱을 일으키지 않고 SQL을 수행한 비율)

7. Execute to Parse
: (파싱부하)와 관련 있는 항목.
Parse Call없이 곧바로 SQL을 수행한 비율. 즉, 커서를(애플리케이션에서 캐싱한 채 반복 수행한 비율)

8. Parse CPU to Parse Elapsd%
: (파싱부하)와 관련 있는 항목.
파싱 총 소요 시간 중 CPU Time이 차지한 비율. (파싱에 소요된 시간 중 실제 일을 수행한 시간비율)

9. %Non-Parse CPU
: (파싱부하)와 관련 있는 항목.
SQL을 수행하면서 사용한 (전체 CPU Time중 파싱 이외의 작업이 차지한 비율)

10. In-memory Sort%
: 전체 소트 수행횟수에서 In-Memory방식으로 소트한 비율

11. Memory Usage%
: Shared Pool내에서 현재 사용중인 메모리 비중

12. %SQL with executions > 1
: (전체 SLQ개수에서 두번이상 수행)된 SQL이 차지하는 비중

13. %Memory for SQL w/exec > 1
: (전체 SQL이 차지하는 메모리 중 두번이상 수행)된 SQL이 차지하는 메모리 비중