누적 성능 통계 읽기: V$SYSSTAT·V$SESSTAT과 Delta

핵심 요약

V$SYSSTAT과 V$SESSTAT은 Oracle의 작업량을 숫자로 보여 주지만, 모든 VALUE를 같은 방식으로 빼면 안 됩니다. 먼저 Statistic의 성격과 측정 범위를 구분합니다.

누적 Counter
  → Begin·End Snapshot의 Delta 계산
  → 예: session logical reads, execute count, redo size

현재 Gauge
  → 특정 시점의 현재 상태
  → 예: logons current, opened cursors current
  → 단순 Delta보다 End·평균·최댓값을 해석

최댓값·High-Water
  → 구간 중 또는 기동 후 최대 상태
  → 증가분을 처리 작업량으로 해석하지 않음

누적 Counter의 기본 계산은 다음과 같습니다.

Delta    = End Value - Begin Value
Rate     = Delta / Elapsed Seconds
Per Tx   = Delta / Business Transactions
Per Exec = Delta / Executions
Per Row  = Delta / Rows Processed

그러나 계산 전에 반드시 범위를 맞춥니다.

Instance 통계
  → 같은 DB·INST_ID·STARTUP_TIME·CON_ID

Session 통계
  → 같은 INST_ID·SID·SERIAL#·LOGON_TIME·CON_ID

Statistic
  → 같은 NAME·같은 단위·같은 Counter 유형

업무 분모
  → 분자와 동일한 Service·Session·SQL·시간 구간

성능 진단에서는 다음 세 축을 함께 봅니다.

• 총량: 구간 전체 작업량
• 처리 강도: 초당 작업량
• 업무 효율: Transaction·Execution·Row당 작업량

큰 누적값
  ≠ 현재 병목

높은 Rate
  ≠ 비효율 증가

좋은 Ratio
  ≠ 작은 총 작업량

이 이론의 범위

이 이론은 SQLP의 SQL 고급활용 및 튜닝 → SQL 분석 도구 → 응답 시간 분석 범위에서 누적 성능 통계의 Snapshot·Delta·정규화를 다룹니다. SQL Trace·TKPROF, AWR·ASH와 개별 SQL 실행계획의 상세 분석은 후속 이론에서 다룹니다.

학습 목표

이 이론을 학습한 뒤에는 다음 내용을 설명할 수 있어야 합니다.

• V$SYSSTAT, V$SESSTAT, V$STATNAME, V$MYSTAT의 관찰 범위를 구분한다.
• 누적 Counter·현재 Gauge·최댓값 Statistic을 구분한다.
• STATISTIC#가 Release 사이 고정되지 않으며 Script에서는 NAME을 사용해야 하는 이유를 설명한다.
• Instance Snapshot의 INST_ID, STARTUP_TIME, CON_ID를 기록한다.
• Session Snapshot의 SID, SERIAL#, LOGON_TIME을 함께 기록한다.
• 누적 Counter의 Delta와 초당 Rate를 계산한다.
• Gauge와 High-Water Statistic을 단순 Delta로 해석하지 않는다.
• 분자와 분모의 Instance·Session·SQL·업무 범위를 맞춘다.
• Physical Block·I/O Request·Byte와 시간 단위를 구분한다.
• execute count와 user calls의 범위를 설명한다.
• V$MYSTAT 측정 SQL이 자신의 Session 통계를 오염시키는 현상을 통제한다.
• Negative Delta의 원인을 Restart·Session 재사용·범위 변경·Statistic 유형에서 찾는다.
• Ratio를 목표값이 아니라 다음 조사 범위를 정하는 신호로 사용한다.
• System → Session → SQL → Operation 순서로 원인을 좁힌다.

1. 동적 성능 통계 View의 범위

1.1 V$SYSSTAT의 CDB 범위

CDB Root에서 V$SYSSTAT을 조회하면 Instance 전체 범위의 행이 CON_ID=0으로 반환됩니다. Root 조회 결과가 PDB별 세부 통계라고 가정하면 안 됩니다.

PDB 범위가 필요한 경우 다음을 통제합니다.

• 어느 Container에 접속해 조회했는가
• Snapshot의 CON_ID
• Monitoring 도구가 CDB 전체인지 PDB별 통계인지
• RAC이면 어느 INST_ID인지

1.2 V$SESSTAT의 Session 범위

V$SESSTAT은 현재 존재하는 Session의 Statistic을 보여 줍니다. SID는 Session 종료 후 재사용될 수 있으므로 SID만으로 Begin·End Snapshot을 연결하면 다른 Session을 비교할 수 있습니다.

Session Snapshot Key

INST_ID
SID
SERIAL#
LOGON_TIME
CON_ID
STATISTIC NAME

SERIAL#와 LOGON_TIME은 V$SESSION 또는 GV$SESSION에서 함께 수집합니다.

