[튜닝] 튜닝방법론

◆ SQL 튜닝 기술이 필요한 사람
  ◇ 설계자
    - SQL 튜닝 방법을 알고 있는 설계자가 쉽게 튜닝할 수 있는 스키마 설계 가능
  ◇ 응용프로그램 개발자
    - SQL 튜닝은 물론 물리적 구조 튜닝 병행
    - 성능 좋은 응용프로그램 개발
  ◇ 데이터베이스 관리자
    - SQL 튜닝 요구 및 해결 방법을 정확히 숙지


◆ 튜닝에 필요한 파일들
  ◇ Alert log file
    - DB상황, 오라클 인스턴스가 수행시 발생하는 에러 등을 기록함
    - 파라미터 파일의 background_dump_dest 파라미터로 설정
    - 노마운트 단계에서 기록을 시작함
  ◇ Background process trace file
    - 문제시마다 생성되므로 여러 개 생성됨
    - 파라미터 파일의 background_dump_dest 파라미터로 설정
    - 생성된 트레이스 파일명을 보면 어떤 프로세스가 생성한 파일인지 구분 가능
  ◇ User trace file
    - 유저의 요청에 의해 생성됨(여러 개 가능)
    - 파라미터 파일의 user_dump_dest 파라미터로 설정


◆ 일반적인 튜닝 과정
  - 원하는 목표치 까지 반복적으로 튜닝
  - 튜닝 후에도 예측하지 못한 튜닝 포인트는 계속 발생
  - 원인분석(부하), 조치(서버/SQL 튜닝), 점검(부하)의 과정을 반복


◆ SQL 튜닝의 3가지 접근 방법
  ◇ 부하의 감소
    - 동일한 부하를 보다 효율적인 방법으로 수행
    - 일반적인 SQL 튜닝
  ◇ 부하의 조정
    - 배치, 리포트 업무 등과 일반 업무(OLTP)를 분리
    - 응용프로그램 별, 시간대 별
  ◇ 부하의 병렬 수행
    - 병렬로 수행하여 응답시간을 크게 단축
    - 과도한 사용은 일반 사용자에게 악영향 가능성
    - 주로 배치 업무에 많이 사용됨


◆ SQL 튜닝을 해도 호전되지 않는 경우
  - 시스템 사이징 실패
  - 잘못된 데이터 모델링
  - 비효율적인 스키마 및 프로세스 흐름
  - 개발 중에 모델 및 스키마의 변경
  - 프로젝트 관리 미숙 및 과도한 요구
  - 업무 진행 중 SQL 튜닝 마인드 부재


◆ 요약

● SQL 튜닝은 개발 과정 상의 문제 해결 방법
  - 동일 부하를 효율적인 방법으로 변환
  - 부하의 대부분 원인은 비효율적인 개발
● 업무 설계, 모델링이 잘못되면 튜닝은 무의미
  - 측정 가능한 목표 설정
  - 설계에서 미리 효율적인 시스템 고려
  - 부적절한 리소스, 과도한 요구 배제
  - 개발 시작 이후, 뒤로 돌아가는 것은 금물