아겔-_-의 뻘로깅

오라클은 그 역사만큼이나 수많은 시스템 파라메터가 존재하고 설정에 따라 그 실행양식은 천태만상으로 달라질 수 있습니삼. 오라클 설치라는건 단순히 프로그램을 카피하고 인스턴스를 만드는것 이상으로 해당 시스템에 대해 이러한 파라메터를 가능하면 자동적으로 설정해주는 역활도 약간은 있다고하삼.

우쨌든... '굴러가면 된거다'-_-라는 ㅈㄴ 무식한 관점을 철회하고 회사에서 서비스하는 프로그램을 튜닝하기 시작했었습니당. 최적화나 튜닝을 하시던 분이 나가시공(많이 배웠었죵.) 그냥 내비두고 살았드랬삼;; 거의 그분이 하셨던 일들은 execution plan을 파악하여 fullscan등을 없애시거나 이에 맞게 쿼리에 hinting을 주거나 적절하게 인덱스를 만들거나 하는 일들이었삼... 문제는 이렇게 튜닝을 시도한 쿼리들이 15개에서 20개정도의 테이블간의 조인이 있고(것도 cartesian product-_-;;;) 조건절의 대부분은 웹을 통해 엔드유져가 선택한 조건들을 반영하삼-_-;;; 결국 한두가지 상황에 대해서 바르게 힌팅을 하거나 인덱스를 조절하는것은 가능할지도 조금이라도 조건들의 조합이 달라지거나 하면 의미가 없어지고, 최악의 경우(어쩌면 대부분일지도-_-)에는 쿼리자체가 해당 조건들에 대해서 튜닝된거지 다른 조건들이나 대부분에 조건에는 더 나쁜 성능이 될수도 있다는점이었삼-_-;;;

저도 똑같은 작업을 몇일간 하였었삼. 하지만 하나의 화면일지라도 각기 다른 업무기준으로 움직이는 업체들간에 밸런스를 맞춰주기란 전혀 쉬운일이 아니었삼.(어떤 업체는 출고기준이 일자별이지만 또 다른 업체는 차수별로 나눌수도 있공... 등등등)

냐튼 이러한 접근법은 rbo에 근거하삼. rule based optimizer라고하능... 오라클이 지원하던 쿼리 최적화기의 하나이삼. 원리는 대단히 직관적이삼. 대상된 쿼리와 그와 연관된 자료구조들을 기반으로 몇가지 정규화된 규칙들을 쿼리에 적용하여 쿼리를 재구성하는 방식이삼. 이해하기 쉽고 이상적일수도 있는 느낌과는 달리 대단히 제한적이라고 생각되삼. 흔히 알려진 from절에서 테이블의 순서에 따라 그 실행시간이 천차만별이 된다거나 하는 결과적으로 개발자가 오라클 에뮬레이터가 되기를 요구하는 모습도 있삼;;; (테이블의 순서에 따라서 루프가 다르게 바뀔수있으니까...)

또다른 접근법은 cbo삼. cost based optimizer이삼.. 참 거추장스럽게 느껴질수도 있는 방식이삼. 이는 실제 데이터들에 대한 통계치(각 행의 블럭크기 등과 같이 말그대로 인덱스가 정확한 포인터인데 반해서 예측/보정이 필요한 수치들...)을 기반으로 해당 쿼리을 대체할 수 있는 실행시간에 제시된 대안쿼리들의 각 execution-plan의 단계별로 대상 자료와의 관계로 비용을 산출하고 이에 따라 비용가중치가 가장 적은 대안을 선택하는... heuristic한 방법이삼.

대부분의 오라클 튜닝/퍼포먼스 자료들은 몇년 묵은 자료들도 많고, 대부분 from에서 테이블의 위치나 count(*)가 유리한 점등을 중점적으로 다루고 있고-_-;; 이와 관련된 주제의 웹페이지들도 "rbo ==> 모든것을 직접 통제하는 완벽한 개발자에 어울리는 그야말로 남자의 길-모든 진정한 개발자는 이를 선호한다, cbo ==> 비용도 크고 겁쟁이 후로게이나 할짓."정도의 뉘앙스로 소개하는게 대부분이었삼;;;

하지만 저는 cbo을 적용했삼. 후로게이라서 땡긴걸수도 있겠고-_-;;; 우쨌든 각 테이블, 인덱스들에 대해서 ANALYZE문을 이용해서 통계치를 누적한 다음에 인스턴스 파라메터들을 조정하고 프로그램을 실행해봤삼... 결과는 놀라웠삼... 아무리 부하가 없는 시점이라도 2~3분이상 걸리던 쿼리-_-;;;가 10초 이내로 완료됐삼;;; 물론 성능이 더 나뻐진 부분들도 있었는데 이들은 대부분 힌팅이 잘못되어 문제가 생기는 부분들이었고 이들을 제거하여 복구하였삼.-_-;;; 추가적으로 주기적으로 해당 자료들에 대해서 통계만 내주도록 설정하는거 정도가 더 필요한 작업이었삼. 전 담당자는 과연 왜 이 방법을 안썼을까가 궁금해졌엇삼...;;;

...오라클은 (이미) rbo을 더 이상 지원할 계획이 없다고 하삼... 하위 호환성을 위해서 포함은 되겠지만 모든 개발과 지원은 cbo만을 할거라고...-_-;;;

...그냥 지금도 '모든것을 개발자가 예측하고 최적화하고 완벽한 프로그램을 만들어야한다'라거나... '재귀같은건 인륜에 어긋난다'...라거나... '모든것은 어셈블리로 구현할수있다. 어셈만이 살길'이라거나-_-;;; 그냥 그런게 참 얼마나 허위에 찬 소리인지 생각해보게해줬삼.

과연 그런 사람들이 'ghc 같은건 왠만한 최적화는 컴파일러가 알아서해줭. 그러니까 그런 환경에서는 가능하면 괴상한 코드나 튜닝을 적용하지 않고 단순히 정규화된 방법으로 프로그램을 표현하는게 더 바람직해...'라는 말이 얼마만큼 이해할까라는 생각도 들어지삼...

아-_- 무슨소리야... 꺄악;;;