2. Statistic 이름과 번호

V$STATNAME은 V$SESSTAT과 V$SYSSTAT에서 사용하는 Statistic 이름을 제공합니다.

Oracle 공식 문서의 핵심 기준은 다음과 같습니다.

STATISTIC#
  → Oracle Release 사이 값이 바뀔 수 있음
  → Application Script의 영구 Key로 사용하지 않음

NAME
  → Release 사이 안정적으로 사용할 수 있는 이름
  → Snapshot·Monitoring Key로 사용

DISPLAY_NAME
  → 더 읽기 쉬운 이름
  → Release 사이 변경 가능

따라서 Snapshot 저장 시 STATISTIC#만 기록하지 않고 NAME을 기록합니다.

2.1 Session Statistic 이름 조인

CDB·RAC 환경을 고려한 예시는 다음과 같습니다.

SELECT ss.inst_id,
       ss.sid,
       se.serial#,
       se.logon_time,
       ss.con_id,
       sn.name,
       ss.value
FROM   gv$sesstat ss
JOIN   gv$statname sn
  ON   sn.inst_id    = ss.inst_id
 AND   sn.statistic# = ss.statistic#
 AND   sn.con_id     = ss.con_id
JOIN   gv$session se
  ON   se.inst_id = ss.inst_id
 AND   se.sid     = ss.sid
 AND   se.con_id  = ss.con_id
WHERE  ss.sid = :sid
AND    sn.name IN (
         'session logical reads',
         'physical reads',
         'parse count (total)',
         'parse count (hard)',
         'execute count',
         'user calls',
         'user commits',
         'redo size'
       )
ORDER BY sn.name;

단일 Instance·현재 Container에서는 V$ View로 단순화할 수 있습니다.

3. Statistic 유형부터 구분한다

V$SYSSTAT.VALUE와 V$SESSTAT.VALUE는 모두 숫자이지만 의미는 Statistic마다 다릅니다.

3.1 누적 Counter

구간 동안 발생한 작업 횟수·Block·Byte·시간을 누적합니다.

대표 예시는 다음과 같습니다.

• session logical reads
• physical reads
• parse count (total)
• parse count (hard)
• execute count
• user calls
• user commits
• redo size
• db block changes
• opened cursors cumulative

이 유형은 같은 범위의 Begin·End Delta를 계산합니다.

3.2 현재 Gauge

조회 시점의 현재 상태를 나타냅니다.

대표 예시는 다음과 같습니다.

• logons current
• opened cursors current

Begin 500
End   520
Delta  20

이 값의 Delta 20은 “구간에 20회 Logon이 발생했다”는 뜻이 아닙니다. 종료 시점에 현재 접속 Session이 20개 더 많다는 뜻입니다.

Gauge는 다음 방식으로 분석합니다.

• End Value
• 구간 평균
• 구간 최댓값
• 정상 구간과 같은 시각의 현재값 비교

3.3 최댓값·High-Water·Derived Statistic

일부 Statistic은 기동 후 최대값, 현재 계산값 또는 내부 상태를 나타낼 수 있습니다. 이런 값의 증가분을 업무 처리량으로 사용하면 안 됩니다.

Statistic을 Delta 대상으로 사용하기 전에 현재 Database 버전의 Statistics Descriptions에서 정의와 단위를 확인합니다.

4. Snapshot 범위를 고정한다

4.1 Instance Snapshot Key

snapshot_time
db_unique_name 또는 dbid
inst_id
instance_name
startup_time
con_id
statistic_name
statistic_value

Instance Restart가 발생하면 누적 Counter의 기준점이 초기화될 수 있으므로 V$INSTANCE.STARTUP_TIME을 함께 저장합니다.

SELECT SYSTIMESTAMP AS snapshot_time,
       s.inst_id,
       i.instance_name,
       i.startup_time,
       s.con_id,
       s.name,
       s.value
FROM   gv$sysstat s
JOIN   gv$instance i
  ON   i.inst_id = s.inst_id
WHERE  s.name IN (
         'session logical reads',
         'physical reads',
         'physical read IO requests',
         'physical read bytes',
         'parse count (total)',
         'parse count (hard)',
         'execute count',
         'user calls',
         'user commits',
         'user rollbacks',
         'redo size',
         'db block changes'
       )
ORDER BY s.inst_id, s.con_id, s.name;

4.2 Session Snapshot Key

snapshot_time
inst_id
sid
serial#
logon_time
con_id
service_name
module
action
statistic_name
statistic_value

같은 SID라도 SERIAL# 또는 LOGON_TIME이 다르면 새 Session입니다.

4.3 RAC Delta

RAC 전체 Delta가 필요하면 각 Instance에서 먼저 Delta를 계산한 뒤 합산합니다.

