<오라클 성능 고도화 원리와 해법1> Ch05-03 데이터베이스 Call이 성능에 미치는 영향

오라클 성능 고도화 원리와 해법1 - Ch05-03 데이터베이스 Call이 성능에 미치는 영향

그림 5-3에 두 테이블이 있다. 데이터 모델을 보고 쉽게 짐작할 수 있듯이 ‘월요금납부실적’ 테이블은 고객별 납입방법별 납입요금을 컬럼 값으로 입력하고, ‘납입방법별_월요금집계’ 테이블은 납입 요금을 납입 방법 코드 별로 하나의 레코드로 입력하도록 하고 있다.

기간계 시스템에서는 요금 납부 실적을 주로 고객 별로 조회하므로 흔히 좌측과 같이 모델링하는 반면(그렇게 하는 게 낫다는 뜻은 아님), 정보계 시스템에서는 다차원 분석을 많이 하므로 우측과 같이 납입 방법 코드를 PK로 끌어올리는 것이 일반적이다. 이처럼 기간계와 정보계 시스템이 서로 다른 데이터 모델을 사용하기 때문에 발생하는 데이터 가공 요건은 매우 흔하며, 여기서는 ‘월 요금 납부 실적’ 테이블을 이용해 ‘납입 방법 별_월 요금 집계’ 테이블 형태로 가공하는 ETL 배치 프로그램이 필요하다고 가정하자.

개발 초기에는 소량의 테스트용 데이터만으로 프로그램을 수행하여 무리 없이 돌아가지만 프로젝트가 통합 테스트 단계로 접어들어 실 데이터들이 이관되기 시작하면 갑자기 문제가 심각해진다. 밤새 돌고도 아침까지 끝나지 않는 프로그램들이 부지기수다. 무엇이 문제인가? 문제는 과도한 데이터베이스 Call에 있다.

만약 처리해야 할 월 요금 납부 실적이 100만 건이면 이 테이블에 대한 Fetch Call이 100만 번(Array 단위 Fetch가 작동하지 않을 때), 납입방법별_월요금집계 테이블로의 insert를 위한 Execute Call이 최대 500만 번, 따라서 최대 600만 번의 데이터베이스 Call이 발생하게 된다. (4장에서 설명했듯이, PL/SOL에서는 커서를 자동으로 캐싱하므로 insert를 위한 Parse Call은 소량만 발생한다.)

그나마 위처럼 PL/SQL 문으로 코딩 하면 네트워크 트래픽 없는 Recursive Call이므로 제법 빠르게 수행된다. 하지만 C, JAVA, VB, Delphi 등으로 개발된 애플리케이션에서 네트워크를 경유해 수행할 때는 문제가 아주 심각해진다.

필자의 로컬 PC에서 앞서 본 PL/SQL 문으로 수행했을 때, 7.26초가 소요되었다. 아래는 그 때의 SQL 트레이스 결과이고, select와 insert를 합쳐 총 18만 번 가량의 데이터베이스 Call이 발생한 것을 알 수 있다.

반면, JAVA 프로그램을 수행할 때는 무려 126.82초가 소요되었다. 아래는 그 때의 SQL 트레이스 결과이고, 총 303,000번 가량의 데이터베이스 Call이 발생한 것을 알 수 있다.

주목할 것은, JAVA에서 총 소요시간이 126.82초인데 반해서 버에서의 일량은 그에 훨씬 못미친다는 사실이다. 순수하게 서버에서 처리한 시간은 10여초에 불과하고 나머지는 네트워크 구간에서 소비한 시간, 그리고 데이터베이스 Call이 발생할 때마다 매번 OS로부터 CPU와 메모리 리소스를 할당받으려고 소비한 시간이다. User Call이 Recursive Call에 비해 더 심각한 부하를 일으키는 이유가 바로 여기에 있다.

One-SQL로 통합하고 수행해 보면 1초가 채 걸리지 않는다.

다음절에서 설명하는 Array Processing 기법을 활용하면, DBMS 외부에서 수행되는 JAVA 같은 프로그램에서도 네트워크 트래픽을 획기적으로 줄여줘 굳이 One-SQL로 작성하지 않더라도 같은 수준의 성능 개선 효과를 얻을 수 있다. 이 사실은, One-SQL로 로직을 통합했을 때 극적으로 성능 개선이 이루어지는 원리가 데이터베이스 Call 횟수를 줄이는 데에 있음을 반증한다.

데이터베이스 Call 횟수를 줄이려고 One-SQL로 구현하는 것도 중요하지만 어떻게 IVO 효율을 달성할지도 중요하다는 사실을 깨달아야 한다. 효율을 고려하지 않은 One-SQL은 누구나 작성할 수 있으며 T O효율의 핵심은 동일 레코드를 반복 액세스하지 않고 얼마만큼 블록 액세스 양을 최소화할 수 있는가에 달려있다.