Buffer cache hit ratio

 

9i에서 db_block_buffers 파라미터는 db_cache_size로 대체되었습니다.

그리고 그러한 작업 직후에는 일단 버퍼캐쉬에 다시 캐슁 될 때까지는 낮게 나올 수도 있습니다. 어느 정도 시간이 지나야 정상으로 돌아옵니다.

시간이 지나도 계속 낮게 나온다면... exp/imp 과정에서 색인이 누락되거나 혹은 통계값이 제대로 생성되지 않았을 수도 있습니다.

 

참고로 Hit Ratio Based 튜닝은 요즘엔 아주 낡은 방법으로 인식됩니다. 심지어 어떤 컨설턴트들은 무용론을 펼치기도 합니다.

그 이유를 곰곰히 생각해보면...

Hit Ratio 라는게 instance가 시작된 이후로의 평균값이므로 신뢰할 수가 없습니다. 즉, 0과 100점을 평균을 내버리면 50점이 나옵니다.

 단순히 오라클이 시작된 이후로의 총 평균값이 95%라고 나왔다고 하여... 문제가 없다고 볼 수는 없다는 논리입니다.

그러므로 특정 시점에서 Hit Ratio의 변동 추이를 추적해서 당시에 어떤 쿼리가 들어왔었느냐? 이런 부분에 대해서는 취약합니다.

 SGA는 실재론 상당히 Dynamic 하게 주식 현황처럼 빠르게 오르락 내리락하는데... 단순히 총 평균만으로 평가하면 오류에 빠집니다.

그래서 Delta Hit Ratio 분석법을 많이 사용합니다. 이 방법은 전체적인 평균값이 아닌 일정 시간 간격의 Hit Ratio를 측정하는 방법으로 훨씬 유용하고 신뢰도도 높습니다.

( 오렌지라는 국산 툴이 이러한 개념을 적용한 툴입니다.)

 

둘째... Buffer Cache Hit Ratio에서 측정하는 것은 Physical I/O에 대한 부분인데... 사실은 더 중요한 부분이 Logical I/O입니다.

 Physical I/O가 낮게 나오면 그럴 듯 하게 보이지만... 실재 내부적으로 SGA의 Buffer Cache 내에서 비효율적인 SQL이 많다면 불필요한 Logical I/O를 많이 일으킵니다. 이러한 전통적인 방법으로는 오히려 더 중요한 Logical I/O 측정이 안됩니다.

 각 종 튜닝 서적에서 OLTP업무에서 Buffer Cache Hit Ratio가 95% 이하면 늘려라라고 되어있는데...

정말 가장 쓰레기 같은 정보로 무시해버리는게 낫다는게 제 지론입니다. (저는 이런 식의 튜닝을 "밑빠진 독에 물붓기" 튜닝이라고 부릅니다.)

 

버퍼 캐쉬 Hit Ratio가 낮게 나오는 것은 둘 중에 하나입니다. 정말로 Buffer Cache를 지극히 작게 잡았을 경우... 그러나 오라클 엔지니어가 설치할 때 어느 정도 최적화된 크기로 설치를 하게 되므로 정말로 작게 잡혀서 문제가 되는 경우는 드뭅니다. 더구나 요즘 메모리 가격이 싸기 때문에 아주 소형 서버임에도 2G-4G 달고 있는 경우를 흔하게 봅니다.

  

정말 중요한 것은... 최적화 되지 않은 SQL과 색인을 제대로 만들어두지 않아서... Buffer Cache를 흥청망청 쓰는 망나니 SQL들입니다.

 이 망나니 SQL들을 찾아내서 소탕작전을 펼치는 것이 중요하지... 일단 메모리 늘리고 보자는 답이 전혀 아닙니다.

(순서가 뒤바뀐 셈이죠.)

 

이렇게 SQL을 튜닝하고 적절히 색인을 생성해주고 나서도 낮게 나온다면... 그 때가서야 Buffer Cache Size를 늘려주면 됩니다.


출처 : http://blog.naver.com/comgen27/20005040231