Instance 1 Delta
+ Instance 2 Delta
+ Instance 3 Delta
= RAC 구간 총량

한 Instance가 측정 중 Restart됐다면 해당 Instance의 Begin·End Counter를 직접 빼지 않습니다.

5. 누적 Counter의 Delta 계산

같은 범위의 Snapshot을 수집했다고 가정합니다.

Delta = End - Begin

300초 구간의 Rate는 다음과 같습니다.

Logical Reads/sec  = 900,000 ÷ 300 = 3,000
Physical Reads/sec =  60,000 ÷ 300 =   200
Hard Parses/sec    =     600 ÷ 300 =     2
Executes/sec       =  60,000 ÷ 300 =   200
Commits/sec        =   3,000 ÷ 300 =    10

5.1 Negative Delta

End가 Begin보다 작으면 다음을 확인합니다.

1. Instance가 Restart됐는가
2. RAC의 다른 INST_ID를 연결했는가
3. Session이 종료되고 같은 SID가 재사용됐는가
4. SERIAL#·LOGON_TIME이 같은가
5. PDB·Container 범위가 달라졌는가
6. 같은 Statistic NAME을 비교했는가
7. 해당 Statistic이 누적 Counter가 아니라 Gauge인가
8. Monitoring 수집 실패·누락·값 변환 문제가 있는가

Negative Delta를 그대로 음수 작업량으로 사용하지 않습니다.

6. 초당 Rate와 업무량 정규화

Rate가 증가했다고 효율이 나빠진 것은 아닐 수 있습니다.

6.1 정상적인 처리량 증가

총량은 두 배지만 업무당 작업량은 같습니다.

6.2 비효율 증가

업무량은 같지만 주문당 Logical Reads가 5배 증가했습니다.

6.3 좋은 분모를 선택한다

분모의 범위는 분자와 일치해야 합니다.

Instance Logical Reads
  ÷ Instance 전체 업무량

Session Logical Reads
  ÷ 같은 Session이 처리한 업무량

SQL Buffer Gets
  ÷ 같은 SQL의 Executions 또는 Rows

Service 작업량
  ÷ 같은 Service의 Request 수

잘못된 예시는 다음과 같습니다.

특정 SQL의 Buffer Gets
  ÷ Instance 전체 execute count

한 PDB의 Physical Reads
  ÷ CDB 전체 Transaction

한 Session의 Redo
  ÷ 다른 Session의 업무 건수

7. Transaction·Execution·Call 통계의 범위

7.1 user commits와 user rollbacks

user commits는 User Commit 수이며 Transaction Rate에 가장 가까운 통계 중 하나입니다. 그러나 Application 업무 건수와 항상 같지는 않습니다.

• 한 업무가 여러 번 Commit할 수 있음
• 여러 업무를 한 Transaction으로 묶을 수 있음
• Rollback은 명시적 Rollback 또는 오류로 발생할 수 있음
• Autonomous·내부 처리와 Application 의미가 다를 수 있음

가능하면 Application의 주문 완료·API 성공·Batch 처리 건수를 사용합니다.

7.2 execute count

execute count는 User와 Recursive SQL Statement의 Execute Call 총수입니다.

따라서 다음 값을 직접 의미하지 않습니다.

• Application이 호출한 고유 SQL 수
• 업무 Transaction 수
• 특정 SQL의 실행 횟수

특정 SQL의 실행당 작업량은 V$SQL, SQL Trace 또는 SQL Monitor의 같은 SQL 범위 통계를 사용합니다.

7.3 user calls

user calls는 Login·Parse·Fetch·Execute 같은 User Call 수입니다. SQL Execute Count와 같은 단위가 아니며 Application Round Trip의 근사 신호로 사용할 때도 Client Driver와 Call 구조를 고려합니다.

8. 통계 단위와 활동 범위

8.1 평균 I/O Request 크기

같은 Application Activity 범위라면 다음 값을 계산할 수 있습니다.

평균 Byte / Request
  = Δphysical read bytes
    / Δphysical read IO requests

Database Block Size를 알고 있고 통계 범위가 일치한다면 Block/Request도 보조적으로 계산할 수 있습니다.

전체 Instance 통계와 Application 전용 통계를 섞지 않습니다.

9. V$MYSTAT 실습과 측정 오염

현재 Session의 통계를 확인할 때 V$MYSTAT을 사용할 수 있습니다.

SELECT sn.name,
       ms.value
FROM   v$mystat ms
JOIN   v$statname sn
  ON   sn.statistic# = ms.statistic#
 AND   sn.con_id     = ms.con_id
WHERE  sn.name IN (
         'session logical reads',
         'physical reads',
         'execute count',
         'parse count (total)'
       )
ORDER BY sn.name;

그러나 이 조회 자체가 현재 Session의 다음 통계를 증가시킬 수 있습니다.

