|
이 기사에서는 서브쿼리 액세스 분석 시간으로 '단순 서브쿼리의 후수행시의 트레이스'에 대한 정보를 얻을 수 있다.
지면 관계상 생략된 자세한 내용은 밑의 첨부된 PDF 파일을 다운로드 하면 얻을 수 있다.
제１장 연결액세스 분석 II : SUB-QUERY
관계형 데이터베이스를 사용하면서 여러 테이블을 통해 흩어져 있는 정보 릴레이션을 조합하여 목표릴레이션을 만들기 위해서는 반드시 조인을 사용하여야 한다는 강박관념에서 벗어나야 한다. SQL을 통해 목표릴레이션을 만들어 내는데 있어서 관계형 데이터베이스는 다양한 형태의 데이터 연결방법을 제공한다. 이 장에서는 그런 데이터 연결의 한 방법으로써 SUB-QUERY의 이용에 대하여 설명한다.
제1절 단순 서브쿼리의 후수행시의 트레이스
서브쿼리는 먼저 수행하여 메인쿼리로 연결이 이루어 질 수도 있고, 메인쿼리를 먼저 수행한 다음 서브쿼리로 연결이 이루어 질 수도 있다. 서브쿼리에 메인쿼리의 컬럼이 존재하지 않는 단순 서브쿼리의 경우는 실행계획을 통해 보면 메인에서 그냥 조인을 한 경우와 비슷한 형태로 나타난다.
아래의 쿼리를 통해 사용자가 의도하는 실행계획의 모습이 조건의 SALEDATE ,1998년 1월을 액세스한 다음 서브쿼리로 연결되는 형태로 처리를 예측했다면 사용자가 의도했던 모습과는 조금 차이가 있다. 그것은 서브쿼리 안에 존재하는 CUST_CODE 조건 때문에 메인에서도 똑같이 이 조건이 반영되어 SALE TABLE의 PK 인덱스를 사용하지 못하고 오히려 더 넓은 범위의 SALE_CUST_SALEDATE_IDX 인덱스를 사용하게 된 것이다.
select *
from sale
where saledate like '199801%'
and cust_code in (select cust_code
from customer
where cust_code between 'C30100' and 'C30200')
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0 0 0 0 0 0
Fetch 63 1.82 1.82 0 12926 0 6200
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 63 1.82 1.82 0 12926 0 6200
Rows Execution Plan
------- ---------------------------------------------------
SELECT STATEMENT
6200 NESTED LOOPS
6200 TABLE ACCESS BY INDEX ROWID :SALE
24401 INDEX RANGE SCAN :SALE_CUST_SALEDATE_IDX(NU)
6200 INDEX UNIQUE SCAN :PK_CUSTOMER (U)
사실 이쿼리는 ‘saledate like '199801%'’ 조건을 살리기 위해 서브쿼리가 먼저 수행되어 SALE_CUST_SALEDATE_IDX INDEX의 일량을 정확하게 액세스 할 수 있도록 하는 것이 더 일량의 측면에서 튜닝된 실행계획을 보여준다. 아래의 경우를 확인하기 바란다
select /*+ INDEX(A SALE_CUST_SALEDATE_IDX) */
*
from sale a
where saledate like '199801%'
and cust_CODE in (select cust_CODE || ''
from customer b
where cust_CODE between 'C30100' and 'C30200')
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0 0 0 0 0 0
Execute 1 0 0 0 0 0 0
Fetch 63 1.02 1.02 0 6610 0 6200
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 63 1.02 1.02 0 6610 0 6200
Rows Execution Plan
------- ---------------------------------------------------
SELECT STATEMENT
6200 NESTED LOOPS
101 VIEW SYS.
101 SORT UNIQUE
102 INDEX RANGE SCAN :PK_CUSTOMER (U)
6200 TABLE ACCESS BY INDEX ROWID :SALE
6301 INDEX RANGE SCAN :SALE_CUST_SALEDATE_IDX(NU)
최초의 쿼리에서 메인쿼리 액세스 일량을 분석하기 위해 다음과 같은 3가지 쿼리를 수행시켜 보자.
select count(*) from sale
where cust_code between 'C30100' and 'C30200';
COUNT(*)
----------
24400
select count(*) from sale
where saledate like '199801%';
COUNT(*)
----------
6200
select count(*) from sale
where saledate in (select testdate
from datetab
where testdate like '199801%')
and cust_code between 'C30100' and 'C30200'
COUNT(*)
----------
6200
이 3가지의 쿼리의 결과로 보면 메인절을 먼저수행한다는 가정을 하면, PK_SALE 인덱스를 사용하여 해당범위의 날짜에 해당하는 데이터를 먼저 액세스하여 서브쿼리를 연결하는 것이 일량의 측면에서 가장 최적의 실행계획이 될 것이라고 생각할 수 있다. 그렇다면 왜 OPTIMIZER는 이러한 최선의 선택을 하지 못한 것일까. 지금 저자가 갑작스레 OPTIMIZER의 실행계획 선택에 대해 언급하는 이유는 이절의 마지막 부분에서 이해가 될 것이다. 아무튼 OPTIMIZER가 위와같은 선택을 한 이유를 분석해 보자. 최초의 쿼리에 대해 OPTIMIZER는 쿼리를 다음과 같이 변형한다.
계속...
첨부된 문서에는 다음과 같은 정보가 담겨져 있다. - 연결 액세스 조인 분석.PDF
제１장 연결액세스 분석 II : SUB-QUERY
제1절 단순 서브쿼리의 후수행시의 트레이스
제2절 단순 서브쿼리의 선수행시의 트레이스
제3절 CORRELATED QUERY의 ONE BUFFER 이용
１. 기본 개념과 비교를 위한 전제
２. SALE TABLE 경우의 ONE BUFFER 효과
３. SALE_CF TABLE 경우의 ONE BUFFER 효과
|
