사례  
- 대형 온라인 쇼핑몰 ‘Y’사의 경우 Peak Time시 사용하고 있는 대형 엔터프라이즈 급의 머신이 CPU 사용률 70% 이상에 육박하는 과부하 상황에 처해있다. 추후 추가되는 서비스와 나날이 증가하는 고객에 대해 확장성을 전혀 보장 받을 수 없는 상황이다. 이 업체는 수억이 넘어가는 추가 하드웨어 업그레이드를 계획하고 있다.
- 온라인 업체 ‘E’사 : DB 서버의 과부하로 인해 주기적으로 시스템을 리부팅해야 하는 상황이다.


귀하의 회사도 그렇지 않습니까? 하드웨어 사양이 불충분해서 혹은 OS를 잘못 선택해서 어플리케이션 서버가 좋지 않아서… 더 좋은 프로그램 언어를 선택하지 않아서? 이러한 문제를 겪고 있다고 생각하십니까?


똑같은 결과를 내는 SQL이지만 전자는 10개의 Logical Block I/O 만으로 처리하는 데 반해서, 후자는 10000개의 Logical Block I/O와 다량의 Physical I/O를 동반하며 수행 시간이 10배가 넘게 걸린다면???


이러한 상황은 그대로 놔두고 하드웨어 증설만으로 문제를 해결하려고 하기 때문에 비용대비 효과를 전혀 볼 수 없는 상황에 처하고 있다.


아직까지 국내 개발자들은 DBMS에 대한 불충분한 이해와 잘못된 모델링, 그리고 최적화 되지 않은 SQL 구사로 시스템 과부하를 초래하고 있다. 또한 종합적인 Access pattern 분석에 따른 Index 구성이 아니라 그 때 그 때 필요에 의해 Index를 추가하다보니 시스템의 트랜잭션 성능을 현저하게 떨어뜨리며 시스템 과부하를 자초하고 있다.


DBMS 튜닝은 결국 비용 대비 가장 효과적인 방법이며 미래의 증가되는 서비스에 대한 충분한 확장성을 보장받으며 고객의 신뢰를 잃지 않을 수 있는 Solution이다.

 

Hard parsing Overhead 해결

 

SQL은 수행시 parse, execute, fetch 단계로 수행되어지며 parse 단계에서는 문법검사, 권한체크, 실행계획 수립등의 다양한 작업을 거치며 한번 파싱된 정보는 Shared pool에 저장되어 재사용 되어진다.
그러나 BIND 변수 미사용으로 인해 한번 Parse된 정보가 재사용되지 않고, 매번 CPU 집약적인 Hard parsing을 유발하게 되며 이는 공유 메모리에 Latch등 직렬화 장치를 사용하므로 동시접속이 증가하면 할수록 시스템 성능을 떨어뜨리며 확장성을 저해하게 된다. 

<그림1> BIND 변수 미사용으로 550M의 Shared pool의 Free Mem영역이 급격히 줄어드는 모습

<그림 2> Hard Parsing으로 CPU 파워의 대다수를 사용하는 모습(파란색부분)

 

SQL 튜닝

 

진단방법 : SQL_Trace 를 통해 1초 이상 수행되는 모든 SQL을 추출한 후 특정 자원을 기다리는데 소요한 wait 현상, 잘못된 SQL 구사로 인한 성능 저하, Index 불량등의 현상을 체크

 

해결 : 보다 자원을 적게 사용하고도 동일한 결과를 내도록 SQL 재작성, Hint 추가나 Index, Cluster 구성으로 Access 속도 개선.  Enqueue등 시스템 Lock 현상 체크, 각종 Wait 현상의 해결(Buffer Busy waits)

 

Index 전략 수립

 

진단방법 : 해당 테이블을 엑세스하는 모든 SQL을 추출하여 최소한의 인덱스만으로 모든 SQL을 만족시키도록 종합적인 인덱스 전략 수립

 

해결 : DML 성능 개선, Redo Log 발생량 최소화, I/O 성능 개선

 

DBMS Instance 튜닝

 

 아키텍쳐 상의 결정 : Connection Overhead : 매 Client요청마다 오라클 Processes의 생성, 소멸 반복으로 오버헤드 초래 -> Connection pooling (JDBC, ODBC, PHP) or Shared Server 구성

 

최적의 I/O 성능을 위한 재구성 : RAID 레벨 조정(Arch, LGWR는 RAID-5 처럼 쓰기가 느린 디스크에 두지 않는다.), Checkpoint 간격 조정, Direct I/O 및 비동기 I/O를 통한 I/O 성능 극대화

 

SGA 메모리 재 구성 : 튜닝 후 Workload에 따라서 Shared pool, log_buffer, Large pool, buffer cache Size 조정, Keep, Recycle Buffer 사용

 

오라클 파라미터 조정: 데이터 사용 목적에 부합하는 파라미터 설정

 

옵티마이저 설정 : Optimizer_mode 설정, 통계정보 구성 전략 수립(통계 sample %, 통계정보 생성 주기, 히스토그램 생성)

 

- 예상 소요시간 : 최소 한달 이상 소요되며… 위의 튜닝 항목에서 특정 항목에 대해서만 서비스를 받을 경우 1주일 이상 소요된다. (예를 들면 악성 top 10 SQL 튜닝만 수행할 경우)


- 비용 : 업무의 복잡도와 SQL 수량, 오라클 인스턴스의 개수에 따라서 별도 산정 (상세 비용은 견적 문의 바람)