(V7.3 ~ 8.X) V$SYSSTAT 과 V$SESSTAT의 DESCRIPTION

Question

제품 : ORACLE SERVER
작성날짜 : 2004-11-01
(V7.3 ~ 8.X) V$SYSSTAT 과 V$SESSTAT의 DESCRIPTION
================================================
PURPOSE
이 문서는 V$SYSSTAT 과 V$SESSTAT 뷰에 관한 DESCRIPTION을
담고 있는 문서이다. 이 문서의 스크립트는 V7.3 이상부터 모든
V8.X version에서 수행될 수 있다.
Explanation
V$SYSSTAT view는 인스턴스가 시작된 이후에 수집된 모든 인스턴스
레벨의 통계정보들의 누적치를 포함하고 있다.
이 view가 포함하고 있는 통계정보들의 이름을 확인하려면
V$STATNAME 과 join하여 확인한다.
select n.name, s.value
from v$statname n , v$sysstat s
where n.statistic# = s.statistic#
order by n.class, n.name
V$SESSTAT 은 각 세션이 시작된 이후로 생성된 세션 레벨의 모든
통계정보들의 누적치를 포함하고 있다.
이 view가 포함하고 있는 통계정보들의 이름을 확인하려면
V$STATNAME 과 join하여 확인한다.
다음 query는 현재 session의 session id를 return한다.
(아래 SQL은 Two-task 환경이나 SQL*Net 환경에서는 terminal 컬럼이
NULL 이므로 동작하지 않는다.)
select s.sid
from v$process p, v$session s
where p.addr = s.paddr
and terminal = userenv('terminal')
Session id는 V$SESSTAT view로부터 정확한 value를 얻기 위해 필요하다.
select n.name, s.value
from v$statname n , v$sesstat s
where s.sid = &sid
and n.statistic# = s.statistic#
order by n.class, n.name
종종, 어떤 test를 수행하기 전/후에 V$SYSSTAT 과 V$SESSTAT view로부터
snapshot을 얻어내는 것이 아주 유용하다. 두 snapshot의 값의 차이는
snapshot 기간 동안의 서버의 activity를 나타낸다. (단, V$SYSSTAT을
조회하려면 인스턴스를 shutdown하지 말아야 하고, Snapshot 사이의
V$SESSTAT 을 조회한다면 Session이 서버로부터 disconnect하면 안 된다.)
(참조) 통계정보의 대부분은 항상 누적되는 누적치(횟수)를 나타내지만,
그러나, 통계정보 중의 일부는 TIMED_STATISTICS = TRUE 인 환경에서
누적되는 시간을 나타내기도 한다.
Example
관련 통계정보의 설명
1) SORTS(MEMORY)
메모리 내의 SORT AREA 내에서 발생한 SORT의 횟수.
2) SORTS(DISK)
Temporary Segment를 필요로 하는 sort 수행 횟수.
위 두 통계정보의 합은 인스턴스가 기동된 이후 발생한 모든 sort 수행 횟수이다.
만약 너무 많은 sort가 수행되었다면 sort를 줄이도록 applications/SQL
statement들을 tuning한다. SORT_AREA_SIZE 를 늘리면 더 많은 sort 작업이
메모리 내에서 발생하도록 개선할 수 있다.
3) SORTS(ROWS)
수행된 모든 sort 작업에서 sort 처리되었던 rows의 총합.
4) TABLE SCANS (SHORT TABLES)
4개 이하의 db block을 가지는 작은 table에 대한 full table scan의 횟수.
이러한 table의 경우 index scan을 하는 것보다 full table scan(한번의 I/O)
을 하는 것이 더 효율적이다.
5) TABLE SCANS (LONG TABLES)
5개 이상의 db block을 가지는 큰 table에 대한 full table scan의 횟수.
만약 10~20% 의 row가 return된다면 index를 사용하여 table을 액세스하는
것이 더 효율적일 것이다.
만약 full table scan을 사용하여 Long table을 액세스하는 것이 필요하다면
good buffer cache hit ratio를 기대하기는 힘들 것이다.
DB_BLOCK_BUFFERS 를 늘리는 것이 Long table을 액세스하는 데 도움이 되지
않는다. 왜냐하면 이러한 block들이 LRU chain의 bottom에 머무르기 때문이다.
그러나, DB_FILE_MULTIBLOCK_READ_COUNT 를 늘리게 되면 disk I/O를 줄이게 되어
도움이 될 수 있다.
이러한 두 통계정보의 합은 모든 FULL TABLE SCAN의 총 횟수를 나타낸다.
6) TABLE SCAN BLOCKS GOTTEN
모든 Full table scan에 의해 액세스된 block의 총 갯수.
Short table scan은 많아야 4 block이기 때문에 하나의 long table scan에
의해 액세스된 block의 평균 갯수를 알 수 있다.
7) TABLE SCAN ROWS GOTTEN
모든 Full table scan에 의해 액세스된 row의 총 갯수.
이것은 단지 qualifying row의 수가 return되는 것이므로,
마지막에 return된 row의 수가 아니다.
8) TABLE FETCH BY ROWID
ROWID에 의해 액세스된 ROW의 갯수.
이것은 rowid를 통해 index를 사용하고, 직접적으로 rowid를 사용하여 액세스된
(where rowid = :rowid) 모든 ROW들에 대한 COUNT이다.
9) TABLE FETCH CONTINUED ROW
Chained row의 두번 째 row piece가 fetch된 횟수.
이 수치가 높을 수록 row가 많이 chain되었음을 나타낸다.
(주) Long column을 갖는 row는 한 block에 fit되지 못하므로, 종종 chain된다.
10) CLUSTER KEY SCANS
cluster key scan의 횟수.
11) CLUSTER KEY SCAN BLOCK GETS
cluster key scan에 의해 액세스된 block의 총 갯수.
'cluster key scans'에 대한 이 통계정보의 비율은 'cluster key scan' 당
액세스한 평균 block 수를 나타낸다.
이상적인 값은 1이다. 각 cluster key에 대한 모든 data가 한 db block에
fit되었음을 나타낸다.
12) CONSISTENT GETS
Normal queries (SELECTs without for update clause)에 대하여
Buffer cache 내에서 액세스된 block의 총 갯수.
13) DB BLOCK GETS
INSERT, UPDATE, DELETE and SELECT FOR UPDATE 문장에 대하여
Buffer cache 내에서 액세스된 block의 총 갯수.
이 두 통계정보의 합은 logical reads의 총합이다.
14) PHYSICAL READS
Physical Reads의 총합.
이 수치는 Buffer cache hit ratio을 계산하기 위해 logical reads와
비교 시 사용된다.
15) BUFFER BUSY WAITS
다른 process가 incompatible mode로 그 block을 잡고 있어서
block access가 fail되었던 총 횟수.
만약 이 통계수치가 Logical reads의 10%를 초과한다면 contention을
확인하기 위해 V$WAITSTAT view를 조회해야 한다.
Reference Documents
<Note:423.1>

