SELECT name,
value
FROM v$sysstat
ORDER BY value DESC;
NAME VALUE
---------------------------------------------------------------- ----------
logical read bytes from cache 5.7033E+14
cell physical IO interconnect bytes 1.1657E+14
physical read total bytes 1.1585E+14
physical read bytes 1.1562E+14
table scan rows gotten 3.3738E+12
file io wait time 2.8629E+12
redo synch time overhead (usec) 2.4639E+12
physical write total bytes 7.1818E+11
session uga memory max 4.1073E+11
bytes sent via SQL*Net to client 1.4201E+11
session logical reads 8.3722E+10
consistent gets 8.3355E+10
no work - consistent read gets 7.5416E+10
physical write bytes 7.1076E+10
consistent gets from cache 6.9254E+10
redo size 6.2464E+10
table scan blocks gotten 6.1634E+10
consistent gets from cache (fastpath) 6.0931E+10
sorts (rows) 4.2377E+10
buffer is pinned count 3.6411E+10
Buffer Nowait %:
버퍼 블록을 읽으려 할 때 buffer busy waits 대기 없이 곧바로 일기에 성공한 비율.
Redo NoWait %:
Redo 로그를 기록할 공간을 요청하지 않고 곧바로 Redo 엔트리를 기록한 비율.
이 비율이 낮다면, 로그 스위칭이 느리거나 너무 자주 발생함을 의미. 로그 스위칭 휫수가 문제라면 Redo 로그 파일 크기를 증가시킬 필요가 있음. 로그 스위칭이 자주 발생하지 않는데도 이 항목이 낮은 수치를 보인다면, I/O 서브 시스템이 느린 것이 원인. Redo 로그 파일을 덜 바쁜 디스크 또는 Redo 로그만을 위한 전용 디스크로 옮기는 것을 고려해야함. 비용이 허락된다면 더 빠른 디바이스로 교체하는 것도 방법임. redo log space requests는 Redo 로그 공간에 대한 요청이 발생하는 것. 로그 스위치가 일어나면 짧은 순간이지만 서버 프로세스는 LGWR 프로세스가 Current Redo 로그에 쓰기를 완료하고 새로운 Redo 로그를 오픈할 때까지 Redo를 생성하지 못하고 계속 기다려야 하기 때문임. 이때 발생하는 대기 이벤트가 log file switch completion임. 로그 스위치가 끝나면 그때까지 대기했던 서버 프로세스들이 동시에 Redo 레코드를 기록하므로 로그 버퍼가 금방 부족해져 log buffer space 대기 이벤트가 발생할 가능성이 높음.
Buffer Hit %:
디스크 일기를 수반하지 않고 버퍼 캐시에서 블록 찾기에 성공한 비율.
Latch Hit %:
래치 경합 없이 첫 번째 시도에서 곧바로 래치를 획득한 비율.
Library Hit %:
Get 히트율 -> Parse 단계와 관련. 이 수치가 낮다면 해당 SQL 커서 또는 오브젝트에 대한 핸들을 찾을 수 없어 하드파싱 또는 최초 로드가 자주 발생하는 경우. Pin 히트율은 실행 단계와 관련. 라이브러시 캐시에 이미 적재된 SQL 커서를 실행하거나 오브젝트 정보를 읽으려 할 때 해당 커서 또느 오브젝트 정보가 힙영역에서 찾아진다면 히트에 성공. 만약 캐시에서 밀려나 찾을 수 없는 경우가 빈번하게 발생한다면 히트율이 낮게 나타나고, 그만큼 다시 로드해야 하는 부하가 생기므로 라이브러리 캐시 효율이 좋지 않음을 뜻함.
Soft Parse %:
실행계획이 라이브러리 캐시에서 찾아져 하드파싱을 일으키지 않고 SQL을 수행한 비율.
이 비율이 낮다면 바인드 변수를 사용하도록 애플리케이션을 개선해야 함.
Execute to Parse %:
Parse Call 없이 곧바로 SQL을 수행한 비율. 커서를 애플리케이션에서 캐싱한 채 반복 수행한 비율.
Parse CPU to Parse Elaped %:
파싱 총 수요 시간 중 CPU time이 차지한 비율. 파싱에 소요된 시간 중 실제 일을 수행한 시간 비율. 이 값이 낮다면 파싱도중 대기가 많이 발생했음을 의미. 또 이 수치가 낮다면 Shared Pool과 라이브러리 캐시에 경합이 많다는 것. 대게 하드 파싱 부하 때문. Load Profile에서 초당 하드 파싱 횟수를 점검하고 5개 정도만 되더라도 그 영향력은 매우 크게 나타남. Parse CPU to Parse Elaped%가 50% 안팎의 낮은 수치를 보이더라도 Library Hit%나 Soft Parse% 모두 99%에 가까운 수치를 보이는 경우가 대부분임.
소프트 파싱은 하드 파싱에 비해 매우 빠르므로 CPU to Parse Elaped% 값에 미치는 영향력이 작다.
하드 파싱은 발생 횟수가 적더라도 매우 느리므로 영향력이 큼. 수치가 커서 크게 영향을 미칠 뿐 아니라 Shared Pool과 라이브러리 캐시 관려 이벤트가 소프트 파싱에 비해 더 많이 발생하므로 CPU time과 Elapsed time간 격차를 더 키움. 두 시스템 간 소프트 파싱 비율이 같더라도 라이브러리 캐시 부하가 더 심한 시스템은, 하드 파싱할 대 경합이 발생할 가능성이 크므로 CPU to Parse Elaped% 값이 더 낮게 나타날 것이다. 초당 하드 파싱 횟수가 거의 나타나지 않는데도 이 Ratio가 낮은 수치를 기록한다면 Parse Call 자체가 많아 발생하는 경합이라고 이해하면 된다. 애플리케이션 커서 캐싱이나 세션 커서 캐싱 기능을 활용해 Parse Call 부하를 줄여주어야 함.
% Non-Parse CPU:
SQL을 수행하면서 사용한 전체 CPU time 중 파싱 이외의 작업이 차지한 비율. 이 비율이 낮다면 파싱 과정에서 소비되는 CPU time 비율이 높은 것이므로 파싱 부하를 줄이도록 애플리케이션을 개선해야 함.
In-memory Sort %:
전체 소프 수행 횟수에서 In-Memory 소트 방식으로 수행한 비율.
Memory Usage %:
Shared Pool 내에서 현재 사용 중인 메모리 비중.
% SQL witch executions > 1:
전체 SQL 개수에서 두 번 이상 수행된 SQL이 차지하는 비중. 이 값이 낮에 나타난다면 조건절에 바인드 변수를 사용하지 않고 Literal 상수 값을 이용하는 쿼리의 수행빈도가 높은 것을 의미.
% Memory for SQL w/exec > 1:
전체 SQL이 차지하는 메모리 중 두 번 이상 수행된 SQL이 차지하는 메모리 비중. 이 값이 낮게 나타난다면 조건절에 바인드 변수를 사용하지 않고 Literal 상수 값을 사용하는 쿼리에 의해 Shared Pool이 낭비되고 있음을 의미.