오라클은 성능 측정 지표로서 활용 가능한 항목들을 선정하고, SQL이 수행되는 동안 지속적으로 그 항목들에 대한 누적 통계치를 저장하며,
인스턴스 기동 후 현재까지 누적 통계치를 시스템 레벨로 확인하고자 할 때 사용하는 뷰
수행 통계 자료를 이용해 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이 낭비되고 있음을 의미 |
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015