꿈꾸는 개발자, DBA 커뮤니티 구루비

인스턴스 기동 후 현재까지 누적 통계치를 시스템 레벨로 확인하고자 할 때 사용하는 뷰
(1)시스템 수행 통계 수집 및 분석
(2) Ratio 기반 성능 분석

인스턴스 기동 후 현재까지 누적 통계치를 시스템 레벨로 확인하고자 할 때 사용하는 뷰

(희발성)

v$statname --> 지표를 설명
v$sysstat --> 인스턴스 시작이후 각종 통계 내역 누적
v$service_stats --> 서비스 이름별 통계 관련 지표 누적
v$sesstat --> 현재 연결중인 각 세션의 통계 누적
v$mystat --> 본인 세션의 통계 누적

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

v$sysstat에 나타나는 값들은 인스턴스 기동 후 또는 세션 수립 후 현재까지 누적된 값
값의 크고 작음만으로 의미있는 정보를 얻기는 힘듬
두 구간 사이의 변화량(증분, delta)을 구해 내부적으로 어떤 일이 있었는지 판단
DELTA값 구하기 : P192, 193참조

(2) Ratio 기반 성능 분석

수행 통계 자료를 이용해 DB의 전반적인 건강상태를 체크 할 수 있는 의미 있는 Ratio 값을 구할 수 있음
이 값들은 문제가 발견되었을 때 그 원인을 분석하는 데에 취약함.

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