메뉴 건너뛰기

bysql.net


1.2.1 DBA들이 튜닝에 실패하는 이유(취약점) : 저자 통계치


- 5년간 통계치                                - 최근 2년간

1위 QT에 대한 지식 부족                        (49%) --> (53%) 4증가

2위 업무 관점의 접근 및 정확한 업무 파악 부족     (25%) --> (26%) 1증가

3위 Wait Event에 대한 지식 부족                (15%) --> (10%) 5감소

4위 신기술에 대한 지식 부족 혹은 두려움           (8%) -->  동일

5위 잘못된 액세스 패턴 * 조인 방법 * 조인순서     (3%)  --> 동일


- 위와 같이 저자의 통계치에 나온 QT에 대한 지식 부족이 계속적으로 증가하는 이유는

   Logical Optimizer에 대한 교재 및 튜닝 메뉴얼 등 정보에 대해 너무나도 취약하다.

1.2.2 이제는 Optimizer 다.(각 시기별 출간된 책들의 트랜드)


1. 1990년대    : SQL의 효율적 작성법, Access Path, 조인, Object 최적화
2. 2000년대    : OWI, RAC
3. 2010년 이후 : 옵티마이져의 내부에 대한 연구(Logical * Physical Optimizer)가 예상


* 참고 (고도화 원리화 해법 1 : 대기이벤트, RAC 캐시 퓨전)

   - OWI(Oracle Wait Interface)

    프로세스들의 I/O, 락, 래치 등 각각의 프로세스들에 대한 획득, 점유, 해제에 대한 대기 현상을 기록하고(통계수집)

    조회하여 부하가 생기는 시점을 확인 및 튜닝 포인트를 추적할 수 있는 성능 추적 방법론이라 할 수 있다.

   - RAC(Real Application Cluster)

    물리적인 하나의 데이터베이스를 여러대의 서버가 공유하는 것으로서, 동일 데이터베이스를 여러 인스턴스가

    접근할 수 있다.

1.2.3 패러다임의 전환이 필요해.


- Physical Optimization의 원리
   인덱스 * 조인방법 * 조인순서의 선택 등 Physical Optimizer의 행동분석하는 데에는 적합하지만

   실전 튜닝에서는 활용도가 떨어진다.

   즉, Physical Optimization의 결과물인 Cost를 계산하면서 SQL을 튜닝하는 사람은 거의 없기 때문이다.


- Logical Optimization의 원리
   SQL 자체를 변경시키기 때문에 성공/실패의 여부에 따라 SQL의 성능에 지대한 영향을 끼친다.
   따라서 Logical Optimizer를 Control 할 수 있어야한다. 직접 튜닝 하는것에서 벗어나 Logical Optimizer에게

   SQL 튜닝을 맡기고 그 한계를 드러내는 경우 옵티마이저에게 더 좋은 방법을 가이드 하는것이 튜너역할이 되었다.



The Logical Optimizer  (bysql.net 2011년 2차 스터디)
작성자: 김범석 (darkbeom)
최초작성일: 2011년 8월 28일
본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
문서의 잘못된 점이나 질문사항은 본문서에 댓글로 남겨주세요. ^^