스크립트 설명

Library Cache Hit Ratio

Library Cache Miss Ratio 는 1~2% 가 좋음
-----------------------------------------------------------------------------------------
Redo log
Description - Redo Buffer Space Wait(%)은 redo entry 가운데 log buffer space 를 할당받기 위해 Wait 한 비율을 의미하며, redo space requests는 해당
Wait event의 발생횟수이다. Redo Log Buffer는 일반적으로 큰 문제를 유발하는 영역은 아니나, 경합이 존재할 경우 데이터베이스 성능 전체의
병목구간으로 작용할 수 있다. Space Request 이벤트를 감소시키기 위해서는 redo log buffer를 늘리거나, 생산되는 Redo의 양을 줄이거나 LGWR의
작업효율을 높여주어야 한다.

Guide - Redo Buffer Space Wait Ratio 와 Redo Log Space Request 가 0에 가까워야 하며 이 수치가 비교적 높은 값이고 연속적으로 증가하면 init.ora의
log_buffers를 증가시키는 것을 고려할 수 있다.
Log_buffers의 적절한 크기는 1M~10M 사이로 지정한다.

-----------------------------------------------------------------------------------------

Shared Pool
Description - Shared Pool은 라이브러리 캐쉬, 딕셔너리 캐쉬, Large Pool 등으로 구성된다. 여기에서 할 수 있듯이 Shared Pool은 기본적으로 캐쉬를
위한 영역이므로 여유공간이 남아있는 한 기존 오브젝트의 ageout 없이 계속 소모하려는 속성이 있다. 따라서 라이브러리 캐쉬나 딕셔너리 캐쉬의
적중률이 양호하면 일반적은 운영시간대에 free memory 크기가 낮은 상태를 유지하는 것은 정상이다. 오히려, 항상 큰 free memory가 남아 있다면
Shared Pool이 불필요하게 크게 설정되어 있다는 것을 의미하며, 일시적으로 갑자기 free memory 크기가 증가하는 경우는 분할이 많이 발생하여
많은 오브젝트가 한꺼번에flush 된 것을 의미하므로 문제를 겪고 있다는 증상일 수 있다.
일반적으로 Shared Pool에서 문제가 되는 것은 시간이 지남에 따라 메모리 영역이 작은 조각으로 분할되어 사이즈가 큰 오브젝트의 로드를 위한
memory할당에 어려움을 겪거나 심하게는 필요한 연속된 메모리 공간의 확보에 실패하여 ora-4031에러가 나는 경우이다.
특히, MTS로 운영되는 경우 UGA 영역이 Shared Pool에 할당되므로 분할이 발생할 가능성이 더 높다. 오라클은 크기가 큰 오브젝트(5000 bytes 이상)들을
위해서 기본적으로 shared Pool의 5% 정도를 따로 확보해서 관리하는데, 이 크기는 shared_pool_reserved_size 파라미터로 조정할 수 있다.

Guide - Shared Pool 메모리의 조각화를 예방하기 위한 조치로는 다음과 같은 방법이 있따.
 - 사이즈가 큰 PL/SQL 블럭의 사용을 자제한다.
 - 불가피하게 사이즈가 큰 PL/SQL 오브젝트는 DBMS_SHARED_POOL.KEEP을 사용하여 KEEP 한다.
 - Literal SQL을 바인드 변수를 사용하도록 수정해 준다.
 - shared_pool_reserved_size의 증가를 고려한다.
 - MTS의 경우 세션별로 지나치게 많은 UGA 영역을 할당하지 않도록 주의하며 애플리케이션을 작성한다.