많은 INLIST와 MULTIPLE OR 연산을 갖는 SQL의 OPTIMIZATION

Question

제품 : ORACLE SERVER
작성날짜 : 2004-04-19
많은 Inlist와 multiple OR 연산을 갖는 SQL의 Optimization
=========================================================
PURPOSE
이 문서는 IN 연산 내의 많은 IN List와 많은 OR 연산자를 갖는
경우에 CBO가 어떻게 처리하는가에 대한 자료이다.
Explanation
많은 개발자나 DBA들은 IN 연산자와 OR 연산자를 사용하는 SQL이
과도한 Optimization time을 야기시키는 문제를 경험했을 것이다.
이 문서에서는 CBO가 어떻게 IN list와 OR 연산자를 처리하는지
설명하고자 한다.
CBO가 IN list 연산을 만나면 다음과 같은 몇 가지 option을 가지고 판단한다.
1. SQL 문장을 UNION ALL 이 들어간 문장의 연속으로 나눈다.
SELECT empno FROM emp WHERE deptno IN (10,20,30);
라는 문장을 살펴보자.
이 문장은 다음과 같이 다시 쓰여질 수 있다.
SELECT empno FROM emp WHERE deptno = 10
UNION ALL
SELECT empno FROM emp WHERE deptno = 20
UNION ALL
SELECT empno FROM emp WHERE deptno = 30
만약 deptno column이 indexed된다면 index는 각 branch 단에서 loopup하기
위해 사용될 수 있다.
만약 split이 Cost Based Optimizer로 자동으로 발생하지 않는다면
USE_CONCAT hint 를 사용함으로써 강제로 수행될 수 있다.
이 내용에 대해서는 <Note:17214.1>을 참조하도록 한다.
2. IN list를 list로 남겨 두고, filter로서 값을 사용한다.
Oracle 7에서 이 옵션은 index를 사용할 수 없다.
Oracle 8에서 이 옵션은 index를 사용할 수 있는 'inlist iterator' 라는
것을 사용하여 제공된다.
NO_EXPAND hint를 사용함으로써 expand가 일어나지 않도록 CBO 에게 지정할 수 있다.
아주 긴 inlist는 CBO 환경에서 문제를 야기시킬 수 있다. 특히 inlist가 많은 수의
UNION ALL 문장으로 expand될 때 그러하다. 왜냐하면 CBO가 expand된 문장들에
대해서 Cost를 결정해야 하기 때문이다. 이러한 expand된 문장들은 많은 수의
branch 때문에 time을 소모하는 문장들이다.
RBO(Rule Based Optimizer) 환경에서는 이것은 cost 산정을 하지 않으므로 문제가
되지 않는다.
Workaround
만약 아주 긴 inlist 때문에 parsing 문제가 있다면 workaround는 다음과 같다.
1) NO_EXPAND hint를 사용하도록 한다. 이 힌트를 쓰면 Oracle 7에서는 index를
사용하지 않고, Oracle 8에서는 index를 사용할 수 있다.
2) RBO 를 사용하도록 한다.
3) Query를 재작성한다. Inlist가 lookup table에 저장이 되도록 해서
inlist를 사용하는 대신에 그 table에 join을 한다.
주의) hint를 사용하게 되면 CBO로 동작하게 됨을 기억해야 한다.
Example
none
Reference Documents
<Note:62153.1>

Answer 1