온라인 SQL 튜닝 전략

튜닝은 기술이면서, 동시에 행정이고, 외교이다. 시스템의 성능 문제를 분석하고 개선하기 위한 전문적인 기술은 필수이고, 내부 이해관계자의 다양한 요구 사항과 의견을 조율해야 하고, 때로는 외부 이해관계자와 첨예한 사안을 놓고 협상해야 할 수도 있다.

튜닝 이론으로는 얼마든지 성능 개선 가능하더라도, 실무에서는 기술적 주장 만으로 개선 방안이 적용되도록 밀어붙이는게 쉽지 않은게 현실이다. 다양한 주체의 다양한 이해관계를 풀어가기 위해서는 시스템 상태 뿐만 아니라, 이해관계자(특히 문제 원인에 귀책이 있거나, 개선방안을 적용하고 책임져야할 인프라팀이나 개발팀)의 상태도 함께 파악되어야 하고, 개선 방안을 작성하고 피력할때, 기술적인 내용 외에 이들을 잘 설득할 수 있는 함의(含意)를 담는 것은 노련한 SQL 튜너가 갖추어야할 기본적인 덕목이다.

다음은 튜닝 방법론의 일부라고도 할 수 있는 튜닝 전략 몇 가지를 소개한다. 

신속하고 정확한 튜닝을 위해, SQL 트레이스 결과 같은 구체적인 성능 자료를 우선 확보한다.

• 세그먼트/오퍼레이션 수준의 결과 로우수(Rows), 논리 읽기 블록 수(Buffers), 물리 읽기 블록  수(Reads)는 필수적인 성능 분석 기초 자료이다

경험적으로 보면, (온라인 처리 SQL) 트레이스 결과에서 주요하게 많은 시간이 소요된 부분은거의 한 두 곳에 불과하며, 그 부분을 집중적으로 분석하고 개선한다

• 사용자 체감 성능 또는 시스템 전체 자원 사용률에 별 영향을 주지 않는 소소한 개선은 설득력이 없고,  경제적이지도 못하다

문제의 근본적인 원인을 파악하여, 그것이 우선 해결되도록 한다

• 최적 실행계획을 만들기 위해 무작정 힌트만 사용할게 아니라, 옵티마이저가 왜 성능에 불리한  실행계획을 수립했는지? 보다 근본적인 원인을 파악한다
• 불필요하게 복잡한 쿼리문이 원인이라면, 쿼리문을 단순 명료하게 재작성하고,
• 최신 통계정보가 없어서 그렇다면, 통계정보를 재생성하고,
• 부적합한 DBMS 환경 설정값 때문이라면, 그 설정 값을 보완하고,
• 적합한 인덱스가 없어서 그렇다면, 인덱스를 신규 생성 또는 변경하고,
• 비정상적인 데이터 처리를 위한 예외 로직 때문이라면, 데이터 정제 노력을 우선 시도한다

다만 적용이 어려울 뿐, 성능 개선이 불가능할 수는 없다

• 문제의 원인을 정확히 파악했다면, 성능을 개선할 방법도 반드시 존재할 것이다
• 예를 들어, 데이터 구조 변경이나 정렬재구성을 운영 환경에서 당장 적용할 수 없더라도, 그것이 성능을  개선할 수 있는 유일한 방안이라면, 그 방안을 제시할 수 있어야 한다

최선이 어려우면 차선, 차선도 어려우면 차차선의 방안을 제시한다

• 예를 들어, 데이터 구조 변경을 통해 확실한 개선이 가능하나, 구조 변경을 할 수 없는 상황이고, 인덱스 신규 생성으로 상당 부분 개선 가능하나 그것마저 적용 불가한 상황이면, SQL 수정으로라도 개선할 수  있는 방안을 제시할 수 있어야 한다

SQL 개발자가 기본적인 SQL 튜닝을 수행하도록, 성능 목표를 구체화한다

• 구체적인 SQL/AP 성능 목표가 없으면, SQL 개발자의 노력이 오류 제거에만 집중되어, 통합테스트 시 성능 이슈로 큰 어려움을 겪을 수 있다
• 그냥 튜닝하는 사람은 닥친 성능 문제만 해결하고, 튜닝 고수는 여러 개를 묶어서 한번에 해결하고, 튜닝 초고수는 미래의 성능 이슈를 예견하고 미리 예방하는 조치를 취한다

튜닝은 ‘오류 수정’이 아닌 ‘성능 개선’ 개념으로 인식한다

• 튜닝은, 잘못을 질책하고, 오류를 수정하는 활동이라기 보다 이해관계자가 성능 개선을 위해 함께  노력하는 활동이다