월요금납부실적 테이블과 납입방법별_월요금집계 테이블이 있습니다.
월요금납부실적테이블은 고객별 납입방법별 납입요금을 컬럼 값으로 입력하고, 납입방법별_월요금집계 테이블은 납입요금을 납입방법코드별로 하나의 레코드로 입력하도록 하고 있습니다.
여기서 월요금납부실적 테이블을 이용해 납입방법별_월요금집계 테이블형태로 가공하는 배치프로그램이 필요하다고 가정하고 아래와 같이 PL/SQL을 작성하였습니다.
위의 쿼리의 문제는 과도한 데이터베이스 Call에 있습니다.
만약 처리해야 할 월요금납부실적이 100만 건이면 이 테이블에 대한 Fetch Call이 100만건, 납입방법별_월요금집계 테이블로의 insert를 위한 Execute Call이 최대 500만번, 따라서 최대 600만번의 데이터베이스 Call이 발생하게 됩니다.
그나마 PL/SQL문으로 코딩하면 네트워크 트래픽이 없는 Recursive Call이므로 제법 빠르게 수행되지만 C,JAVA,VB,Delphi 등으로 개발된 애플리케이션에서 네트워크를 경유해 수행할 때는 훨씬 문제가 심각해지게 됩니다.
(30000건의 데이터를 월요금납부실적 테이블에 insert 하고 PL/SQL과 JAVA로 각각 수행하여 성능을 비교하였습니다.)
PL/SQL : 7.26초 약 18만번의 Call 발생
JAVA 프로그램 수행 : 126.82초 약 30만번의 Call이 발생
Java에서 총 소요시간이 126.82초인데 반해 서버에서의 일량은 그에 훨씬 못미쳤습니다. 순수하게 서버에서 처리한 시간은 10여초에 불과하고 나머지는 네트워크 구간에서 소비한 시간, 그리고 데이터베이스 Call이 발생할 때마다 매번 OS로부터 CPU와 메모리 리소스를 할당받으려고 소비한 시간입니다. User Call이 Recursive Call에 비해 심각한 부하를 일으키는 이유가 여기에 있습니다.
One-SQL로 로직을 통합했을 때 극적으로 성능 개선이 이루어지는 원리가 데이터베이스 Call 횟수를 줄이는 데에 있습니다.
데이터베이스 Call 횟수를 줄일려고 One-SQL로 구현하는 것도 중요하지만 어떻게 I/O효율을 달성할지도 중요하다는 사실을 깨달아야 합니다. 효율을 고려하지 않은 One-SQL은 누구나 작성할 수 있으며, I/O효율의 핵심은 동일 레코드를 반복 액세스하지 않고 얼마만큼 블록 액세스 양을 최소화 할 수 있느냐에 달렸습니다.
'스터디 > 오라클 성능고도화 원리와 해법1' 카테고리의 다른 글
05.데이터베이스 Call 최소화 원리 - 05. Fetch Call 최소화 (2) | 2020.01.30 |
---|---|
05.데이터베이스 Call 최소화 원리 - 04.Array Processing 활용 (0) | 2020.01.29 |
05.데이터베이스 Call 최소화 원리 - 02.User Call vs. Recursive Call (0) | 2020.01.22 |
05.데이터베이스 Call 최소화 원리 - 01.Call 통계 (0) | 2020.01.21 |
04.라이브러리 캐시 최적화 원리 - 11.Static SQL 구현을 위한 기법들 (0) | 2020.01.20 |
댓글