Buffer cache ratio 관련 내용

Buffer Hit Ratio is NOT Everything

 

-A badly tuned database can still have a hit ratio of 99% or better

 

 Buffer Hit Ratio 가 90% 이하로 낮아질 경우에 튜닝대상이 된다고하는데 이말에는 커다란 오점이있다. Buffer Hit Ratio 는 인스턴스가

 

 시작된이래로 수집된 평균값이기 때문에 신뢰하기 어렵다. 즉 인스턴스시작이래로 Buffer Hit Ratio가 90%이어도 지금 인스턴스가

 

 최적화 되어있다고 말할 수가 없다는것이다.

 

 그래서 Delta Hit Ratio분석을 많이 사용한다. 이 방법은 전체적인 평균값이 아닌 일정 시간 간격의 Hit Ratio를 측정하는 방법으로

 

 훨씬 유용하고 신뢰도가 높다.

 

 

 

- Hit ratio is only one part of determining tuning performance

 

- Hit Ratio does not determine whether a database is optimally tuned

 

  : 예를 들어, A와 B두개의 애플리캐이션이 있다고 가정하자. A의 cache hit ratio가 99% , 반면에 B의 cache hit ratio가 60%다.

 

    이 지표를 봤을때에는 A가 훨씬좋은 성능을 가지고있다. 그렇다면 다른지표를 하나더 본다면 A는 100,000의 Logical reads 와

 

    1000의 physical read가 필요하고 B는 100의 Logical reads와 40의 Physical reads가 필요하다. 이렇게 놓고본다면 어느애플리케이션이 더 최적화 되어있는가? 이런이유로만 봐도 cache hit ratio지표만 보고는 튜닝의 대상이 될수 없다.

 

- Use the wait interface to examine what is causing a bottleneck:

 

  -v$session_wait

 

  -v$session_event

 

  -v$system_event

 

- Tune SQL statements

 

   : 위의 예제 에서 봤듯이 cache hit ratio지표를 가지고 먼저 튜닝을 하는것 보다 badSQL을 찾아서 최적화하는것이

 

     더 바람직한 방법이다.

 

 

 

Interpreting Buffer Cache Hit Ratio

 

 

 

Hit ratio는 데이터 접근 방법에 따라 영향을 받는다.

 

   -전체 테이블 스캔

 

     : 전체 테이블 스캔으로 읽은 블록들은 LRU의 꼬리 쪽에 위치하게 된다. 이말은 index lookup ,short table스캔에 비해 메모리에서탈락될 가능성이 높다는 것이다. 그렇기 때문에 광범위의 전체 테이블스캔이 발생할 때 hit ratio가 낮게 나올수 있다는것을  기억해 두자!

 

   -동일한 테이블에서의 반복적인 스캔

 

     : 동일한 큰 테이블에서의 반복 스캔 또는 인덱스 스캔은 비정상적으로 hit ratio 를 낮게 부풀린다.

 

   -큰 테이블에서의 랜덤액세스

 

     :큰 테이블에서의 랜덤액세스는 hit ratio가 낮다. 테이블이 크기고 랜덤액세스를 하기때문에 대부분의 로우들은 한번이나 혹은 0번 액세스 되어진다.

 

   -데이타 또는 어플리캐이션 설계

 

 

 

Investigate increasing the cache size if

 

  - Hit ratio is low

 

  - Application is tuned to avoid full table scans