[오우경]Wiki와 Oracle Reference를 애용합시다!!

외근 나가계신 용범씨에게 전화가 왔다. 모 고객사의 장애 원인을 파악해달라고 하셨다.

사무실에 있었던 나는 고객사와 연락을 해서 원격 접속을 하고 어디가 이상한지 찾아보았다. 살펴보니 8월 12일자에 성능이 현저하게 떨어져있는 것을 발견했다. 그래서 해당일자 log를 열어보았고, 특정시점에서 active session이 높게 나타나고 성능은 떨어져있는 것을 확인했다. 그래서 전에 배웠던 대로 Stat Ratio Event를 찾아 보았고, 그 시점에 gc buffer busy 와 SQL *Net message from dblink가 대부분을 차지하고 있음을 발견할 수 있었다.

신입사원인 나에게는 아직 이런 지표들이 익숙하지 않고 확신이 서지 않았기에 WIKI와 Oracle Reference를 찾아보았다. 

잠깐 이 지표들을 살펴보자.

[ gc buffer busy ]
 Gc buffer busy 이벤트는 로컬 프로세스가 읽고자 하는 블록이 현재 리모트 노드의 요청에 의해 사용중임을 의미하는 이벤트이다. Gc buffer busy 이벤트는 Placeholder/Fixed-up의 분류의 따르지 않는 독립 이벤트이다.

 Gc buffer busy 이벤트는 buffer busy waits 이벤트나 read by other session 이벤트의 글로벌 버전으로 이해하면 된다. 서버 프로세스가 특정 블록을 사용하고자 하는 시점에 버퍼 락 경합이 발생하면 대기하게 되는데, 그 발생 사유에 따라 이들 대기 이벤트들 중 하나를 사용하게 된다.

[ gc buffer busy의 해결 ]
 Gc buffer busy 이벤트의 근본적인 발생 원인은 buffer busy waits 이벤트와 동일하며, 해결책 또한 동일하다. 핫 블록이 gc buffer busy 이벤트 발생의 가장 일반적인 원인이다. 따라서 문제가 되는 핫 블록을 분산시킴으로써 문제를 해결할 수 있다. 세그먼트 레벨의 파티셔닝 적용, 우편향 인덱스 현상의 해소, 시퀀스 캐시 크기의 증가, PCTFREE의 증가 등이 보편적으로 사용되는 방법이다.

 FLM을 사용하는 경우에는 세그먼트 헤더 블록이 버퍼 경합의 원인이 될 수 있다. 다행히 오라클 10g R2부터는 ASSM이 기본적으로 사용되기 때문에 FLM 환경에서 발생하는 성능 문제가 크게 줄어든다. 만일 FLM을 사용하는 환경이라면, 반드시 FREELIST GROUPS 속성을 노드 수와 동일하게 설정해서 세그먼트 헤더 블록의 경합을 최소화해야 한다.

[ SQL *Net message from dblink ]
 SQL *Net message from client 대기 이벤트는 원격 DB로부터 데이터를 전송 받아 대기할 때 발생한다. 일반적으로 해당 이벤트는 세션이 IDLE 상태라는 것을 의미한다.

 사용자와 상호작용 하지 않는 배치 프로그램에서 SQL *Net message from dblink 대기 이벤트의 대기시간이 과다할 경우, 이것은 애플리케이션 소스 코드가 비효율적으로 작성되었거나, 네트워크 레이어 부분이 문제일 수 있다. 따라서 해당 대기이벤트의 높은 대기시간에 의해 데이터베이스 성능이 저하되는 것은 아니다. 대기시간이 과다하다는 것은 성능상에 문제가 있다는 것을 감지할 수 있으나, 실질적으로 데이터베이스의 문제는 아니라는 것을 명확하게 알 수 있다.

음…..이렇게 지표 설명을 찾아보고 하면서….뭐가 제일 큰 문제일까?? 고민하기 시작했다. 무엇이 문제이더냐!!

해당 시점의 SQL도 확인해보고 alert.log도 확인 해 보았으나 별 문제가 없는 것 같았다.
현 시점의 I/O양도 적었고, SQL도 부하가 큰 것이 아니었다. 음….그럼 뭐가 문제여서 이 시점에서 성능이 떨어졌던 것일까?? 뭔가 딱 보이면 좋을텐데…;; 별 문제가 없어 보여서 다시 고민이 시작됐다.

그러던 중 갑자기 저 위에 밑줄 친 문장에 눈이 확~ 가는 것이 아닌가?? 아! 혹시…..DB가 아니라 네트워크에 문제가 있는 것은 아닐까??

혹시나 하는 마음에 담당자께 말씀 드려서 DB에 문제가 있는 것이 아니라 네트워크상에 문제가 있는 것 같다고 말씀을 드렸더니 확인 해 보신다고 말씀하셨다. 그래서 혹시 또 다른 문제가 있었나?? 초조해 하며 로그를 보고 있었더니 담당자한테서 연락이 왔다. 확인해보니 그 당시에 파이버 채널(Fibre channel)에 문제가 있었다고 말씀해주셨다. 다행히 예상했던 대로 네트워크 문제였고, 짧고도 긴 시간이었지만, 로그와 지표를 보면서 네트워크 문제인지 알아 낸 내 자신에게도 스스로 대견스러웠다.^^;;

Wiki나 Oracle Reference가 많은 도움이 된 것 같다. 여러분도 자주 애용하세요~*^^*

아직 많이 부족하지만, 틈틈이 이렇게 로그도 분석해보고 지표공부도 꾸준히 하면서 엑셈을 대표할 수 있는 DataBase Artist로 성장해야겠다.!! 오늘도 아자아자!!