주요 조건절이 2개 테이블에 분산된 경우, 인덱스만으로 2개 테이블을 조인하고, 주요 조건절을 모두 사용한 후, 그외 사용해야 할 조건절과 컬럼값 획득을 위해 테이블을 액세스하도록 함으로써 테이블 액세스량을 크게 줄인다(여기서는 오라클의 INDEX JOIN과는 다른 개념으로 사용함)
개선 전
- (문제 상황) 거래기본 및 계약기본 데이터를 많이 액세스하였고, 거래기본, 계약기본, 상품기본 순서대로 조인하면서 결과건수가 216천건->2124건->698건으로 점차 감소함 (최종 30건은 그룹핑 결과임)
- (문제 원인) 액세스 범위를 크게 줄일 수 있는 조건절에 처리기준일자 컬럼이 포함되어 있으나 그것 만으로는 액세스 범위를 충분히 줄이지 못해 거래기본 테이블 액세스량이 많음
개선 방안(1/2)
- (수정 전) 216천건 만큼의 거래기본 테이블 랜덤 액세스가 성능에 문제됨
- (수정 후) 거래기본 테이블에 대한 랜덤 액세스를 줄이기 위해, 인덱스 만으로 상품기본과 1차 조인하고, 그 이후 거래기본 테이블을 액세스하도록 함(756회로 크게 감소)
개선 방안(2/2)
- (개선 방안) SQL문 수정을 통해 거래기본 인덱스와 계약기본 인덱스 조인으로 결과 집합 범위를 충분히 줄인 후 거래기본 테이블을 랜덤 액세스 하도록 함으로써 거래기본 테이블 랜덤 액세스 량과 소요시간을 많이 줄어들도록 함
- 인라인뷰 CS 내 처리 시 거래기본 테이블 랜덤 액세스가 없도록 하는 것이 튜닝의 주된 포인트이며, 이를 위해, 인라인뷰 CS 내 사용 가능한 거래기본 테이블 컬럼은 처리기준일자, 참조번호 등 IX12 인덱스 구성 컬럼으로 제한해야 함
개선 후
- (개선 결과) 새롭게 작성한 인라인 뷰 처리 결과 756건 만큼만 거래기본 테이블을 랜덤 액세스함
- 인라인뷰 부분으로서, 뷰 바깥의 거래기본 부분과 합치더라도 개선 전 보다 액세스량과 소요시간이 현저히 감소함
- 거래기본 테이블에 대한 액세스 없이 IX12 인덱스만 액세스하였고, (테이블 액세스와 비교할 때) 로우 수에 비해 액세스 블록이 많지 않고, 액세스한 논리 블록 수에 비해 물리 블록 수가 많지 않다는 사실에 유의
※ 참고 사례
개선 전
- (문제 상황) 액세스 범위를 크게 줄일 수 있는 조건절이 고객번호 및 지급일자 컬럼 조건절인데, 이 두 컬럼이 2개 테이블로 분산되어 있는 경우 조인 순서 변경을 통한 최적화에 한계가 있음
- (문제 원인) 다시 말해, 현 조인 순서로는 지급일자 조건절이 테이블 filter 조건이 되어 송금기본 테이블 블록을 많이 액세스하고 있는데, 만약 NL 조인 순서를 바꾸게 되면, 지급일자 조건절이 인덱스 access 조건이 되어 송금기본 테이블 블록을 적게 액세스 하지만 대신, 인덱스 access 조건이었던 고객번호 조건절이 테이블 filter 조건이 되어 외환기본 테이블 블록을 많이 액세스 해야 함
개선 후
- (개선 방안) USE_HASH 힌트로 NL 조인 대신 해시 조인이 수행되도록 함
- (개선 결과) 비록 지급일자와 고객번호 조건 모두 인덱스 access 조건이 되었지만, 고객번호 조건 결과가 20만건이나 되어 충분한 성능이 나오기 어려울 수 있으나 마침 외환기본_IX01 인덱스만 읽어도 되는 경우(예외적인 경우)여서 해시조인이 상대적으로 유리해 졌음
댓글
댓글 쓰기