그림 3-11에서 소개했던 0.2초 이상 소요되는 SQL 수행 비율을 다시 한 번 살펴보면 1. 리플레이를 수행하며 패치하는 과정에서 성능이 1차적으로 개선되었고 부족한 부분은 2. SQL을 최적화함으로써 외산 DBMS 수준과 유사하게 성능을 개선한 것을 확인할 수 있다.

그렇다면 각 두 번의 개선 단계에서 어떠한 이슈들을 처리했기에 목표 수준까지 성능이 향상될 수 있었을까?

• [그림 3-11] 0.2초 이상 SQL 수행비율
• 

먼저 패치과정을 통해 개선된 사항을 알아보자. SQL 수행 시간이 요청하는 데이터양 및 SQL의 복잡성을 고려했을 때 합리적이라는 의미는 DBMS의 옵티마이저(쿼리 최적화기)가 SQL이 원하는 데이터를 최소한의 데이터 블록만 읽고 처리할 수 있는 효율적인 플랜을 생성했다는 의미이다

따라서 외산 DB의 수준까지 SQL 수행 시간을 단축시키기 위해서는 티베로 옵티마이저를 개선하여 외산 DB만큼 효율적인 플랜을 생성할 수 있도록 하면 되므로 첫 번째 성능 개선은 리플레이를 재현하여 확인된 옵티마이저의 비효율 이슈^주2)를 만족스러운 결과가 나올 때까지 패치를 적용하며 처리하였다고 이해할 수 있다.

| 주2 | full table scan이 유리한데 index를 scan하거나 hash join이 유리한데 index join(외산 DBMS의 NL Join을 티베로에서는 index join이라 표현한다)이 적용되는 등 다양한 옵티마이저 비효율이 있을 수 있다.

그렇다면 옵티마이저 비효율이 발생한 이유는 무엇일까? 단순하게는 티베로가 외산 DBMS보다 아직은 많이 부족하기 때문일 것 같은데 과연 이것만이 이유일까? 다양한 의견이 있을 수 있겠지만 동일 제조사의 제품을 업그레이드하는 과정에서도 기존에 사용하던 SQL의 성능이 느려지는 옵티마이저 비효율이 발생할 수 있다는 사실을 고려할 때 처음 발생한 약 15%의 성능차이가 전적으로 티베로가 부족해서 발생했다고 보기에는 무리가 있을 것이라 생각된다.

또한 대부분의 옵티마이저 비효율이 발생한 소속 회사의 SQL이 다소 복잡하거나 구성이 잘못된 것이라는 점을 봐도 무조건 티베로가 외산 DBMS보다 좋지 않다는 해석은 문제가 있다고 생각한다.

그리고 어플리케이션 개발 프로젝트를 진행하는 모든 개발자가 DBMS의 충분한 이해를 가지고 효율적으로 SQL을 구현하기 보다는 정해진 업무요건에 알맞은 데이터를 추출하는데 집중을 할 수밖에 없으므로 15%의 성능 저하는 이러한 과정에서 생성된 복잡한 SQL을 처리하는 능력이 티베로가 다소 부족했다고 해석하는 것이 합리적이다.

다만 SQL이 아무리 복잡하거나 구성이 잘못되어도 외산 DBMS 만큼의 성능은 나올 수 있도록 티베로의 옵티마이저가 더욱 개선되는 노력은 반드시 필요할 것이다.

그리고 소속 회사의 프로젝트 과정 중에 보여준 1차 성능개선 결과가 그 노력의 일부이며, 시간이 지나 이러한 경험이 많아지면 외산 DBMS를 뛰어넘을 수 있다는 가능성을 보여준 것이라고 생각한다.

이제부터는 두번째 개선단계인 SQL 최적화 과정에서 처리된 이슈를 자세히 확인해보자. 앞에서 옵티마이저 비효율 이슈가 발생한 대부분의 SQL들은 다소 복잡하거나 구성이 잘못된 것이었다는 것을 밝혔고 그중 많은 부분을 옵티마이저 비효율을 개선한 패치를 통해 해결하였음을 확인하였다.

그리고 마지막 패치를 확정하고도 처리가 되지 않은 조금 더 복잡하거나 구성이 잘못된 나머지 SQL들이 본 장에서 얘기하고자 하는 성능저하 SQL들이다

외산 DBMS는 이 SQL들이 복잡하고 정상적이지 않은 구성이라고 하더라도 나름의 방법으로 합리적 시간을 소요하며 수행이 되는데 비하여 티베로는 외산 DB에 비해 보다 많은 시간을 소요하며 수행이 되어 SQL을 수정하여 성능을 개선할 수 밖에 없었다.

그러므로 향후에는 이러한 SQL들도 잘 수행이 될 수 있도록 티베로 옵티마이저가 개선되어야 하겠으며 동시에 옵티마이저 비효율이 발생할 수 있는 이러한 형태의 SQL을 티베로 전환을 검토하는 회사에서 사전에 효율적인 형태로 미리 변경해 둔다면 외산 DBMS에서도 보다 효율적으로 수행이 될 것이므로 성능향상에 도움이 되고 향후 전환 프로젝트도 조금 더 쉽게 수행이 가능할 것이다. 다음은 소속 회사에서 발생한 대표적인 성능 저하 패턴들이다. 하나하나 자세히 살펴보자