• Parse·Execute Call
• Logical I/O
• User Call
• Cursor Open

9.1 오염을 줄이는 방법

• 별도 Observer Session에서 대상 SID·SERIAL#의 V$SESSTAT 조회
• 시작·종료에 같은 Snapshot SQL 사용
• Snapshot SQL을 먼저 실행해 Cursor를 준비한 뒤 측정
• 대상 작업량을 충분히 크게 하여 측정 Overhead 비중 축소
• SQL Trace·AUTOTRACE·DBMS_APPLICATION_INFO와 조합
• 반복 측정 후 Snapshot Overhead Baseline을 따로 측정

같은 Session의 작은 SQL 한 번을 측정할 때는 Snapshot SQL의 비용이 대상 작업보다 클 수도 있습니다.

10. Ratio는 질문을 만드는 도구다

Ratio는 분자와 분모가 어떤 범위를 나타내는지 먼저 정의합니다.

10.1 Hard Parse 비중

Hard Parse Share
  = Δparse count (hard)
    / Δparse count (total)

parse count (total)은 Hard·Soft·Describe Parse Call을 포함합니다. Session Cursor Cache Hit는 SQL이 다시 Parse되지 않은 재사용을 포함할 수 있으므로 실제 재파싱 문제를 분석할 때 함께 확인합니다.

10.2 Buffer Cache Hit Ratio

Buffer Cache Hit Ratio는 전체 physical reads가 아니라 Cache 전용 통계의 같은 구간 Delta를 사용합니다.

BCHR
  = 1 - Δphysical reads cache
        / (Δconsistent gets from cache
           + Δdb block gets from cache)

Ratio는 목표값이 아니라 다음 질문을 만드는 신호입니다.

• 총 Logical Reads가 얼마나 큰가
• 실행당·업무당 Block 수가 늘었는가
• Physical I/O Wait가 DB Time의 큰 비중인가
• 특정 SQL·Session에 집중됐는가

11. System에서 Session·SQL로 범위 좁히기

V$SYSSTAT Delta는 Instance 전체에서 “무엇이 증가했는가”를 알려 주지만 원인 SQL을 직접 알려 주지 않습니다.

Instance Statistic 증가
  → Service·Module·Action별 부하 확인
  → Session별 V$SESSTAT Delta 확인
  → SQL_ID·Child별 V$SQL·Trace·ASH 확인
  → 실제 실행계획 Operation 확인

11.1 Hard Parse 증가 예

1. Δparse count (hard)와 Δparse count (total) 계산
2. Δexecute count, Session Cursor Cache Hit와 비교
3. Service·Module·Session에서 증가 범위 확인
4. Literal SQL과 Parent Cursor 수 확인
5. V$SQLAREA.VERSION_COUNT, V$SQL_SHARED_CURSOR 확인
6. Bind·Statement 재사용과 Optimizer 환경 확인
7. 개선 후 Hard Parse·Parse CPU·응답시간 재측정

11.2 Logical I/O 증가 예

1. Instance Logical Reads/sec·Transaction 계산
2. 증가한 Service·Session 확인
3. SQL별 Buffer Gets/Execution·Row 확인
4. 실행계획에서 후보 행·반복 Operation 확인
5. Predicate·Bind·통계정보와 연결
6. 같은 업무량으로 변경 전후 비교

12. Snapshot 비교에서 주의할 기준

13. 성능 개선 전후 비교 예

동일한 주문 10,000건을 처리한 두 구간을 비교합니다.

성능 개선은 Ratio 하나가 아니라 다음 결과로 판단합니다.

• 사용자 응답시간·Batch 완료시간
• Throughput
• 업무당 Logical I/O·CPU·Redo
• 실행당 SQL 작업량
• Error·정합성
• 새 병목의 발생 여부

14. 핵심 진단 순서

1. Statistic이 Counter·Gauge·High-Water 중 무엇인지 확인한다.
2. 정상 구간과 문제 구간의 범위를 정의한다.
3. Instance·Container·Session Identity를 기록한다.
4. NAME과 단위를 확인한다.
5. Counter는 Delta, Gauge는 평균·최댓값·종료값을 계산한다.
6. 초당 Rate와 업무당 값을 계산한다.
7. 분자와 분모의 범위를 맞춘다.
8. Instance → Service → Session → SQL → Operation으로 좁힌다.
9. Wait·Time Model·실행계획과 연결한다.
10. 동일 조건에서 개선 전후를 재측정한다.

누적 통계를 읽는 핵심은 큰 숫자 자체를 평가하는 것이 아닙니다. 동일한 범위의 변화량을 시간과 업무량으로 정규화하고, 증가한 작업을 만든 Session·SQL·Operation까지 연결하는 것입니다.

15. 자주 혼동하는 판단