Tunning 개념

튜닝

Hardware 튜닝 -> 비용 ↑, 최후의 수단

SQL 튜닝 -> Hardware 튜닝 필요없이 성능 ↑, 비용 ↓

SQL 튜닝을 위한 선결과제

1. 물리적 환경

- 업무가 운영되기에 충분한 용량의 서버 용량 산정 및 환경 구축이 필요 (CPU, Memory, Network)

- SQL 특성에 맞도록 오라클 서버 튜닝 -> 오라클 패치 같은 작업, DB 메모리 및 I/O튜닝

- OS 튜닝, 오라클 서버가 운용되는디 필요한 기본적인 리소스 파라미터 튜닝

2. 설계 중 과제

- 업무 기능 분석 및 설계

- 업무를 자아 잘 표현하는 단순 명료한 데이터 모델이 필요 -> 업무 분석 및 업부 범위의 명확한 구분이 필요

튜닝에 필요한 파일들

1. Alert Log File 

2. Background Process Trace File 

문제시마다 생성되서 여러개가 생성됨, 파일 이름으로 어떤 프로세스인지 구별 가능

3. User Trace File

user request에 의해서 생성됨, 역시 여러개가 생성

eg) alter database backup controlfile to trace as ' ' --> 이런식으로 만드는 trace file을 말함

일반적 튜닝 과정

원하는 목표치까지 반복적으로 튜닝: 원인분석 -> 조치(튜닝) -> 점검

튜닝 후에도 시스템 상황은 항상 변화, 시간이 지나면서 사용자 및 서버 데이터량 증가 등으로 계속 조치 

즉, 튜닝 포인트에 대한 표준이 없기 때문에 원하는 결과가 나올 때까지 계속 해줘야 한다. (장기적 관라)

3가지 접근 방법

부하의 감소: 동일한 부하를 보다 효율적인 방법으로 수행, 일반적인 SQL 튜닝

부하의 조정: 부하 정도에 따라 업무를 조정, 시간대별, 응용 프로그램별로 조정

부하의 병렬 수행: 병렬로 수행해서 응답 시간을 단축, 주로 배치 업무에 많이 사용된다.

튜닝 실패

SQL 튜닝을 해도 호전 되지 않는 경우

업무 설계, 모델링이 잘못 됬을 경우

시스템 사이징 실패

개발 중 모델 및 스키마 변경

비효율적 스키마 및 프로세스 흐름