Answer 1

제품 : ORACLE SERVER
작성날짜 : 2004-11-01
(V7.3 ~ 8.X) V$SYSSTAT 과 V$SESSTAT의 DESCRIPTION
================================================
PURPOSE
이 문서는 V$SYSSTAT 과 V$SESSTAT 뷰에 관한 DESCRIPTION을
담고 있는 문서이다. 이 문서의 스크립트는 V7.3 이상부터 모든
V8.X version에서 수행될 수 있다.
Explanation
V$SYSSTAT view는 인스턴스가 시작된 이후에 수집된 모든 인스턴스
레벨의 통계정보들의 누적치를 포함하고 있다.
이 view가 포함하고 있는 통계정보들의 이름을 확인하려면
V$STATNAME 과 join하여 확인한다.
select n.name, s.value
from v$statname n , v$sysstat s
where n.statistic# = s.statistic#
order by n.class, n.name
V$SESSTAT 은 각 세션이 시작된 이후로 생성된 세션 레벨의 모든
통계정보들의 누적치를 포함하고 있다.
이 view가 포함하고 있는 통계정보들의 이름을 확인하려면
V$STATNAME 과 join하여 확인한다.
다음 query는 현재 session의 session id를 return한다.
(아래 SQL은 Two-task 환경이나 SQL*Net 환경에서는 terminal 컬럼이
NULL 이므로 동작하지 않는다.)
select s.sid
from v$process p, v$session s
where p.addr = s.paddr
and terminal = userenv('terminal')
Session id는 V$SESSTAT view로부터 정확한 value를 얻기 위해 필요하다.
select n.name, s.value
from v$statname n , v$sesstat s
where s.sid = &sid
and n.statistic# = s.statistic#
order by n.class, n.name
종종, 어떤 test를 수행하기 전/후에 V$SYSSTAT 과 V$SESSTAT view로부터
snapshot을 얻어내는 것이 아주 유용하다. 두 snapshot의 값의 차이는
snapshot 기간 동안의 서버의 activity를 나타낸다. (단, V$SYSSTAT을
조회하려면 인스턴스를 shutdown하지 말아야 하고, Snapshot 사이의
V$SESSTAT 을 조회한다면 Session이 서버로부터 disconnect하면 안 된다.)
(참조) 통계정보의 대부분은 항상 누적되는 누적치(횟수)를 나타내지만,
그러나, 통계정보 중의 일부는 TIMED_STATISTICS = TRUE 인 환경에서
누적되는 시간을 나타내기도 한다.
Example
관련 통계정보의 설명
1) SORTS(MEMORY)
메모리 내의 SORT AREA 내에서 발생한 SORT의 횟수.
2) SORTS(DISK)
Temporary Segment를 필요로 하는 sort 수행 횟수.
위 두 통계정보의 합은 인스턴스가 기동된 이후 발생한 모든 sort 수행 횟수이다.
만약 너무 많은 sort가 수행되었다면 sort를 줄이도록 applications/SQL
statement들을 tuning한다. SORT_AREA_SIZE 를 늘리면 더 많은 sort 작업이
메모리 내에서 발생하도록 개선할 수 있다.
3) SORTS(ROWS)
수행된 모든 sort 작업에서 sort 처리되었던 rows의 총합.
4) TABLE SCANS (SHORT TABLES)
4개 이하의 db block을 가지는 작은 table에 대한 full table scan의 횟수.
이러한 table의 경우 index scan을 하는 것보다 full table scan(한번의 I/O)
을 하는 것이 더 효율적이다.
5) TABLE SCANS (LONG TABLES)
5개 이상의 db block을 가지는 큰 table에 대한 full table scan의 횟수.
만약 10~20% 의 row가 return된다면 index를 사용하여 table을 액세스하는
것이 더 효율적일 것이다.
만약 full table scan을 사용하여 Long table을 액세스하는 것이 필요하다면
good buffer cache hit ratio를 기대하기는 힘들 것이다.
DB_BLOCK_BUFFERS 를 늘리는 것이 Long table을 액세스하는 데 도움이 되지
않는다. 왜냐하면 이러한 block들이 LRU chain의 bottom에 머무르기 때문이다.
그러나, DB_FILE_MULTIBLOCK_READ_COUNT 를 늘리게 되면 disk I/O를 줄이게 되어
도움이 될 수 있다.
이러한 두 통계정보의 합은 모든 FULL TABLE SCAN의 총 횟수를 나타낸다.
6) TABLE SCAN BLOCKS GOTTEN
모든 Full table scan에 의해 액세스된 block의 총 갯수.
Short table scan은 많아야 4 block이기 때문에 하나의 long table scan에
의해 액세스된 block의 평균 갯수를 알 수 있다.
7) TABLE SCAN ROWS GOTTEN
모든 Full table scan에 의해 액세스된 row의 총 갯수.
이것은 단지 qualifying row의 수가 return되는 것이므로,
마지막에 return된 row의 수가 아니다.
8) TABLE FETCH BY ROWID
ROWID에 의해 액세스된 ROW의 갯수.
이것은 rowid를 통해 index를 사용하고, 직접적으로 rowid를 사용하여 액세스된
(where rowid = :rowid) 모든 ROW들에 대한 COUNT이다.
9) TABLE FETCH CONTINUED ROW
Chained row의 두번 째 row piece가 fetch된 횟수.
이 수치가 높을 수록 row가 많이 chain되었음을 나타낸다.
(주) Long column을 갖는 row는 한 block에 fit되지 못하므로, 종종 chain된다.
10) CLUSTER KEY SCANS
cluster key scan의 횟수.
11) CLUSTER KEY SCAN BLOCK GETS
cluster key scan에 의해 액세스된 block의 총 갯수.
'cluster key scans'에 대한 이 통계정보의 비율은 'cluster key scan' 당
액세스한 평균 block 수를 나타낸다.
이상적인 값은 1이다. 각 cluster key에 대한 모든 data가 한 db block에
fit되었음을 나타낸다.
12) CONSISTENT GETS
Normal queries (SELECTs without for update clause)에 대하여
Buffer cache 내에서 액세스된 block의 총 갯수.
13) DB BLOCK GETS
INSERT, UPDATE, DELETE and SELECT FOR UPDATE 문장에 대하여
Buffer cache 내에서 액세스된 block의 총 갯수.
이 두 통계정보의 합은 logical reads의 총합이다.
14) PHYSICAL READS
Physical Reads의 총합.
이 수치는 Buffer cache hit ratio을 계산하기 위해 logical reads와
비교 시 사용된다.
15) BUFFER BUSY WAITS
다른 process가 incompatible mode로 그 block을 잡고 있어서
block access가 fail되었던 총 횟수.
만약 이 통계수치가 Logical reads의 10%를 초과한다면 contention을
확인하기 위해 V$WAITSTAT view를 조회해야 한다.
Reference Documents
<Note:423.1>