성능고도화 4-3. 뷰 Merging

뷰 Merging 이란 

 - 뷰 Merging과 다음 절에 설명하는 조건절 Pushing이 불가능한 형태의 뷰를 사용했을 때 

   성능이 느려지기도 하므로 뷰 때문에 쿼리 성능이 더 느려진다는 말도 전혀 틀린 말은 아니다. 

   하지만 악연한 경험치를 가지고 뷰사요을 꺼리는 것보다는 옵티마아저의 쿼리 변환 원리를 

   정확히 이해함으로써 적절한 때에 뷰를 사용할 수 있어야 한다. 

단순 뷰 Merging 

 - 조건절과 조인문만을 포함하는 단순 뷰는 no_merge 힌트를 사용하지 않는 한 언제든 

   Merging이 일어난다. 

 - group by 절이나 distinct 연산을 포함하는 복합 뷰는 파라미터 설정 또는 

   힌트 사용에 의해서만 뷰 Merging이 가능하다. 

 - 또한 집합 연산자, connect by, rownum등을 포함하는 복합뷰는 아예 뷰 Merging이 불가능 

복합 뷰 Merging 

 - 복합 뷰는 ' _complex_view_merging ' 파라미터를 true로 설정할 때만 Merging이 일어난다. 

     ● group by 절 

     ● select-list 에 distinct 연산자 포함 

 - 8i에서는 _complex_view_merging 파라미터의 기본 값이 false 이므로 기본적으로 복합 뷰 

   Merging이 작동하지 않는다. 복합 뷰 Merging을 원할 때는 merge 힌트를 사용해야만 한다. 

 - 9i부터는 이 파라미터가 기본적으로 true로 설정돼 있으므로 동일한 결과가 보장되는 한 

   복합 뷰 Merging이 항상 일어난다. 

 - 10g에서도 복합 뷰 Merging을 일단 시도하지만, 원본 쿼리에 대해서도 비용을 같이 계산해 

   Merging 했을 때의 비용이 더 낮을 때만 그것을 채택한다. 

 - 복합 뷰 Merging 을 아예 사용할 수 없는 경우 

   ( 파라미터 값이 변경된다고 하더라도) 

    ● 집합(set)연산자 (union, union all, intersect, minus) 

    ● connect by 절 

    ● ROWNUM pseudo 컬럼 

    ● select-list에 집계 함수 (avg, count, max, min, sum) 사용 

         ( group by 없이 전체를 집계하는 경우를 말함 ) 

    ● 분석함수 

         ( rank 함수 등의 함수와 집계 함수에 over가 붙은 형태)  

비용기반 쿼리 변환의 필요성 

 - 다른 쿼리 변환은 대게 더 나은 성능을 제공하지만, 복합 뷰 Merging은 그렇지 못할 때가 많다. 

 - 비용기반 쿼리 변환이 휴리스틱 쿼리 변환보다 고급 기능이긴 하지만 

   파싱 과정에서 더 많은 일을 수행해야만 한다. 약간의 하드 파싱 부하를 감수하더라도 더 나은 

   실행계획을 얻으려는 것이므로 이들 파라미터를 off 시키는 것은 바람직하지 않다. 

 - 실제로 10g에서 조인 조건 Pushdown 기능이 비용기반 쿼리 변환으로 바뀌면서 쿼리 성능이 

   느려지는 경우가 자주 발생한다. 이때는 문제가 되는 쿼리 레벨에서 힌트를 이용해 

   파라미터를 false로 변경하면 된다. 

Merging 되지 않은 뷰의 처리방식 

 - 어떤 이유에서건 뷰 Merging이 이루어지지 않았을 땐 2차적으로 조건절 Pushing을 시도한다. 

   하지만 이마저도 실패한다면 뷰 쿼리 블록을 개별적으로 최적화하고, 거기서 생성된 

   서브플랜을 전체 실행계획을 생성하는 데 사용한다. 실제 쿼리를 수행할 때도 뷰 쿼리의 

   수행 결과를 엑세스 쿼리에 전달하는 방식을 사용한다.