'Oracle' 카테고리의 글 목록

PARTITION WISE JOIN이란 무엇인가?

Oracle/Data Join Method 2013. 5. 21. 06:00

부제: Partition Wise Join의 성능

DBA나 튜닝 컨설턴트들에게 PARTITION WISE JOIN(이후 PWJ)를 설명해 보라고 하면, 언제나 PARALLEL과 PQ_DISTRIBUTE 힌트를 언급한다. 이상한 일이다. PWJ는 PARALLEL + PQ_DISTRIBUTE 힌트 조합과 상관없이 독립적으로 존재한다. 그럼에도 불구하고 PWJ를 설명하기 위해 두 힌트를 항상 끌어들인다. 마치 PWJ 기능이 두 힌트에 종속되기라도 하는 것처럼 말이다. 그 이유는 메뉴얼을 포함한 거의 모든 튜닝책에 위의 두 힌트를 사용해서 PWJ를 설명하고 있기 때문이다.

말도 안 되는 소리
이제는 PWJ를 설명 할 때, PARALLEL과 PQ_DISTRIBUTE 힌트와 연계하여 설명하지 말기 바란다. 이렇게 연계하여 설명하는 것은 근본원리를 모르면서 활용하려고 하는 것이다. 더 잘못된 것은 성능이 개선되는 이유는 조인할 PARTITION을 미리 짝지어 놓았기 때문(Partition Pair)에 조인이 빠르다고 설명한다. 잘못된 설명이다. 성능문제의 대부분이 두 가지 관점(BLOCK I/O와 PGA 사용량)으로 결정된다는 것은 상식이다. 그런데 두 가지 관점을 설명하지도 않고 PARTITION을 미리 짝지어 놓았기 때문에 빠르다는 것은 어불성설이다.

지금까지의 PWJ의 정의를 과감히 버려라. 그리고 지금부터 PWJ를 재정의 해보자. PWJ를 다시 설명하지 않으면 다음의 세가지를 알 수 없다.

1. PARALLEL 힌트와 PQ_DISTRIBUTE 힌트를 사용하지 않고 PWJ를 설명 할 수 있다.
2. PWJ를 사용함으로써 개선된 성능을 BLOCK I/O로 나타낼 수 있다.
3. PWJ를 사용함으로써 개선된 성능을 PGA 사용량으로 나타낼 수 있다.

1. 번은 개념을 설명하는 것이다. 2,3번은 성능향상을 수치로 나타낼 수 있느냐는 것이다. 아마 기존의 상식으로는 힘들것이다. 따라서 이글의 목적은 위의 세 가지를 이해하고 나타낼 수 있는 능력을 기르는 것이다.

먼저 파티션 테이블 두 개(SALES_PT,SALES_ORDER_PT)를 만들고, 파티션이 되지 않은 테이블 두 개(SALES_NO_PT, SALES_ORDER_NO_PT)를 만든다. SALES_PT와 SALES_NO_PT의 차이점은 전자는 파티셔닝이 적용되고 후자는 적용되지 않았다는 것이다. SALES_ORDER_PT와 SALES_ORDER_NO_PT의 차이점도 마찬가지다.

테이블 생성 스크립트 다운로드

Table Generation.SQL

환경: 오라클 11.2.0.1
모든 테이블은 대략 92만 건이다.
SALES_PT, SALES_ORDER_PT 두 테이블의 파티션 키 컬럼은 TIME_ID 이다.

먼저 파티션이 되지 않은 테이블 두 개를 이용하여 HASH JOIN으로 실행해보자.

SELECT /*+ LEADING(T) */ COUNT(*)
FROM SALES_NO_PT S, SALES_ORDER_NO_PT T
WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')
   AND S.PROD_ID = T.PROD_ID
   AND S.CUST_ID = T.CUST_ID
   AND S.TIME_ID = T.TIME_ID
   AND S.CHANNEL_ID = S.CHANNEL_ID
   AND S.PROMO_ID = T.PROMO_ID  ;

------------------------------------------------------------------------------------------
| Id | Operation           | Name              | Starts | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                   |      1 |      1 |00:00:05.20 |    9898 |
|   1 | SORT AGGREGATE     |                   |      1 |      1 |00:00:05.20 |    9898 |
|* 2 |   HASH JOIN         |                   |      1 |    154 |00:00:05.20 |    9898 |
|* 3 |    TABLE ACCESS FULL| SALES_ORDER_NO_PT |      1 |     88 |00:00:03.12 |    5457 |
|   4 |    TABLE ACCESS FULL| SALES_NO_PT       |      1 |    918K|00:00:01.20 |    4441 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND "S"."TIME_ID"="T"."TIME_ID" AND
              "S"."PROMO_ID"="T"."PROMO_ID")
   3 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

파티션이 아님으로 PWJ가 발생하지 않았다. ID 4의 BLOCK I/O(Buffers)가 4441임을 주목하라. 또한 후행테이블의 건수(A-Row)가 918K임을 기억하라. 이제 PWJ 를 실행할 차례다.

SELECT /*+ LEADING(T) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | | 1 |00:00:00.18 | 6263 |

| 1 | SORT AGGREGATE | | 1 | | | 1 |00:00:00.18 | 6263 |

| 2 | PARTITION RANGE ALL| | 1 | 1 | 28 | 154 |00:00:00.18 | 6263 |

|* 3 | HASH JOIN | | 28 | | | 154 |00:00:00.18 | 6263 |

|* 4 | TABLE ACCESS FULL| SALES_ORDER_PT | 28 | 1 | 28 | 88 |00:00:00.10 | 5947 |

| 5 | TABLE ACCESS FULL| SALES_PT | 1 | 1 | 28 | 60608 |00:00:00.02 | 316 |

--------------------------------------------------------------------------------------------------------

Outline Data

-------------

/*+

BEGIN_OUTLINE_DATA

...생략

PX_JOIN_FILTER(@"SEL$1" "S"@"SEL$1")

END_OUTLINE_DATA

*/

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND

"S"."PROMO_ID"="T"."PROMO_ID")

4 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

조인된 두 테이블은 모두 파티셔닝 되었다. 따라서 PARTITION RANGE ALL이 두 번 나와야 됨에도 불구하고 ID 2을 보면 단 한번만 나온다. PWJ가 실행되었다는 증거다. PWJ가 실행되지 않은 경우와 BLOCK I/O를 비교해 보면 14배 이상 차이가 난다. 바로 이 것이 FULL PWJ가 실행되면 성능에 유리한 이유다. FULL PWJ가 실행되면 후행 테이블의 파티션을 모두 읽을 필요가 없다. 왜냐하면 이미 선행테이블(BUILD INPUT)을 읽는 과정에서 어떤 파티션을 액세스 할 것인지 결정 되었기 때문이다. 따라서 후행테이블의 건수도 918K건이 아니라 59K건(60608건)에 불과한 것이다.

위의 Outline Data를 보고 혹자는 'PX_JOIN_FILTER 때문에 PARTITION PRUNING이 일어난 것이다' 고 의혹을 제기한다. 하지만 PX_JOIN_FILTER는 FULL PWJ는 아무 상관이 없다. 왜냐하면 아래와 같이 NO_PX_JOIN_FILTER 힌트를 사용해서 Filter를 제거해도 PWJ의 효과가 유지되기 때문이다.

SELECT /*+ LEADING(T) NO_PX_JOIN_FILTER(S) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | | 1 |00:00:00.18 | 6263 |

| 1 | SORT AGGREGATE | | 1 | | | 1 |00:00:00.18 | 6263 |

| 2 | PARTITION RANGE ALL| | 1 | 1 | 28 | 154 |00:00:00.18 | 6263 |

|* 3 | HASH JOIN | | 28 | | | 154 |00:00:00.18 | 6263 |

|* 4 | TABLE ACCESS FULL| SALES_ORDER_PT | 28 | 1 | 28 | 88 |00:00:00.10 | 5947 |

| 5 | TABLE ACCESS FULL| SALES_PT | 1 | 1 | 28 | 60608 |00:00:00.02 | 316 |

--------------------------------------------------------------------------------------------------------

Outline Data

-------------

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE('11.2.0.1')

DB_VERSION('11.2.0.1')

ALL_ROWS

OUTLINE_LEAF(@"SEL$1")

FULL(@"SEL$1" "T"@"SEL$1")

FULL(@"SEL$1" "S"@"SEL$1")

LEADING(@"SEL$1" "T"@"SEL$1" "S"@"SEL$1")

USE_HASH(@"SEL$1" "S"@"SEL$1")

END_OUTLINE_DATA

*/

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID"

AND "S"."PROMO_ID"="T"."PROMO_ID")

4 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

위의 SQL에서 NO_PX_JOIN_FILTER를 사용하여 FILTER를 제거시켰지만 여전히 PWJ가 실행되었다. 따라서 PX_JOIN_FILTER도 FULL PWJ의 원리가 아니다. PWJ의 성능향상 원리는 T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD') 조건에 있다. 다시 말해 이 조건 때문에 후행 테이블은 2001년도 1분기 파티션만 읽으면 되는 것이다. 중요한 점은 T.ORDER_DT 컬럼이 Partition Key 컬럼이 아님에도 성능이 향상되었다는 점이다. 아래의 SQL이 그것을 증명한다.

SELECT /*+ FULL(SALES) */ COUNT(*)

FROM SALES_PT PARTITION (ST_Q1_2001);

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | | 1 |00:00:00.05 | 316 |

| 1 | SORT AGGREGATE | | 1 | | | 1 |00:00:00.05 | 316 |

| 2 | PARTITION RANGE SINGLE| | 1 | 17 | 17 | 60608 |00:00:00.04 | 316 |

| 3 | TABLE ACCESS FULL | SALES_PT | 1 | 17 | 17 | 60608 |00:00:00.02 | 316 |

-----------------------------------------------------------------------------------------------------

PWJ의 성능개선 원리는 선행집합의 Filter에 있다
FULL PWJ가 발생했을 때와 같이 정확히 316 BLOCK 만 읽었다. PWJ가 실행됨으로써 BLOCK I/O 관점의 성능개선사항은 명확해졌다. 선행집합의 FILTER가 후행집합의 BLOCK I/O를 결정한다는 것이다. 다시 말해 선행집합은 T.ORDER_DT = 상수조건에 상관없이 모든 파티션을 ACCESS 해야 한다. 하지만 후행집합은 T.ORDER_DT = 상수조건에 만족하는 파티션만 ACCESS 하는 것이 PWJ의 성능개선 원리이다.

Partial PWJ의 성능개선 원리도 FULL PWJ와 같다
FULL PWJ의 성능개선 원리와 Partial PWJ의 성능개선 원리는 같다. 하지만 처리방식이 다르다. Partial PWJ는 내부적으로Bloom Pruning을 이용한다. Bloom Filter를 이용하여 후행테이블의 조인건수를 줄일 수 있는데, Bloom Pruning도 같은 메커니즘을 이용하여 후행 테이블의 파티션 Access 개수를 최소화 하는 것이다. 아래의 SQL은 Partial PWJ 예제이며, Bloom Pruning을 이용하여 후행집합의 파티션 Access 개수를 최소화 하고 있다.

ALTER SESSION SET "_bloom_pruning_enabled" = TRUE;

SELECT /*+ LEADING(T) USE_HASH(S) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_NO_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1| | | 1|00:00:00.64| 5773|

| 1 | SORT AGGREGATE | | 1| | | 1|00:00:00.64| 5773|

|* 2 | HASH JOIN | | 1| | | 154|00:00:00.64| 5773|

| 3 | PART JOIN FILTER CREATE | :BF0000 | 1| | | 88|00:00:00.52| 5457|

|* 4 | TABLE ACCESS FULL | SALES_ORDER_NO_PT| 1| | | 88|00:00:00.52| 5457|

| 5 | PARTITION RANGE JOIN-FILTER| | 1|:BF0000|:BF0000| 60608|00:00:00.05| 316|

| 6 | TABLE ACCESS FULL | SALES_PT | 1|:BF0000|:BF0000| 60608|00:00:00.03| 316|

---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID"
                AND "S"."CUST_ID"="T"."CUST_ID" AND "S"."PROMO_ID"="T"."PROMO_ID")
   4 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

FULL PARTITION WISE JOIN과 PARTIAL PARTITION WISE JOIN의 성능개선 원리는 같으며, BLOCK I/O도 동일하다. 다른 점은 PARTIAL PARTITION WISE JOIN이 Bloom Pruning를 이용했다는 것뿐이다. 다시 말해, 아래처럼 Bloom Pruning 기능을 사용할 수 없게 된다면 PARTIAL PARTITION WISE JOIN시 성능향상(후행 집합의 BLOCK I/O 감소)을 기대할 수 없다.

ALTER SESSION SET "_bloom_pruning_enabled" = false;

SELECT /*+ LEADING(T) USE_HASH(S) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_NO_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

------------------------------------------------------------------------------------------------------------
| Id | Operation             | Name              | Starts | Pstart| Pstop | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                   |      1 |       |       |      1 |00:00:01.22 |   10341 |
|   1 | SORT AGGREGATE       |                   |      1 |       |       |      1 |00:00:01.22 |   10341 |
|* 2 |   HASH JOIN           |                   |      1 |       |       |    154 |00:00:01.22 |   10341 |
|* 3 |    TABLE ACCESS FULL | SALES_ORDER_NO_PT |      1 |       |       |     88 |00:00:00.54 |    5457 |
|   4 |    PARTITION RANGE ALL|                   |      1 |     1 |    28 |    918K|00:00:00.31 |    4884 |
|   5 |     TABLE ACCESS FULL | SALES_PT          |     28 |     1 |    28 |    918K|00:00:00.15 |    4884 |
------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND "S"."TIME_ID"="T"."TIME_ID" AND
              "S"."PROMO_ID"="T"."PROMO_ID")
   3 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

_bloom_pruning_enabled 파라미터를 false로 놓고 실행하자 SALES_PT 테이블의 모든 파티션을 Access하게 되었다. 이에 따라 성능도 저하된다. PARTIAL PARTITION WISE JOIN이 Bloom Pruning를 이용하고 있다는 증거이다.

Partition Pair는 PWJ의 성능개선 원리가 아니다
많은 책에서 PWJ를 설명하기 위해 Partition Pair라는 용어를 사용하고 있다. 하지만 Partition Pair는 PWJ의 원리가 아니라, 조인 시 선행집합에 PARTITION PRUNING이 발생한 것뿐이다. 아래의 SQL을 실행시켜 보자.

SELECT /*+ LEADING(T) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND T.TIME_ID BETWEEN TO_DATE('20010101', 'YYYYMMDD') AND TO_DATE('20011231', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

-------------------------------------------------------------------------------------------------------------

| Id | Operation                 | Name           | Starts | Pstart| Pstop | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |                |      1 |       |       |      1 |00:00:00.08 |    1984 |
|   1 | SORT AGGREGATE           |                |      1 |       |       |      1 |00:00:00.08 |    1984 |
|   2 |   PARTITION RANGE ITERATOR|                |      1 |    17 |    20 |    154 |00:00:00.08 |    1984 |
|* 3 |    HASH JOIN              |                |      4 |       |       |    154 |00:00:00.08 |    1984 |
|* 4 |     TABLE ACCESS FULL     | SALES_ORDER_PT |      4 |    17 |    20 |     88 |00:00:00.02 |    1668 |
|* 5 |     TABLE ACCESS FULL     | SALES_PT       |      1 |    17 |    20 | 60608 |00:00:00.02 |     316 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND
              "S"."PROMO_ID"="T"."PROMO_ID")
   4 - filter(("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
                AND "T"."TIME_ID"<=TO_DATE(' 2001-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
   5 - filter("S"."TIME_ID"<=TO_DATE(' 2001-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

T.TIME_ID 조건에 의해서 선행집합에 PARTITION PRUNING이 발생하여 전체 파티션이 아닌 2001년도 파티션 4개만 읽으면 된다. 이에 따라 선행 테이블의 I/O가 5947에서 1668로 줄어들었다. 비록 선행집합의 I/O가 줄어들었지만, PWJ의 성능 개선 원리인 '선행집합의 FILTER 조건이 후행집합의 BLOCK I/O를 결정한다'는 변치 않는다. 즉 선행테이블의 두 조건인 T.ORDER_DT = 조건과 T.TIME_ID BETWEEN 조건의 교집합이 후행테이블의 ACCESS 범위가 되는 것이다. 만약 PWJ의 성능개선 원리가 없고 Partition Pair만 존재했다면 후행집합이 2001년에 해당하는 파티션 4개를 모두 읽어야 할 것이다. 하지만 위에서 보는 것처럼 후행집합은 단 하나의 파티션만 Access 한다.

물론 아무런 조건 없이 Partition Key 조건만 있다면 아래처럼 Partition Pair가 되기는 한다.

SELECT /*+ LEADING(T) USE_HASH(S) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE T.TIME_ID BETWEEN TO_DATE('20010101', 'YYYYMMDD') AND TO_DATE('20011231', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

-------------------------------------------------------------------------------------------------------------
| Id | Operation                 | Name           | Starts | Pstart| Pstop | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |                |      1 |       |       |      1 |00:00:00.61 |    3022 |
|   1 | SORT AGGREGATE           |                |      1 |       |       |      1 |00:00:00.61 |    3022 |
|   2 |   PARTITION RANGE ITERATOR|                |      1 |    17 |    20 |    464K|00:00:00.58 |    3022 |
|* 3 |    HASH JOIN              |                |      4 |       |       |    464K|00:00:00.50 |    3022 |
|* 4 |     TABLE ACCESS FULL     | SALES_ORDER_PT |      4 |    17 |    20 |    259K|00:00:00.05 |    1668 |
|* 5 |     TABLE ACCESS FULL     | SALES_PT       |      4 |    17 |    20 |    259K|00:00:00.05 |    1354 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND
              "S"."PROMO_ID"="T"."PROMO_ID")
   4 - filter("T"."TIME_ID"<=TO_DATE(' 2001-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   5 - filter("S"."TIME_ID"<=TO_DATE(' 2001-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

T.ORDER_DT 조건을 삭제하고 T.TIME_ID 조건만 있으므로 정확히 두 테이블은 Pair이다. 즉 두 테이블은 2001년 파티션을 각각 4개씩 읽었다. 즉 PWJ 발생시 BLOCK I/O 관점의 성능개선 원리는 FULL PWJ이냐 아니면 Partial PWJ이냐에 따라 변치 않으며 아래처럼 정의 할 수 있다.

1. 선행집합의 파티션 ACCESS 범위는 PARTITION KEY 조건에 의한 Partition Pruning에 의해 결정된다. 하지만 이 기능은 PWJ의 장점이 아니다. 왜냐하면 조인이 아닌 경우도 실행되기 때문이다.

2. 후행집합의 파티션 ACCESS 범위는 선행집합의 모든 FILTER에 의해 결정된다. 이 기능이야 말로 Partition Wise Join의 장점이다. 왜냐하면 조인에 의해서 성능이 향상되기 때문이다.

이

PWJ 성능향상의 두 번째 원리

이제 BLOCK I/O관점에서 성능개선 원리가 밝혀졌으므로, PGA 사용량 관점에서 PWJ의 성능개선 원리를 나타내 보자.

SELECT /*+ LEADING(T) */ COUNT(*)

FROM SALES_NO_PT S, SALES_ORDER_NO_PT T

WHERE S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

-----------------------------------------------------------------------------------------------------
| Id | Operation           | Name              | Starts | A-Rows |   A-Time   | Buffers | Used-Mem |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                   |      1 |      1 |00:00:04.22 |    9898 |          |
|   1 | SORT AGGREGATE     |                   |      1 |      1 |00:00:04.22 |    9898 |          |
|* 2 |   HASH JOIN         |                   |      1 |   1418K|00:00:04.00 |    9898 |   54M (0)|
|   3 |    TABLE ACCESS FULL| SALES_ORDER_NO_PT |      1 |    918K|00:00:00.40 |    5457 |          |
|   4 |    TABLE ACCESS FULL| SALES_NO_PT       |      1 |    918K|00:00:00.36 |    4441 |          |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID"
               AND "S"."TIME_ID"="T"."TIME_ID" AND "S"."PROMO_ID"="T"."PROMO_ID")

PWJ가 실행되지 않는 경우 PGA를 54MB나 소모하였다. 이제 PWJ를 실행시켜 성능이 얼마나 개선되는지 알아보자.

SELECT /*+ LEADING(T) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID = T.TIME_ID

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

--------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | | 1 |00:00:04.48| 10795| |

| 1 | SORT AGGREGATE | | 1 | | | 1 |00:00:04.48| 10795| |

| 2 | PARTITION RANGE ALL| | 1 | 1 | 28| 1418K|00:00:04.26| 10795| |

|* 3 | HASH JOIN | | 28 | | | 1418K|00:00:03.69| 10795|5008K (0)|

| 4 | TABLE ACCESS FULL| SALES_ORDER_PT | 28 | 1 | 28| 918K|00:00:00.34| 5947| |

| 5 | TABLE ACCESS FULL| SALES_PT | 16 | 1 | 28| 918K|00:00:00.34| 4848| |

---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("S"."TIME_ID"="T"."TIME_ID" AND "S"."PROD_ID"="T"."PROD_ID"
               AND "S"."CUST_ID"="T"."CUST_ID" AND "S"."PROMO_ID"="T"."PROMO_ID")

PWJ를 실행하니 PGA 사용량이 11배나 줄어들었다. PWJ란 덩치가 큰 테이블 두 개를 조인시켜야 될 때, 작은 여러 개의 파티션으로 쪼개서 각각 조인시킴으로써 조인의 성능을 향상 시키는 것이다. 이렇게 되면 당연히 PGA 사용량이 급격히 줄어들 것이다.

한가지 주의 사항이 있다. PWJ가 발생하려면 파티션 기준 컬럼으로 양측 집합을 조인해야 한다. 그런데 파티션 Key 조인 컬럼을 아래처럼 가공하게 되면 PWJ가 발생되지 않으므로 주의하기 바란다

SELECT /*+ LEADING(T) */ COUNT(*)

FROM SALES_PT S, SALES_ORDER_PT T

WHERE T.ORDER_DT = TO_DATE('20010101', 'YYYYMMDD')

AND S.PROD_ID = T.PROD_ID

AND S.CUST_ID = T.CUST_ID

AND S.TIME_ID + 1 = T.TIME_ID + 1 --파티션 기준컬럼 가공

AND S.CHANNEL_ID = S.CHANNEL_ID

AND S.PROMO_ID = T.PROMO_ID ;

---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1| | | 1 |00:00:02.23 | 10831 | |

| 1 | SORT AGGREGATE | | 1| | | 1 |00:00:02.23 | 10831 | |

|* 2 | HASH JOIN | | 1| | | 154 |00:00:02.23 | 10831 |1210K (0)|

| 3 | PARTITION RANGE ALL| | 1| 1 | 28| 88 |00:00:00.10 | 5947 | |

|* 4 | TABLE ACCESS FULL | SALES_ORDER_PT | 28| 1 | 28| 88 |00:00:00.10 | 5947 | |

| 5 | PARTITION RANGE ALL| | 1| 1 | 28| 918K|00:00:00.70 | 4884 | |

| 6 | TABLE ACCESS FULL | SALES_PT | 28| 1 | 28| 918K|00:00:00.33 | 4884 | |

---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("S"."PROD_ID"="T"."PROD_ID" AND "S"."CUST_ID"="T"."CUST_ID" AND

INTERNAL_FUNCTION("S"."TIME_ID")+1=INTERNAL_FUNCTION("T"."TIME_ID")+1 AND "S"."PROMO_ID"="T"."PROMO_ID")

4 - filter("T"."ORDER_DT"=TO_DATE(' 2001-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

FULL PWJ를 가능하게 하는 파라미터는 _full_pwise_join_enabled 이며 Default로 True이다. Partial PWJ를 가능하게 하는 기능은 Bloom Pruning이며 파라미터는 _bloom_pruning_enabled이다. 이 파라미터의 Default값은 True이다.

결론

PARTITION WISE JOIN을 설명하는데 PARALLEL + PQ_DISTIRBUTE 힌트 조합은 필요 없다. PARALLEL Operation을 사용할 때 옵티마이저가 잘못된 분배방식을 사용하여 PARTITION WISE JOIN이 실행되지 못할 수 있다. 이때 사용할 수 있는 힌트가 PQ_DISTIRBUTE이며, 이것은 활용법일 뿐이다.

PARTITION PAIR라는 용어 때문에 미리 짝지어 놓았다고 상상함으로써, 마치 조인되는 양측 Partition이 항상 Pair하게 I/O를 한다고 잘못 생각하게 만든다. PWJ의 성능상 장점은 선행집합의 FILTER에 의해서 후행집합에 Access할 파티션의 개수가 줄어든다는 것이다. 따라서 I/O가 PAIR하게 발생되지 않는다. 'PARTITION PAIR로 동작한다'라는 개념은 선행집합에 조건이 하나도 없는 경우이거나 혹은 Partition Key로만 조건이 들어오는 경우뿐이다. 다시 말해 선행집합에 Partition Key조건 이외의 조건이 있다면 PARTITION PAIR를 보장하지 않는다.

PWJ가 실행될 때 성능개선사항 세 가지

첫 번째, 조인 선행집합에 Partition Key 조건이 있으면 Partition Access 범위도 줄어듦으로 BLOCK I/O량도 줄어든다.

두 번째, 선행집합의 모든 FILTER(Partition Key 조건을 포함한)에 의해서 후행집합의 Partition Access 범위가 줄어듦으로 BLOCK I/O량이 줄어든다.

세 번째, JOIN시 큰 테이블을 상대적으로 작은 파티션으로 쪼개어 각각 조인함으로써 PGA 사용량이 감소된다.

첫 번째 개선사항을 정확히 말하면 PWJ의 기능이 아니라 일반적인 Partition Pruning에 의한 성능향상이다. Partition Wise Join의 성능개선은 조인에 의해서 성능이 향상되어야 함으로 두 번째, 세 번째가 진정한 PWJ의 성능개선사항이다.

이제 필자의 차례는 끝나고, 여러분의 차례이다. 주위 사람들에게 PWJ의 정의를 다시 알려주기 바란다.

저작자표시 비영리 변경금지

'Oracle > Data Join Method' 카테고리의 다른 글

Sort Merge Join에 대한 오만과 편견 (476)	2011.04.28
같은 테이블을 두 번 읽었지만 일량이 틀려요 (16)	2011.01.14
Oracle 조인 방법 25가지 (15)	2010.02.26
Nested Loop Join 성능향상과 관련된 2가지 원리 (17)	2009.05.09
Hash Join Right (Semi/Anti/Outer) 의 용도 (17)	2009.03.02

Posted by extremedb

,

COUNT(Distinct 컬럼)의 성능

Oracle/Optimizer 2013. 5. 6. 06:00

집계함수 내부에 Distinct를 사용할 수 있다는 것은 많은 사람들이 알고 있다. 하지만 실제로 그렇게 사용했을 때 내부적으로 무슨 일이 일어나는지 아는 사람은 드물다. 한걸음 더 나아가서 COUUNT(COL) 대신에 COUNT(Distinct COL)를 사용했다면 분명히 추가적인 부하가 존재할 것인데, 그 부하를 어떻게 해결할 것인가를 아는 사람은 거의 없을 것이다. 만약 그렇다면 SQL을 실행할 때 마다 성능이 느려질 것이고 문제를 해결할 수 없을 것이다. 여러분들에게는 그런 일이 발생하지 않는다. 이미 이 글을 읽고 있기 때문이다.

이 글은 위에서 언급된 두 가지 문제를 다룬다. 즉 내부적으로 어떤 변화가 발생하는지 알아보고, 추가적인 부하를 어떻게 없앨 수 있는지도 연구해보자.

SQL 변경에 따른 내부적인 변화를 알아보는 가장 좋은 방법은 비교하는 것이다. 다시 말해, COUUNT(COL)로 실행했을 때의 일량과 COUNT(Distinct COL)로 사용했을 때의 일량을 비교해 보는 것이다. 따라서 우리는 SQL 두 개를 실행한 다음 각각의 작업량(실행통계)을 비교할 것이다.

환경: 오라클 11.2.0.1

CREATE TABLE SALE_T AS SELECT * FROM SALES;

SELECT /*+ NO_USE_HASH_AGGREGATION */
        S.PROD_ID
       ,COUNT(S.CHANNEL_ID)
       ,SUM(S.AMOUNT_SOLD)
       ,SUM(S.QUANTITY_SOLD)
FROM SALE_T S
GROUP BY S.PROD_ID;

-----------------------------------------------------------------------------------------
| Id | Operation          | Name   | Starts | A-Rows |   A-Time   | Buffers | Used-Mem |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |      1 |     72 |00:00:01.12 |    4440 |          |
|   1 | SORT GROUP BY     |        |      1 |     72 |00:00:01.12 |    4440 | 6144 (0)|
|   2 |   TABLE ACCESS FULL| SALE_T |      1 |    918K|00:00:00.32 |    4440 |          |
-----------------------------------------------------------------------------------------

위의 SQL이 실행되는데 시간이 1.12초 걸렸고 PGA는 6144 Byte를 소모하였다. 그런데 아래처럼 COUNT에 DISTINCT를 추가를 추가한다면 어떻게 될까?

SELECT /*+ NO_QUERY_TRANSFORMATION */
        S.PROD_ID
       ,COUNT(DISTINCT S.CHANNEL_ID)
       ,SUM(S.AMOUNT_SOLD)
       ,SUM(S.QUANTITY_SOLD)
FROM SALE_T S
GROUP BY S.PROD_ID;

-----------------------------------------------------------------------------------------
| Id | Operation          | Name   | Starts | A-Rows |   A-Time   | Buffers | Used-Mem |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |      1 |     72 |00:00:02.20 |    4440 |          |
|   1 | SORT GROUP BY     |        |      1 |     72 |00:00:02.20 |    4440 |14336 (0)|
|   2 |   TABLE ACCESS FULL| SALE_T |      1 |    918K|00:00:00.33 |    4440 |          |
-----------------------------------------------------------------------------------------

작업량이 증가된 이유
Distinct 만 추가했을 뿐인데 시간이 약 두 배나 걸리고 PGA도 약 두 배로 사용하였다. 그 이유는 Operation에는 나오지 않지만 내부적으로 SORT UNIQUE가 실행되기 때문이다. 즉 PROD_ID별로 SORT GROUP BY를 했음에도 CHANNEL_ID 별로 SORT UNIQUE를 다시 실행해야 한다. 약 92만 건의 데이터를 CHANNEL_ID 별로 SORT한 후에 중복을 제거하는 작업이 Distinct에 의해서 추가된 것이다. 그렇기 때문에 FULL TABLE SCAN의 수행시간은 거의 같지만 SORT GROUP BY의 수행시간이 0.8초에서 1.87초로 늘어나고 PGA사용량도 두 배가 된 것이다.

비효율을 제거하는 방법
첫 번째 의문점인 집계함수에 Distinct가 추가되면 어떤 일이 발생하는지 알아냈다. 그렇다면 두 번째 문제인 비효율(추가적인 Sort와 중복제거)을 없애는 방법은 무엇일까? SQL을 아래처럼 튜닝 할 수 있을 것이다.

SELECT /*+ NO_USE_HASH_AGGREGATION */
        PROD_ID,
        COUNT(S.CHANNEL_ID),
        SUM(S.AMOUNT_SOLD),
        SUM(S.QUANTITY_SOLD)
FROM (SELECT /*+ NO_USE_HASH_AGGREGATION */
                 S.CHANNEL_ID ,
                 S.PROD_ID ,
                 SUM(S.AMOUNT_SOLD) AMOUNT_SOLD,
                 SUM(S.QUANTITY_SOLD) QUANTITY_SOLD
           FROM SALE_T S
          GROUP BY PROD_ID, CHANNEL_ID) S
GROUP BY S.PROD_ID ;

-------------------------------------------------------------------------------------------
| Id | Operation            | Name   | Starts | A-Rows |   A-Time   | Buffers | Used-Mem |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |        |      1 |     72 |00:00:01.39 |    4440 |          |
|   1 | SORT GROUP BY NOSORT|        |      1 |     72 |00:00:01.39 |    4440 |          |
|   2 |   VIEW               |        |      1 |    228 |00:00:01.39 |    4440 |          |
|   3 |    SORT GROUP BY     |        |      1 |    228 |00:00:01.39 |    4440 |18432 (0)|
|   4 |     TABLE ACCESS FULL| SALE_T |      1 |    918K|00:00:00.33 |    4440 |          |
-------------------------------------------------------------------------------------------

비록 PGA 사용량은 약간 늘어났지만 수행시간은 DISTINCT가 없는 SQL과 비슷해졌다. 먼저 PROD_ID, CHANNEL_ID로 GROUP BY 되었기 때문에 인라인뷰 외부에서는 Distinct를 할 필요가 없다. 다른 말로 표현하면 먼저 GROUP BY했기 때문에 PROD_ID 별로는 CHANNEL_ID가 UNIQUE 하다. 따라서 인라인뷰 외부에서는 Distinct가 필요 없게 된 것이다.

더 좋은 것은 실행계획의 Id 1을 보면 SORT GROUP BY NOSORT가 나온다. NOSORT가 나온 이유는 인라인뷰가 이미 PROD_ID로 SORT 되어있기 때문에 더 이상의 SORT는 필요 없기 때문이다. 따라서 추가적인 Group By의 부하는 거의 없다. 이렇게 튜닝하면 Distinct에 의한 SORT UNIQUE의 부하가 대부분 사라진다.

옵티마이저가 사람을 대신한다
집계함수에 Distinct를 사용한다면 무조건 위의 SQL처럼 튜닝 해야 하는가? 그건 아니다. 오라클 11.2를 사용한다면 Logical Optimizer가 SQL을 자동으로 변경시켜 준다. 아래의 튜닝 되지 않은 SQL을 실행시켜보자.

SELECT /*+ NO_USE_HASH_AGGREGATION(@"SEL$5771D262") */
        S.PROD_ID
       ,COUNT(DISTINCT S.CHANNEL_ID)
       ,SUM(S.AMOUNT_SOLD)
       ,SUM(S.QUANTITY_SOLD)
FROM SALE_T S
GROUP BY S.PROD_ID

---------------------------------------------------------------------------------------------
| Id | Operation            | Name     | Starts | A-Rows |   A-Time   | Buffers | Used-Mem |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |      1 |     72 |00:00:01.39 |    4440 |          |
|   1 | SORT GROUP BY NOSORT|          |      1 |     72 |00:00:01.39 |    4440 |          |
|   2 |   VIEW               | VW_DAG_0 |      1 |    228 |00:00:01.39 |    4440 |          |
|   3 |    SORT GROUP BY     |          |      1 |    228 |00:00:01.39 |    4440 |18432 (0)|
|   4 |     TABLE ACCESS FULL| SALE_T   |      1 |    918K|00:00:00.32 |    4440 |          |
---------------------------------------------------------------------------------------------

Outline Data
-------------
/*+
      BEGIN_OUTLINE_DATA
      …생략
      TRANSFORM_DISTINCT_AGG(@"SEL$1")
      …생략
      END_OUTLINE_DATA
*/

오라클이 내부적으로 TRANSFORM_DISTINCT_AGG 힌트를 사용하였고 SQL을 자동으로 변경하였다. 실행계획도 튜닝된 SQL과 같다. 즉 11.2 버전부터는 집계함수내부에 Distinct가 존재하면 Logical Optimizer가 SQL을 변경시킴으로써 성능이 향상되는 것이다. 이 기능을 Distinct To Aggregation이라고 부른다.

아래는 10053 Trace 파일의 내용이다. 내용이 많지만 개념은 간단하다. 쿼리변환 전의 SQL을 보여주고 쿼리변환 후의 SQL을 보여준다. 그리고 두 개의 SQL 사이에는 쿼리블럭 SEL$1이 Distinct To Aggregation 기능에 의해서 두 개로 찢어지는 과정(SPLIT QUERY BLOCK)을 보여준다.

DAGG_TRANSFORM: transforming query block SEL$1 (#0)
qbcp (before transform):******* UNPARSED QUERY IS *******
SELECT "S"."PROD_ID" "PROD_ID",COUNT(DISTINCT "S"."CHANNEL_ID") "COUNT(DISTINCTS.CHANNEL_ID)",SUM("S"."AMOUNT_SOLD") "SUM(S.AMOUNT_SOLD)",SUM("S"."QUANTITY_SOLD") "SUM(S.QUANTITY_SOLD)" FROM "TLO"."SALE_T" "S" GROUP BY "S"."PROD_ID"
pgactx->ctxqbc (before transform):******* UNPARSED QUERY IS *******
SELECT "S"."PROD_ID" "PROD_ID",COUNT(DISTINCT "S"."CHANNEL_ID") "COUNT(DISTINCTS.CHANNEL_ID)",SUM("S"."AMOUNT_SOLD") "SUM(S.AMOUNT_SOLD)",SUM("S"."QUANTITY_SOLD") "SUM(S.QUANTITY_SOLD)" FROM "TLO"."SALE_T" "S" GROUP BY "S"."PROD_ID"
Registered qb: SEL$5771D262 0xea51918 (SPLIT QUERY BLOCK FOR DISTINCT AGG OPTIM SEL$1; SEL$1)
---------------------
QUERY BLOCK SIGNATURE
---------------------
signature (): qb_name=SEL$5771D262 nbfros=1 flg=0
fro(0): flg=0 objn=76169 hint_alias="S"@"SEL$1"

Registered qb: SEL$C33C846D 0xde78e84 (MAP QUERY BLOCK SEL$5771D262)
---------------------
QUERY BLOCK SIGNATURE
---------------------
signature (): qb_name=SEL$C33C846D nbfros=1 flg=0
fro(0): flg=5 objn=0 hint_alias="VW_DAG_0"@"SEL$C33C846D"

qbcp (after transform):******* UNPARSED QUERY IS *******
SELECT "VW_DAG_0"."ITEM_2" "PROD_ID",COUNT("VW_DAG_0"."ITEM_1") "COUNT(DISTINCTS.CHANNEL_ID)",SUM("VW_DAG_0"."ITEM_4") "SUM(S.AMOUNT_SOLD)",SUM("VW_DAG_0"."ITEM_3") "SUM(S.QUANTITY_SOLD)" FROM (SELECT /*+ NO_USE_HASH_AGGREGATION */ "S"."CHANNEL_ID" "ITEM_1","S"."PROD_ID" "ITEM_2",SUM("S"."QUANTITY_SOLD") "ITEM_3",SUM("S"."AMOUNT_SOLD") "ITEM_4" FROM "TLO"."SALE_T" "S" GROUP BY "S"."CHANNEL_ID","S"."PROD_ID") "VW_DAG_0" GROUP BY "VW_DAG_0"."ITEM_2"

Distinct To Aggregation 쿼리변환은Heuristic Query Transformation에 속한다. _optimizer_distinct_agg_transform 파라미터로 이 기능을 제어할 수 있고 Default로 true이다. 힌트로는 TRANSFORM_DISTINCT_AGG / NO_TRANSFORM_DISTINCT_AGG 를 사용할 수 있다.

이제 우리는 집계함수에 Distinct가 추가되면 SORT UNIQUE의 부하로 성능이 느려짐을 안다. 또 Distinct 대신에 Group By를 사용하여 그 부하를 대부분 없애는 방법도 알게 되었다. 하지만 이제는 이런 일들을 옵티마이저가 대신하게 되었다. 이런 기능들이 계속 추가된다면 언젠가는 튜너라는 직업이 사라지 않을까? 만약 튜너가 없어진다면, 그 후에 옵티마이저를 연구하는 사람까지 사라질 것이다. 왜냐하면 옵티마이저를 연구하는 사람은 튜너를 위해 존재하기 때문이다.

PS
다들 잘 지내시죠? 개인 사정으로 지난 2년간 뵙지 못했습니다. 5월달에 글을 한 두개 더 올릴 생각 입니다. 기대해 주세요. 5월 중순 부터는 바빠서 글쓰기가 힘들 것 같습니다.

그럼 건강하세요.

저작자표시 비영리 동일조건

'Oracle > Optimizer' 카테고리의 다른 글

Cardinality Feedback이 위험할 때 (10)	2010.10.25
공지 - Cardinality Feed Back이 위험할 때 (1)	2010.10.22
union과 union all의 숨겨진 차이점 (6)	2010.10.18
메트릭스나 터미네이터는 먼 미래의 이야기 인가? (2)	2010.04.28
해결사 되기 (15)	2010.02.04

Posted by extremedb

,

Oracle에 SSD(Flash Disk)를 사용한다면

Oracle/Performance Analysis 2011. 5. 4. 15:38

Window 7을 사용하는 사람들은 ReadyBoost 기능을 잘 알 것이다. 부팅 시에 필요한 정보를 성능이 우수한 Flash Disk(USB)에 넣음으로써 부팅속도를 향상시키는 것이다. 즉 부팅 시에 성능이 느린 Hard Disk를 사용하지 않으므로 성능이 향상된다. 이와 비슷한 기능이 오라클에도 있다.

Oracle 11.2부터 Database Smart Flash Cache라는 것이 추가되었다. 이 개념은 buffer cache가 Aging Out되어 Disk로 내려가는 단점을 보완한 것이다. 즉 buffer cache에서 Aging Out 되더라도 성능이 우수한 Flash Disk(SSD)로 내려가는 개념이다. 따라서 SSD로 Aging out된 블록을 다시 읽을 때 기존 Disk보다 빠른 성능을 낼 수 있다. Database Smart Flash Cache 기능이 추가되어 메모리 구조도가 약간 변경되었다.

그림의 출처: Database Administrator's Guide 11g Release 2

Flash Disk를 2차 cache로 사용하는 셈이다. 하지만 Flash Disk에서 조차 aging out될 때는 Disk로 내려가는 것은 막을 수 없다.

제약사항

반드시 솔라리스나 오라클 엔터프라이즈 리눅스를 사용해야 한다.

어떨 때 사용해야 되나?

아래의 세 가지 경우를 모두 만족하면 Database Smart Flash Cache를 고려해야 한다.

첫 번째, AWR이나 Statspack에서 Buffer Pool Advisory를 참조하여 buffer cache가 부족한 경우

두 번째, db file sequential read가 Top Wait Eevnt일 경우

세 번째, 여분의 CPU가 있는 경우

위의 세 가지 경우를 모두 만족해야 되는 이유는 기존의 Disk에도 약간의 Cache기능이 있으므로, 위의 조건과 같이 buffer cache가 부족하거나 aging out이 많이 발생하는 경우만 성능향상의 폭이 크기 때문이다.

All or Nothing

RAC인 경우 하나의 SSD Disk를 다른 노드에 공유할 수 없다. 즉, 노드별로 Smart Flash Cache를 별도로 설정해야 한다. 또한 하나의 노드에 Database Smart Flash Cache를 설정하였으면 나머지 노드에도 모두 Smart Flash Cache를 설정해야 한다.

Database Smart Flash Cache의 Size 설정

Flash Cache는 buffer cache의 2배~10배 정도를 권고한다. Flash Cache의 Size가 buffer cache의 2배보다 작으면 효과를 볼 수 없다.

Parameters

db_flash_cache_file:

Flash Cache로 사용할 파일의 경로를 설정한다. 만약 파일이 없으면 오라클이 startup시에 생성한다. 반드시 SSD내의 경로를 사용해야 한다. 그렇지 않으면 성능이 떨어진다.
예:/dev/fioa1

db_flash_cache_size:

Giga 단위로 기술해야 한다. 이 파라미터를 0으로 설정하면 Database Smart Flash Cache기능이 Disable된다. 이 파라미터는 scope = memory 옵션을 사용할 수 없다. 따라서 이 파라미터를 적용하려면 Shutdown과 Startup이 필요하다.

예: 16G

Buffer Cache 튜닝

aging out이 발생하여 buffer cache에서 Flash Cache로 밀려날 때에도 블록의 메타정보는 그대로 남게 된다. 그 메타정보는 어림잡아 한 블럭당 100 byte 정도이다. 만약 RAC라면 한 블럭당 200 byte를 차지한다. 이 메타정보는 블록이 flash cache로 이동될 때 flash cache내의 address 정보를 가지고 있을 것으로 추측된다. 만약 Flash Cache를 사용할 것이라면 buffer cache가 block 당 100 byte 정도(RAC라면 200 byte) 줄어들므로 그만큼 더 잡아주기 바란다.

필자의 여건상 Database Smart Flash Cache를 테스트 해볼 수 없다. 누가(SSD를 보유한 사람이) 테스트를 하여 후기를 올려주었으면 한다. 테스트 시나리오는 아래와 같다. Flash Cache의 적용 전/후의 성능을 비교하는 것이다. 나라면 이렇게 테스트 할 것이다.

Database Smart Flash Cache 미적용 시나리오

1. buffer cache를 아주 작게 잡는다.

2. 큰 테이블 두 개에 각각 사이즈가 큰 인덱스를 하나씩 만들어 Nested Loop Join을 시키면 aging out이 발생될 것이다.

Database Smart Flash Cache 적용 시나리오

1. buffer cache를 아주 작게 잡는다.

2. Database Smart Flash Cache기능을 Setup 한다.

3. 큰 테이블 두 개에 각각 사이즈가 큰 인덱스를 하나씩 만들어 Nested Loop Join을 시키면 aging out이 발생될 것이다.

측정항목

AWR로 db file sequential read의 부하가 얼마나 줄어드는지 관찰한다.

Nested Loop Join의 전체건 처리 속도는 얼마나 빨라지는지

이상으로 Oracle 11.2에 추가된 Database Smart Flash Cache 기능에 대해 살펴보았다. 한가지 이상한 점은 Database Smart Flash Cache 기능을 HP나 IBM 서버 등에는 사용할 수 없다는 것이다. 요즘 Oracle은 HP와 사이가 좋지 않다. 오라클의 가격정책도 이런 사실을 증명해준다. 돌아올 수 없는 강을 건넌 것인가? 아니면 Oracle 다음 버전(V 12)에서 HP나 IBM서버도 지원 할 것인가? 나는 전자라고 생각한다.

Reference:

Oracle Database 11g Release 1 (11.2.0.1) New Features- 1.8.1.1 Database Smart Flash Cache

Oracle Database Administrator's Guide 11g Release 2-Configuring Database Smart Flash

저작자표시 비영리 동일조건

'Oracle > Performance Analysis' 카테고리의 다른 글

About DBMS_XPLAN - 2.포맷 설정하기 (0)	2009.04.28
Query Transformation - Filter Push Down (5)	2009.03.17
Internal Hint Transformation (0)	2009.03.09
About DBMS_XPLAN - 1.실행계획 (9)	2008.12.18
AWR, ADDM, ASH 성능보고서 가장쉽게 출력하기 (2)	2008.10.16

Posted by extremedb

,

Sort Merge Join에 대한 오만과 편견

Oracle/Data Join Method 2011. 4. 28. 07:00

일반적인 의견
흔히 Sort Merge Join에 대해 다음과 같이 이야기 한다. “조인에 참여하는 양측 집합에 Sort가 발생하므로 대용량 집합간의 조인에는 불리하다. 그러나 조인 되는 양쪽 집합에 적절한 인덱스가 있다면 Sort가 발생되지 않으므로 성능이 좋다.” 일견 일리가 있는 말이다. 하지만 이 정도는 튜닝에 입문하는 단계에서 언급되는 정도일 뿐이다. 2단을 외운다고 해서 구구단을 모두 안다고 할 수는 없다. 튜닝에 입문하는 사람과는 반대로 경력이 있는 사람들은 좀더 구체적인 사실들을 알고 있다. Sort Merge Join과 관련된 튜닝을 많이 해보고, Merge Join에 대해 여기저기 튜닝서적들을 탐독한다. 그 결과 다음과 같은 섣부른 결론을 내리는 사람이 많이 있다.

1. 양쪽 집합이 Full Table Scan을 사용하면 조인순서에 상관없이 일량이 동일하므로 처리시간도 동일하다.

2. 조인순서에 상관없이 Sort량은 동일하다.

3. 부분범위처리가 안 된다.

4. Full Scan이 발생하면 인덱스를 사용할 수 없으므로 항상 Sort 작업을 동반한다.

5. Sort Merge Join 대신 Cartesian Merge Join이 나오면 조인조건이 빠진 악성 SQL이다.

6. 조인컬럼 기준으로 Sort되므로 Order by절과 조인 컬럼이 일치해야만 Sort가 발생하지 않는다.

완벽하지 않거나 잘못된 결론

혹시 당신도 Sort Merge Join에 대해서 1~6번이 옳다고 생각하는가? 위의 List는 깊이 고민해 보지 않고 내린 결론이다. 물론 1~6 번이 옳은 경우도 있다. 하지만 그것은 잘못된 것 혹은 완벽하지 않은 결론이다. 왜냐하면 간단한 테스트로 1~6번이 잘못된 개념임을 증명하거나, 1~6번에 해당하지 않는 경우를 증명할 수 있기 때문이다. 지금부터 시작해 보자.

먼저 실습용 테이블을 생성한다.

<환경: Oracle 11.2.0.1>

CREATE TABLE SALES_T AS SELECT * FROM SALES;

1. 조인순서에 상관없이 처리시간이 동일할까?

ALTER SYSTEM FLUSH BUFFER_CACHE;

SELECT /*+ leading(s) full(p) full(s) use_merge(p) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_name = 'CD-R with Jewel Cases, pACK OF 12'

AND p.prod_id = s.prod_id ;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:07.74 | 4447 | 4439 | |

| 1 | MERGE JOIN | | 1 | 22189 |00:00:07.74 | 4447 | 4439 | |

| 2 | SORT JOIN | | 1 | 590K|00:00:04.75 | 4440 | 4433 | 43M (0)|

| 3 | TABLE ACCESS FULL| SALES_T | 1 | 918K|00:00:01.23 | 4440 | 4433 | |

|* 4 | SORT JOIN | | 590K| 22189 |00:00:01.29 | 7 | 6 | 2048 (0)|

|* 5 | TABLE ACCESS FULL| PRODUCTS | 1 | 1 |00:00:00.01 | 7 | 6 | |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("P"."PROD_ID"="S"."PROD_ID")

filter("P"."PROD_ID"="S"."PROD_ID")

5 - filter("P"."PROD_NAME"='CD-R with Jewel Cases, pACK OF 12')

Sales_t 집합을 선행으로 실행하니 Scan한 블록수는 4447 이며 Sort량은 43M + 2048 이다. 그리고 처리시간은 7초 74이다. 그리고 조인시도(Merge)횟수는 59만 번이다. 그러면 이제 조인 순서만 바꿔보자. 과연 처리시간이 동일 할까?

ALTER SYSTEM FLUSH BUFFER_CACHE;

SELECT /*+ leading(p) full(p) full(s) use_merge(s) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_name = 'CD-R with Jewel Cases, pACK OF 12'

AND p.prod_id = s.prod_id ;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:02.52 | 4447 | 4439 | |

| 1 | MERGE JOIN | | 1 | 22189 |00:00:02.52 | 4447 | 4439 | |

| 2 | SORT JOIN | | 1 | 1 |00:00:00.03 | 7 | 6 | 2048 (0)|

|* 3 | TABLE ACCESS FULL| PRODUCTS | 1 | 1 |00:00:00.03 | 7 | 6 | |

|* 4 | SORT JOIN | | 1 | 22189 |00:00:02.44 | 4440 | 4433 | 43M (0)|

| 5 | TABLE ACCESS FULL| SALES_T | 1 | 918K|00:00:01.25 | 4440 | 4433 | |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter("P"."PROD_NAME"='CD-R with Jewel Cases, pACK OF 12')

4 - access("P"."PROD_ID"="S"."PROD_ID")

filter("P"."PROD_ID"="S"."PROD_ID")

일량이 같은데 수행시간은 세배이상 빠르다. 그 이유는?

조인 순서를 바꾸어 Products를 선행집합으로 Sort Merge Join을 해도 Scan한 블록 수와 Sort량은 완전히 같다. 일량이 같으므로 처리시간도 같을 것으로 생각해서는 안 된다. 처리시간이 2초 52로 무려 세배이상 빨라졌다. 그 이유는 조인시도(Merge)횟수가 단 한번이기 때문이다. 이와는 대조적으로 Sales_t가 선행집합인 경우는 Merge 횟수가 무려 59만 번에 이르므로 성능이 느릴 수 밖에 없는 것이다. 그러므로 다음과 같은 결론을 낼 수 있다.

양쪽 집합이 Full Table Scan을 사용하면 조인순서에 상관없이 일량이 동일하므로 처리시간도 동일하다 ( X )

-->일량은 동일하더라도 Merge 횟수가 달라지면 처리시간이 달라진다 ( O )

2. 조인순서에 상관없이 Sort량이 동일할까?

실습을 위해 테이블을 두 개 만든다.

CREATE TABLE TAB1 NOLOGGING AS

SELECT ROWNUM AS SALES_NO, A.* FROM SALES A;

CREATE INDEX IDX_TAB1_01 ON TAB1 (PROD_ID, SALES_NO);

CREATE TABLE TAB2 NOLOGGING AS

SELECT A.*, B.SEQ

FROM TAB1 A,

(SELECT LEVEL AS SEQ

FROM DUAL

CONNECT BY LEVEL <= 5) B ;

CREATE INDEX IDX_TAB2_01 ON TAB2 (PROD_ID, SALES_NO, SEQ);

SELECT /*+ LEADING(A) INDEX(A) INDEX(B) USE_MERGE(B) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:00.22 | 17355 | |

| 1 | MERGE JOIN | | 1 | 17205 |00:00:00.22 | 17355 | |

| 2 | TABLE ACCESS BY INDEX ROWID | TAB1 | 1 | 3441 |00:00:00.01 | 94 | |

|* 3 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 14 | |

|* 4 | SORT JOIN | | 3441 | 17205 |00:00:00.16 | 17261 | 1054K (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| TAB2 | 1 | 17205 |00:00:00.11 | 17261 | |

|* 6 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 17205 |00:00:00.02 | 56 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("A"."PROD_ID"=22)

4 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

6 - access("B"."PROD_ID"=22)

건수가 적은 tab1을 선행집합으로 하여 실행하였다. 선행집합은 적절한 인덱스 덕분으로 Sort가 발생하지 않았다. 하지만 후행집합 tab2는 17205건을 Sort하여 1054K의 PGA를 사용하였다. 이제 선행집합을 바꿔서 실행하여 Sort량이 같은지 검증해보자.

SELECT /*+ LEADING(B) INDEX(A) INDEX(B) USE_MERGE(A) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:00.34 | 17354 | |

| 1 | MERGE JOIN | | 1 | 17205 |00:00:00.34 | 17354 | |

| 2 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 17205 |00:00:00.15 | 17263 | |

|* 3 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 17205 |00:00:00.04 | 58 | |

|* 4 | SORT JOIN | | 17205 | 17205 |00:00:00.08 | 91 |83968 (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 3441 |00:00:00.01 | 91 | |

|* 6 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 12 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("B"."PROD_ID"=22)

4 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

6 - access("A"."PROD_ID"=22)

Sort Merge Join도 조인순서가 중요하다

선행집합을 tab2 로 바꾸어 실행하였다. 이번에는 tab1의 3441건만 Sort하였으므로 PGA를 83K 만 사용하였다. Tab2를 Sort하는 경우는 PGA를 1054K 나 사용하였으므로 12배 이상 차이가 난다. 다시 말해, 적절한 인덱스가 존재하는 경우는 Filtering 된 건수가 적은 집합을 후행집합으로 하는 것이 Sort의 부하를 줄일 수 있다.

하나는 안다. 하지만 둘은?

Sort의 부하를 12배 이상 줄였으므로 만족해서는 안 된다. Sort량이 극적으로 줄어도 속도는 오히려 떨어질 수 있다. 위의 실행계획 두 가지의 처리속도를 비교해보면 Sort량이 많은 것이 오히려 더 빠르다. 그 이유는 건수가 적은 집합을 후행으로 놓으면 선행집합이 건수가 많아지므로 Merge 시도횟수가 증가하기 때문이다. Sort의 부하와 Merge 횟수를 모두 고려해야 최적의 튜닝을 할 수 있다.

튜닝의 목적이 무엇인가?

예를 들면, 배치 SQL을 튜닝할 때 응답시간을 단축시키려면 작은 집합을 선행집합으로 하여 Merge 횟수를 줄여야 한다. 이와는 반대로 Sort의 부하가 커서 multi-pass가 나오는 경우라면 작은 집합을 후행집합으로 하여 Sort의 부하를 줄여야 한다. 즉, 응답시간 단축이냐 아니면 Sort량을 감소가 목적이냐에 따라서 튜닝방법이 달라져야 한다.

이 테스트를 통하여 다음을 증명해 보았다.

조인순서에 상관없이 Sort량이 동일하다 ( X )

-->적절한 인덱스를 사용하는 경우, Sort량은 Join 순서에 의해 달라진다 ( O )

참고사항: 첫 번째 조건이 참이 되려면 두 가지 전제가 필요하다. 전체범위를 처리해야 하며, 양측집합이 Full Scan인 경우에 해당한다.

3. Merge Join은 부분범위처리가 안 될까?

SELECT *

FROM (SELECT /*+ LEADING(B) INDEX(A) INDEX(B) USE_MERGE(A) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

ORDER BY B.PROD_ID, B.SALES_NO, B.SEQ )

WHERE ROWNUM <= 1 ;

-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.02 | 95 | |

|* 1 | COUNT STOPKEY | | 1 | 1 |00:00:00.02 | 95 | |

| 2 | VIEW | | 1 | 1 |00:00:00.02 | 95 | |

| 3 | MERGE JOIN | | 1 | 1 |00:00:00.02 | 95 | |

| 4 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 1 |00:00:00.01 | 4 | |

|* 5 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 1 |00:00:00.01 | 3 | |

|* 6 | SORT JOIN | | 1 | 1 |00:00:00.02 | 91 |83968 (0)|

| 7 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 3441 |00:00:00.02 | 91 | |

|* 8 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 12 | |

-----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM<=1)

5 - access("B"."PROD_ID"=22)

6 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

8 - access("A"."PROD_ID"=22)

단 한 건만 읽는다

인라인뷰 외부에서 ROWNUM <= 1 조건을 사용하자, 후행집합은 전체 건을 읽었지만 선행집합은 정확히 한 건만 읽었다. 선행집합이 전체범위로 처리되었다면 17205건을 읽었을 것이다. 즉 선행집합에 대해서는 완벽히 부분범위로 처리된다. 만약 후행집합이 몇 건 안 된다면 부분범위처리의 효율은 더욱 높아진다.

이제 Rownum 조건을 10, 100으로 변경해 가면서 실행계획을 관찰 해보자.

ROWNUM <= 10 조건일 때의 실행계획

-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.02 | 105 | |

|* 1 | COUNT STOPKEY | | 1 | 10 |00:00:00.02 | 105 | |

| 2 | VIEW | | 1 | 10 |00:00:00.02 | 105 | |

| 3 | MERGE JOIN | | 1 | 10 |00:00:00.02 | 105 | |

| 4 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 10 |00:00:00.01 | 14 | |

|* 5 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 10 |00:00:00.01 | 4 | |

|* 6 | SORT JOIN | | 10 | 10 |00:00:00.02 | 91 |83968 (0)|

| 7 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 3441 |00:00:00.02 | 91 | |

|* 8 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 12 | |

-----------------------------------------------------------------------------------------------------------

ROWNUM <= 100 조건일 때의 실행계획

-----------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 100 |00:00:00.03 | 195 | |

|* 1 | COUNT STOPKEY | | 1 | 100 |00:00:00.03 | 195 | |

| 2 | VIEW | | 1 | 100 |00:00:00.03 | 195 | |

| 3 | MERGE JOIN | | 1 | 100 |00:00:00.03 | 195 | |

| 4 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 100 |00:00:00.01 | 104 | |

|* 5 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 100 |00:00:00.01 | 4 | |

|* 6 | SORT JOIN | | 100 | 100 |00:00:00.03 | 91 |83968 (0)|

| 7 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 3441 |00:00:00.02 | 91 | |

|* 8 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 12 | |

-----------------------------------------------------------------------------------------------------------

Rownum 조건을 10, 100으로 변경하자 tab2를 정확히 10건, 100건만 읽는다. 도대체 누가 “Sort Merge Join은 부분범위처리가 안 된다” 라는 말을 한 것일까?

Sort Merge Join은 부분범위처리가 안 된다 ( X )

-->적절한 인덱스가 있다면 선행집합은 부분범위처리가 가능하다 ( O )

4. Full Scan을 하면 인덱스를 사용할 수 없으므로 항상 Sort 작업이 발생할까?

SELECT /*+ leading(s) full(p) full(s) use_merge(p) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_id = 119

AND p.prod_id = s.prod_id;

---------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:00.29 | 4450 | |

| 1 | MERGE JOIN CARTESIAN| | 1 | 22189 |00:00:00.29 | 4450 | |

|* 2 | TABLE ACCESS FULL | SALES_T | 1 | 22189 |00:00:00.06 | 4443 | |

| 3 | BUFFER SORT | | 22189 | 22189 |00:00:00.07 | 7 | 2048 (0)|

|* 4 | TABLE ACCESS FULL | PRODUCTS | 1 | 1 |00:00:00.01 | 7 | |

---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."PROD_ID"=119)

4 - filter("P"."PROD_ID"=119)

Sort Join이 사라진 이유

힌트를 주어 sales_t 와 products 모두 full table scan을 발생시켰다. 그러자 product 테이블 쪽은 buffer sort가 존재하지만 sales_t 테이블 쪽은 Sort가 사라졌다. Sort가 사라질 수 있는 이유는 product 쪽에 unique 조건(prod_id = 119)에 의해서 집합이 항상 한 건임을 보장하기 때문이다. 즉, 집합이 한 건뿐이므로 조인이 필요 없어지는 것이다. 바로 이것이 Sort Merge Join이 Cartesian Merge Join 으로 바뀔 수 있는 이유이다. 반대로 이야기하면, 위의 SQL에서 unique 조건이 없다면 Cartesian Merge Join과 buffer sort는 결코 발생하지 않는다.

Full Scan이 발생하면 인덱스를 사용할 수 없으므로 항상 Sort 작업을 동반한다 ( X )

-->Full Scan이 발생해도 Unique 조건이 들어오면 Sort Join Operation이 사라진다 ( O )

5. Sort Merge Join 대신에 Cartesian Merge Join이 나오면 조인조건이 빠진 악성 SQL일까?

위에서 Unique 조건 때문에 Sort Merge Join이 Cartesian Merge Join으로 바뀐다고 했다. 이 현상은 아주 바람 직한 것이다. 왜냐하면 불필요한 Sort를 없애버리기 때문이다. 따라서 Cartesian Merge Join이라고 해서 항상 실수로 조인을 하지 않은 악성 SQL은 아니다.

이번에는 Unique 인덱스를 사용하는 경우를 보자.

SELECT /*+ leading(p) full(s) use_merge(s) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_id = 119

AND p.prod_id = s.prod_id;

-------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:00.14 | 4444 |

| 1 | MERGE JOIN CARTESIAN| | 1 | 22189 |00:00:00.14 | 4444 |

|* 2 | INDEX UNIQUE SCAN | PRODUCTS_PK | 1 | 1 |00:00:00.01 | 1 |

|* 3 | TABLE ACCESS FULL | SALES_T | 1 | 22189 |00:00:00.05 | 4443 |

-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("P"."PROD_ID"=119)

3 - filter("S"."PROD_ID"=119)

Unique 인덱스를 사용하자 Sort가 사라졌고, 심지어 Buffer Sort도 사라졌다. 따라서 성능도 최적이 되었다. 그러므로 MERGE JOIN CARTESIAN 이라는 operation 만 보고 조인절이 빠졌다거나 악성 SQL 이라고 판단해서는 안 된다.

만약 조인 순서가 바뀌면 buffer sort가 나타나므로 주의해야 한다. 아래의 SQL을 보자.

SELECT /*+ leading(s) full(s) use_merge(p) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_id = 119

AND p.prod_id = s.prod_id;

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:00.28 | 4444 | |

| 1 | MERGE JOIN CARTESIAN| | 1 | 22189 |00:00:00.28 | 4444 | |

|* 2 | TABLE ACCESS FULL | SALES_T | 1 | 22189 |00:00:00.06 | 4443 | |

| 3 | BUFFER SORT | | 22189 | 22189 |00:00:00.07 | 1 | 2048 (0)|

|* 4 | INDEX UNIQUE SCAN | PRODUCTS_PK | 1 | 1 |00:00:00.01 | 1 | |

------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."PROD_ID"=119)

4 - access("P"."PROD_ID"=119)

카테시안 조인도 순서대로 실행해야 한다

Buffer sort 뿐만 아니라 merge 횟수도 22189번이나 시도되어 성능이 저하되었다. 위의 실행계획에서 볼 수 있듯이 CARTESIAN MERGE JOIN 도 조인의 순서가 중요하므로 실행계획을 유심히 살펴야 한다.

카테시안 조인의 발생조건

Unique 컬럼에 조건이 Equal로 들어오면 옵티마이져가 성능향상을 위해서 조인절을 삭제한다. 만약 Unique 컬럼이라도 Equal 조건이 아니라 Range 조건이라면 위의 CARTESIAN MERGE JOIN 실행계획이 나타나지 않는다. 아래의 SQL이 그것을 증명한다.

SELECT /*+ leading(s) full(s) use_merge(p) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_id >= 119

AND p.prod_id < 120

AND p.prod_id = s.prod_id;

-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:00.35 | 4441 | |

| 1 | MERGE JOIN | | 1 | 22189 |00:00:00.35 | 4441 | |

| 2 | SORT JOIN | | 1 | 22189 |00:00:00.16 | 4440 | 1117K (0)|

|* 3 | TABLE ACCESS FULL| SALES_T | 1 | 22189 |00:00:00.06 | 4440 | |

|* 4 | SORT JOIN | | 22189 | 22189 |00:00:00.08 | 1 | 2048 (0)|

|* 5 | INDEX RANGE SCAN | PRODUCTS_PK | 1 | 1 |00:00:00.01 | 1 | |

-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter(("S"."PROD_ID">=119 AND "S"."PROD_ID"<120))

4 - access("P"."PROD_ID"="S"."PROD_ID")

filter("P"."PROD_ID"="S"."PROD_ID")

5 - access("P"."PROD_ID">=119 AND "P"."PROD_ID"<120)

카테시안 조인이 더 빠르다

비록 SQL의 결과는 같지만 sort join operation에 의해서 PGA를 소모한다. where절의 prod_id가 equal 조건이냐 아니면 Range조건이냐에 따라서 성능이 좌우된다. 즉, 성능이 나쁜 Sort Merge Join으로 풀리느냐 아니면, 추가적인 Sort가 없어서 성능이 우수한 CARTESIAN MERGE JOIN으로 풀리느냐는 where 조건에 따라 좌우된다. Unique 컬럼에 = 조건인지 아닌지에 따라 Sort의 부하가 좌우되는 것이다.

만약 Unique 컬럼에 = 조건이 들어오면 옵티마이져가 hash join을 선택하는 경우가 있을까?

SELECT /*+ leading(p) use_hash(s) */

s.*, p.prod_id

FROM sales_t s, products p

WHERE p.prod_id = 119

AND p.prod_id = s.prod_id;

------------------------------------------------------------------------------------

------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 22189 |00:00:00.10 | 4444 |

| 1 | NESTED LOOPS | | 1 | 22189 |00:00:00.10 | 4444 |

|* 2 | INDEX UNIQUE SCAN| PRODUCTS_PK | 1 | 1 |00:00:00.01 | 1 |

|* 3 | TABLE ACCESS FULL| SALES_T | 1 | 22189 |00:00:00.06 | 4443 |

------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("P"."PROD_ID"=119)

3 - filter("S"."PROD_ID"=119)

Hash join은 실행할 수 없다

Unique 컬럼에 = 조건이 들어오면 결코 hash join을 선택하지 않는다. 강제로 힌트를 사용해도 merge join이나 nested loop join을 선택한다. 왜냐하면 Hash Join은 반드시 Equal Join이 필요한데, 조인절이 삭제되어 hash join이 발생될 수 없기 때문이다.

Sort Merge Join 대신 Cartesian Merge Join이 나오면 조인조건이 빠진 악성 SQL이다 ( X )

-->Unique 조건이 Equal로 들어오고 같은 컬럼으로 조인하면 옵티마이저는 성능향상을 위해 조인절을 삭제한다 ( O )

6. 조인컬럼 기준으로 Sort되므로 Order by절과 조인 컬럼이 일치할 때만 Sort가 발생되지 않는다. 정말 그럴까?

Sort의 기준이 조인컬럼이라는 말이 항상 참일까? 아래의 SQL을 보자.

SELECT /*+ LEADING(B) FULL(A) FULL(B) USE_MERGE(A) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

ORDER BY B.PROD_ID, B.SALES_NO, B.SEQ ;

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:03.34 | 32327 | |

| 1 | SORT ORDER BY | | 1 | 17205 |00:00:03.34 | 32327 | 1180K (0)|

| 2 | MERGE JOIN | | 1 | 17205 |00:00:03.29 | 32327 | |

| 3 | SORT JOIN | | 1 | 17205 |00:00:02.62 | 27257 | 1054K (0)|

|* 4 | TABLE ACCESS FULL| TAB2 | 1 | 17205 |00:00:02.53 | 27257 | |

|* 5 | SORT JOIN | | 17205 | 17205 |00:00:00.59 | 5070 |83968 (0)|

|* 6 | TABLE ACCESS FULL| TAB1 | 1 | 3441 |00:00:00.52 | 5070 | |

-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - filter("B"."PROD_ID"=22)

5 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

6 - filter("A"."PROD_ID"=22)

Order by 절에 조인컬럼(SALES_NO) 이외의 것들이 있으므로 SORT ORDER BY operation이 추가로 발생하여 성능이 저하되었다. 이제 조인컬럼으로만 order by를 해보자.

SELECT /*+ LEADING(B) FULL(A) FULL(B) USE_MERGE(A) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

ORDER BY B.SALES_NO;

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:02.69 | 32331 | |

| 1 | MERGE JOIN | | 1 | 17205 |00:00:02.69 | 32331 | |

| 2 | SORT JOIN | | 1 | 17205 |00:00:02.49 | 27257 | 1054K (0)|

|* 3 | TABLE ACCESS FULL| TAB2 | 1 | 17205 |00:00:02.41 | 27257 | |

|* 4 | SORT JOIN | | 17205 | 17205 |00:00:00.11 | 5074 |83968 (0)|

|* 5 | TABLE ACCESS FULL| TAB1 | 1 | 3441 |00:00:00.04 | 5074 | |

----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter("B"."PROD_ID"=22)

4 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

5 - filter("A"."PROD_ID"=22)

참고사항으로 알아두자. Order by절에 prod_id가 추가되어도 위의 실행계획은 같다. 왜냐하면 prod_id는 상수 22로 고정되어 있으므로 Sort가 필요 없기 때문이다.

조인컬럼으로 sort를 하니 SORT ORDER BY operation이 사라져 버렸다. 얼핏 보면 Sort의 기준은 조인컬럼인 것처럼 보인다. 하지만 이 조건을 항상 만족하려면 Full Scan을 해야 한다는 전제조건이 붙어야 한다. 그러면 이제 Full Scan 대신에 인덱스를 사용해보자.

SELECT /*+ LEADING(A) INDEX(A) INDEX(B) USE_MERGE(B) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

ORDER BY B.PROD_ID, B.SALES_NO, B.SEQ ;

----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:02.21 | 17352 | |

| 1 | SORT ORDER BY | | 1 | 17205 |00:00:02.21 | 17352 | 1117K (0)|

| 2 | MERGE JOIN | | 1 | 17205 |00:00:02.16 | 17352 | |

| 3 | TABLE ACCESS BY INDEX ROWID | TAB1 | 1 | 3441 |00:00:00.31 | 91 | |

|* 4 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.05 | 12 | |

|* 5 | SORT JOIN | | 3441 | 17205 |00:00:01.80 | 17261 | 1054K (0)|

| 6 | TABLE ACCESS BY INDEX ROWID| TAB2 | 1 | 17205 |00:00:01.75 | 17261 | |

|* 7 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 17205 |00:00:00.06 | 56 | |

----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("A"."PROD_ID"=22)

5 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

7 - access("B"."PROD_ID"=22)

인덱스를 사용했음에도 추가적인 Sort가 발생하는 이유

이런! 인덱스를 사용했지만, SORT ORDER BY가 발생하였다. 왜 그럴까? 인덱스를 사용할 때 Sort의 기준은 선행집합의 인덱스 컬럼이다. 즉, 선행집합의 인덱스컬럼이 order by절에 나온다면 Sort가 발생하지 않는다. 위의 SQL에서 선행집합의 인덱스컬럼은 PROD_ID + SALES_NO 이다. 따라서 B.SEQ 컬럼 때문에 Sort가 발생한 것이다. 그러면 이제 Sort를 없애기 위하여 선행집합을 바꿔보자.

SELECT /*+ LEADING(B) INDEX(A) INDEX(B) USE_MERGE(A) */

B.*, A.CHANNEL_ID AS CHAN

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

ORDER BY B.PROD_ID, B.SALES_NO, B.SEQ ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:03.09 | 17387 | |

| 1 | MERGE JOIN | | 1 | 17205 |00:00:03.09 | 17387 | |

| 2 | TABLE ACCESS BY INDEX ROWID | TAB2 | 1 | 17205 |00:00:02.58 | 17296 | |

|* 3 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 17205 |00:00:00.14 | 91 | |

|* 4 | SORT JOIN | | 17205 | 17205 |00:00:00.39 | 91 |83968 (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 3441 |00:00:00.32 | 91 | |

|* 6 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.06 | 12 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("B"."PROD_ID"=22)

4 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

6 - access("A"."PROD_ID"=22)

선행집합의 인덱스 컬럼과 Order By절의 컬럼이 동일하다. 그리고 인덱스와 Order by절의 컬럼순서도 동일하다. 이 두 가지 조건을 만족하므로 추가적인 SORT ORDER BY operation이 발생하지 않았다. Order By 뿐만 아니라 Group By도 마찬가지이다. 이제 Order by와 Group By를 동시에 사용해보자.

SELECT /*+ LEADING(B) INDEX(A) INDEX(B) NO_PLACE_GROUP_BY USE_MERGE(A) */

B.PROD_ID, B.SALES_NO, COUNT(*)

FROM TAB1 a, TAB2 b

WHERE A.SALES_NO = B.SALES_NO

AND A.PROD_ID = 22

AND B.PROD_ID = 22

GROUP BY B.PROD_ID, B.SALES_NO, B.SEQ

ORDER BY B.PROD_ID, B.SALES_NO ;

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 17205 |00:00:00.30 | 70 | |

| 1 | SORT GROUP BY NOSORT| | 1 | 17205 |00:00:00.30 | 70 | |

| 2 | MERGE JOIN | | 1 | 17205 |00:00:00.25 | 70 | |

|* 3 | INDEX RANGE SCAN | IDX_TAB2_01 | 1 | 17205 |00:00:00.02 | 58 | |

|* 4 | SORT JOIN | | 17205 | 17205 |00:00:00.08 | 12 |57344 (0)|

|* 5 | INDEX RANGE SCAN | IDX_TAB1_01 | 1 | 3441 |00:00:00.01 | 12 | |

------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("B"."PROD_ID"=22)

4 - access("A"."SALES_NO"="B"."SALES_NO")

filter("A"."SALES_NO"="B"."SALES_NO")

5 - access("A"."PROD_ID"=22)

Order By/Group By절의 컬럼이 모두 선행집합의 인덱스 컬럼과 순서가 같으므로 추가적인 Sort가 전혀 발생하지 않았다. 따라서 다음과 같은 결론을 낼 수 있다.

조인컬럼 기준으로 Sort되므로 Order by절과 조인 컬럼이 일치해야만 Sort가 발생하지 않는다. ( X )

-->Full table scan일 때는 조인컬럼 기준으로 sort 되는 것이 옳다. 하지만, index를 사용한다면 조인컬럼 뿐만 아니라, 선행집합의 인덱스 컬럼과 order by/group by절을 일치시켜도 Sort가 발생하지 않는다 ( O )

결론

6가지의 오만과 편견 중에 하나라도 얻은 것이 있다면 성공이다. 다시 한번 여섯 가지를 정리하기 바란다.

양쪽 집합이 Full Table Scan을 사용하면 조인순서에 상관없이 일량이 동일하므로 처리시간도 동일하다 ( X )

-->일량은 동일하더라도 Merge 횟수가 달라지면 처리시간이 달라진다 ( O )

조인순서에 상관없이 Sort량이 동일하다 ( X )

-->적절한 인덱스를 사용하는 경우, Sort량은 Join 순서에 의해 달라진다 ( O )

Sort Merge Join은 부분범위처리가 안 된다 ( X )

-->적절한 인덱스가 있다면 선행집합은 부분범위처리가 가능하다 ( O )

Full Scan이 발생하면 인덱스를 사용할 수 없으므로 항상 Sort 작업을 동반한다 ( X )

-->Full Scan이 발생해도 Unique 조건이 들어오면 Sort Join Operation이 사라진다 ( O )

Sort Merge Join 대신 Cartesian Merge Join이 나오면 조인조건이 빠진 악성 SQL이다 ( X )

-->Unique 조건이 Equal로 들어오고 같은 컬럼으로 조인하면 옵티마이저는 성능향상을 위해 조인절을 삭제한다 ( O )

조인컬럼 기준으로 Sort되므로 Order by절과 조인 컬럼이 일치해야만 Sort가 발생하지 않는다. ( X )

-->Full table scan일 때는 조인컬럼 기준으로 sort 되는 것이 옳다. 하지만, index를 사용한다면 조인컬럼 뿐만 아니라, 선행집합의 인덱스 컬럼과 order by/group by절을 일치시켜도 Sort가 발생하지 않는다 ( O )

PS
요즘 워낙 바빠서 예전에 미리 글을 써놓지 않았더라면 글을 하나도 올리지 못할뻔 하였다.

저작자표시 비영리 동일조건

'Oracle > Data Join Method' 카테고리의 다른 글

PARTITION WISE JOIN이란 무엇인가? (406)	2013.05.21
같은 테이블을 두 번 읽었지만 일량이 틀려요 (16)	2011.01.14
Oracle 조인 방법 25가지 (15)	2010.02.26
Nested Loop Join 성능향상과 관련된 2가지 원리 (17)	2009.05.09
Hash Join Right (Semi/Anti/Outer) 의 용도 (17)	2009.03.02

Posted by extremedb

,

COPY_T 테이블 필요한가?

Oracle/SQL Tuning 2011. 4. 4. 07:00

▶ 더미 테이블을 사용해서 장애를 만나는 경우

▶ 더미 테이블을 사용하는 이유

▶ 더미 테이블을 사용하지 않는 방법

포장마차에서 지인에게 재미있는 이야기를 들었다. 물론 공장 이야기 이다. 나는 이야기를 재미있게 들었지만, 지인의 입장에서는 머리가 쭈뼛쭈뼛 서는 심각한 일이었다. 사건은 2011년 겨울에 시작된다.

2011년 1월 1일 이른 아침, 갑자기 잘 돌아가던 시스템에 몇몇 프로그램들이 작동하지 않는 장애를 만났다. Y2K 버그도 아니고 2011년 1월 1일에 장애라니? 서버와 네트워크 그리고 Database는 정상이므로 관심의 화살은 개발팀으로 집중되었다. 개발팀에서 장애 프로그램을 조사해보니 지난 한 달간 프로그램 수정이 없다고 하였다. 결국 모든 것이 정상인데 프로그램만 돌아가지 않는 상황이다. 귀신이 곡할 노릇이 아닌가? 빨리 정상적인 서비스를 해야 하므로 1분, 1초가 아쉬운 시점이었다. 모두들 땀을 흘리며 원인을 찾고 있었다. 프로그램 담당자는 장애를 일으킨 사람을 찾으면 죽여버리겠다고 소리쳤다.

여러분은 이런 장애에서 안전한가?

다행히 오래 걸리지 않고 원인을 찾았다. 돌아가지 않는 프로그램들의 공통점은 더미테이블을 사용한다는 것이었다. 즉 Copy_ymd를 사용한 것이다. 그 테이블을 조사해보니 일자가 2010년 까지만 들어가 있었다. 그래서 2011년이 되자마자 장애가 발생한 것이었다. 다시 말해, Copy_ymd 테이블에 2011년 데이터가 없으므로, 이 테이블과 조인하면 한 건도 나오지 않는 것이다. 생각해보니, 모든 시스템에 이런 일이 발생할 수 있다. 이야기를 듣는 필자의 간담이 갑자기 서늘해진다.

시스템을 구축한 업체에게 항의하려고 문서를 찾아보니 2001년에 Open한 시스템으로 2001년 기준으로 미래의 일자를 10년치 넣어 놓았다. 소프트웨어의 라이프 사이클을 고려한다면, 10년이면 충분하다고 생각했을 것이다. 하지만 운이 없게도 차세대 프로젝트를 하지 않고 10년간 유지보수를 하면서 사용한 것이다. 그리고 인수인계서에 2011년이 되기 전에 몇 년치의 데이터를 더 넣어놓으라고 명시되어 있었다. 시스템을 구축한 업체에게 항의할 수 도 없는 일이었다. 인수인계서를 보는 사람이 한 명이라도 있었을까?

왜 더미 테이블을 사용할까?

데이터베이스에 관심이 있는 개발자라면 Copy_ymd, Copy_ym, Copy_y, Copy_t 등 네 개의 더미테이블을 알 것이다. 많은 시스템에 이런 더미 테이블들이 있다. 과거에는 이런 테이블들을 사용해야만 했다. 하지만 2011년의 시점에서 새로운 프로젝트를 할 때 이런 테이블들이 필요할까? 필요한지 아닌지를 알려면 먼저 더미테이블의 용도를 알아야 한다. 이 테이블들의 용도 중에서 대표적인 것은 아래와 같이 세 가지로 볼 수 있다.

1. Copy: 같은 집합을 여러 번 복제하여 원하는 결과집합을 구한다.

2. 데이터 체크: 일자의 경우 입력된 값이 올바른지 확인한다. 예를 들면, 2월 30일은 잘못된 일자이다.

3. 인덱스의 효율적 사용: 인덱스의 첫 번째 컬럼 혹은 중간 컬럼이 Where 조건에 사용되지 않을 때 더미 테이블을 이용하여 IN으로 공급해주면 인덱스를 효율적으로 사용할 수 있다.

물론, 다른 용도로 더미테이블을 사용할 수 도 있지만, 대부분은 위의 세가지 경우 때문에 더미테이블이 필요하다. 가끔 기준일자를 관리하는 테이블을 볼 수 있는데, 이것은 더미테이블이 아니라 business에 필요한 것이다. 더미테이블은 업무적인 것이 아니라, 성능적인 관점, 혹은 관리적인 목적으로 사용되는 것이다. 업무적인 데이터가 없으므로 차세대 시스템을 구축할 때 더미 테이블은 분석 대상에서 빠져도 된다. 이런 이유 때문에 모델러들도 더미테이블을 중요하게 생각하지 않는다.

더미 테이블의 단점

위의 세 가지를 더미 테이블을 사용하지 않고 처리할 수 있다면 굳이 사용할 필요는 없다. 왜냐하면 아래와 같은 단점이 있기 때문이다.

첫 번째, 더미 테이블이라고 해도 시스템 속성을 추가해야만 한다. 시스템 속성이란 입력자, 입력일시, 수정자, 수정일시 등을 의미한다. 모든 테이블에 이런 컬럼들이 4개 ~ 6개 정도 존재한다. 많은 기업들이 메타시스템을 사용하고 있다. 메타시스템에 테이블에 시스템 속성이 없으면 등록할 수가 없는 경우가 많다. 심지어 자동으로 시스템속성을 추가하는 메타시스템도 있다.

그런데 더미테이블은 튜닝의 목적이 있으므로 매우 가벼워야 한다. 생각해보라. Copy_t에 존재하는 숫자컬럼의 length는 3 byte에 불과한데 시스템 속성 네 개가 48 byte를 차지한다. 3 byte를 위해서 건건이 48 byte를 낭비해야 한다. 테이블이 무거워 질 수 밖에 없다. 더미 테이블은 메타시스템으로 관리하지 말고 엑셀로 관리하면 된다고? 왜 추가적인 관리를 해야만 하는가?

두 번째, 누가 더미 테이블을 중요하게 생각하는가? 더미 테이블을 인수인계 시 중요항목으로 관리되고 있는가? 2011년이 가까이 다가와도, Copy_ymd에 데이터를 넣어줄 생각을 하는 사람은 아무도 없었다. 왜냐하면 10년간 담당자가 세 번이나 바뀌었고, 더미테이블은 인수인계 시 중요관심사가 아니었기 때문이다. 결국 더미테이블을 신경 쓰는 사람은 아무도 없을 수 있다. 시스템은 이렇게 중요 테이블이 아니더라도 조그만 블랙홀이 생기면 장애를 맞는다. 이런 일이 발생할 수 밖에 없는 걸까?

세 번째, 관리해야 할 DB 서버가 많다면 위험이 증가한다. DB 팀이 관리하는 DB가 30개라고 가정하자. 지금 30개의 DB에 대해서 더미테이블을 관리하고 있는가? Copy_ymd에 추가적인 데이터를 insert 해야 하는 시기를 알고 있는가? 관리하고 있지 않다면 장애를 맞을 가능성이 높다. 그렇다면, 신경 쓰지 않아도 되도록, 시간이 되면 자동으로 insert되는 프로그램을 고려해 보아야 하는가? 아니면 시스템마다 더미테이블 들을 뒤져서 안전하게 100년치를 넣을 것인가? 왜 그래야 하는가? 아예 더미테이블을 사용하지 않으면 될 것을

지금은 운영 중이기 때문에 SQL을 바꾸는 것이 어렵다고 하더라도, 차세대 시스템을 구축할 때는 테이블을 관리할 필요도 없고, 장애도 일으키지 않는 방법이 무엇인지 고려하기 바란다. 방법은 얼마든지 있다. 이미 똑똑한 개발자들은 아래의 방법을 사용하고 하고 있다.

1. Copy

Copy_t 대신에 Rollup, Cube, Grouping Sets를 활용하면 원하는 집합을 만들 수 있다. 사용방법은 해당 글을 참고하라. 물론 내부적으로 쿼리변환이 발생되어 UNION ALL로 풀릴 수도 있으므로 성능이 저하되는지 실행계획의 확인은 필요하다. 이런 경우에도 COPY_T는 필요 없으며 DUAL + CONNECT BY LEVEL을 사용하면 된다. 또한 LEAD/LAG를 사용한다면 복제하지 않고도 전/후의 데이터를 비교할 수 있다.

2. 데이터 체크

데이터를 Insert 하기 전에 일자 컬럼을 체크하려고, DBMS Call을 해야만 하나? 다시 말해, 무슨 이유 때문에 DB에 불필요한 부하를 주어야 하는가? 비슷한 노력을 들이고도 DBMS Call을 하지 않을 수 있다. 화면 단에서 Java Script로 처리하던지, 아니면 Constraint를 걸면 Insert할 때에 자동으로 체크 되므로 별도의 DBMS Call은 필요 없다. Constraint에 대해서는 관련 글을 참조하라.

3. 인덱스의 효율적 사용

INDEX SKIP SCAN 기능이 추가되었기 때문에 IN 서브쿼리를 사용해야 되는 경우는 많이 한정 되었다. 또한 IN 서브쿼리를 사용한다고 하더라도 Copy_t, Copy_ymd 대신에 Dual + Connect By를 사용하면, Pseudo 컬럼인 Level을 사용할 수 있다. 물론 주의사항은 있다. 해당 글을 참조하라.

3번에 대해서 어느 개발자가 다음과 같이 질문한다.

질문1

개발자: 인덱스가 거래일자 + 고객번호 입니다. 거래일자에 Between 조건이 들어오고 고객번호에 = 조건이 들어온다고 칩시다. 인덱스의 선두 컬럼이 Range 조건이므로 똑똑한 고객번호를 인덱스로 액세스 할 수 없습니다. 이럴 때, Copy_ymd가 있어서 거래일자를 IN 서브쿼리로 공급할 수 있었습니다. 그런데 Copy_ymd 테이블 없이 Dual + Connect By + Level로 처리가 가능 한가요? Copy_t는 Level로 처리가 가능하지만 일자는 Range 조건으로 만들기 힘들 것 같은데요.

필자: 됩니다.

개발자: 어떻게요?

질문2

개발자: INDEX SKIP SCAN은 인덱스가 A+B+C 로 되어있고, A 혹은 B가 Where 조건에서 생략될 때만 사용할 수 있는 것 아닙니까? 즉, A 컬럼에 Range 조건이 오고 B에 = 조건이 오면 INDEX SKIP SCAN을 사용할 수 없는 걸로 알고 있습니다만.

필자: 꼭 그런 것은 아닙니다. A 컬럼에 조건이 Between이나 LIKE 조건이 오고 B 컬럼에 = 조건이 오더라도 INDEX SKIP SCAN이 발생합니다. 즉, 선두나 중간 컬럼의 조건이 생략될 때만 INDEX SKIP SCAN이 발생하는 것은 아니며, 선두나 중간 컬럼에 조건이 Range로 들어올 때도 발생합니다.

개발자: 그럴 리가요?

이제부터 두 가지 질문에 대해 대답해보자. 먼저 Sales 테이블에 인덱스를 하나 만들고 Copy_ymd를 만들자.

CREATE INDEX IDX_SALES_01 ON SALES (time_id, cust_id, prod_id) ;

CREATE TABLE COPY_YMD AS

SELECT TO_CHAR(ROWNUM + TO_DATE('19800101', 'YYYYMMDD'), 'YYYYMMDD') AS YMD_CHAR,

ROWNUM + TO_DATE('19800101', 'YYYYMMDD') AS YMD_DT

FROM SALES

WHERE ROWNUM <= 14600;

ALTER TABLE COPY_YMD ADD CONSTRAINT PK_COPY_YMD

PRIMARY KEY (YMD_CHAR) USING INDEX;

CREATE UNIQUE INDEX IDX_COPY_YMD_01 ON COPY_YMD(YMD_DT);

Sales 테이블의 인덱스는 Time_id _+ cust_id + Prod_id 이다. 해당 매출테이블의 transaction이 많아서 인덱스를 변경할 수도, 생성할 수도 없는 상황이라고 가정한다. 이제 테스트를 시작해보자.

참고로 아래의 힌트는 INDEX SKIP SCAN을 방지할 목적으로 사용한 것이다. INDEX SKIP SCAN이 나오기 전에는 이렇게 INDEX RANGE SCAN으로 수행되었다.

SELECT /*+ NO_INDEX_SS(S IDX_SALES_01) INDEX_RS_ASC(S IDX_SALES_01) */ s.*

FROM sales s

WHERE time_id BETWEEN TO_DATE('20011001', 'YYYYMMDD')

AND TO_DATE('20011130', 'YYYYMMDD')

AND cust_id = 53;

----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 |00:00:00.01 | 209 |

| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| SALES | 1 | 6 |00:00:00.01 | 209 |

|* 2 | INDEX RANGE SCAN | IDX_SALES_01 | 1 | 6 |00:00:00.01 | 203 |

----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("TIME_ID">=TO_DATE(' 2001-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "CUST_ID"=53

AND "TIME_ID"<=TO_DATE(' 2001-11-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

filter("CUST_ID"=53)

과거에는 선두컬럼이 Between이나 Like등의 Range 조건이 들어오면 위의 실행통계에서 볼 수 있듯이 비효율이 심했다. 고작 6건을 출력하기 위해 209 블록이나 Scan했다. 왜냐하면, 똑똑한 조건인 고객번호가 선두컬럼의 Range 조건 때문에 Access 조건이 못되고 Filter로 빠졌기 때문이다. 이런 비효율을 없애기 위해 예전에는 아래와 같이 더미테이블을 이용한 서브쿼리를 사용하였다.

SELECT /*+ LEADING(C@SUB) USE_NL(S) */ s.*

FROM sales s

WHERE time_id IN ( SELECT /*+ QB_NAME(SUB) */ ymd_dt

FROM copy_ymd c

WHERE ymd_dt BETWEEN TO_DATE('20011001', 'YYYYMMDD')

AND TO_DATE('20011130', 'YYYYMMDD') )

AND cust_id = 53;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 |00:00:00.01 | 136 |

| 1 | NESTED LOOPS | | 1 | 6 |00:00:00.01 | 136 |

| 2 | NESTED LOOPS | | 1 | 6 |00:00:00.01 | 130 |

|* 3 | INDEX RANGE SCAN | IDX_COPY_YMD_01 | 1 | 61 |00:00:00.01 | 4 |

|* 4 | INDEX RANGE SCAN | IDX_SALES_01 | 61 | 6 |00:00:00.01 | 126 |

| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| SALES | 6 | 6 |00:00:00.01 | 6 |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("YMD_DT">=TO_DATE(' 2001-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND

"YMD_DT"<=TO_DATE(' 2001-11-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

4 - access("TIME_ID"="YMD_DT" AND "CUST_ID"=53)

filter(("TIME_ID"<=TO_DATE(' 2001-11-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND

"TIME_ID">=TO_DATE(' 2001-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))

서브쿼리를 사용하자 고객번호를 Access 조건으로 사용할 수 있게 되었다. 이에 따라 서브쿼리를 사용하지 않은 경우(209 블럭)보다는 Scan량이 줄어 136 블록이 되었지만 약간의 비효율이 있다. Copy_ymd 때문에 4블럭을 Scan 하였다. 이것을 해결하려면 아래처럼 Dual + Connect By Level을 사용하면 된다. 위의 SQL과 아래의 SQL의 답은 같으며 아래의 SQL은 질문1의 답변에 해당한다.

SELECT s.*

FROM sales s,

( SELECT TO_DATE('20011001', 'YYYYMMDD') + LEVEL - 1 AS time_id

FROM dual

CONNECT BY LEVEL <= TO_DATE('20011130', 'YYYYMMDD') - TO_DATE('20011001', 'YYYYMMDD') + 1) d

WHERE s.time_id = d.time_id

AND s.cust_id = 53;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 |00:00:00.01 | 132 |

| 1 | NESTED LOOPS | | 1 | 6 |00:00:00.01 | 132 |

| 2 | NESTED LOOPS | | 1 | 6 |00:00:00.01 | 126 |

| 3 | VIEW | | 1 | 61 |00:00:00.01 | 0 |

| 4 | CONNECT BY WITHOUT FILTERING | | 1 | 61 |00:00:00.01 | 0 |

| 5 | FAST DUAL | | 1 | 1 |00:00:00.01 | 0 |

|* 6 | INDEX RANGE SCAN | IDX_SALES_01 | 61 | 6 |00:00:00.01 | 126 |

| 7 | TABLE ACCESS BY GLOBAL INDEX ROWID| SALES | 6 | 6 |00:00:00.01 | 6 |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

6 - access("S"."TIME_ID"=INTERNAL_FUNCTION("D"."TIME_ID") AND "S"."CUST_ID"=53)

Dual을 사용했기 때문에 Block I/O가 없어졌다. 하지만 여기서 만족하면 안 된다. 왜냐하면 쓸모 없는 조인이 61번이나 시도되었고 이에 따라 126블록을 Scan하였기 때문이다. 따라서 SQL을 아래처럼 바꾸어야 한다.

SELECT /*+ INDEX_SS(S IDX_SALES_01) */ s.*

FROM sales s

WHERE time_id BETWEEN TO_DATE('20011001', 'YYYYMMDD')

AND TO_DATE('20011130', 'YYYYMMDD')

AND cust_id = 53;

----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 |00:00:00.01 | 70 |

| 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| SALES | 1 | 6 |00:00:00.01 | 70 |

|* 2 | INDEX SKIP SCAN | IDX_SALES_01 | 1 | 6 |00:00:00.01 | 64 |

----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("TIME_ID">=TO_DATE(' 2001-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "CUST_ID"=53

AND "TIME_ID"<=TO_DATE(' 2001-11-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

filter("CUST_ID"=53)

불필요한 조인도 없어졌으며 Block I/O도 서브쿼리를 사용할 때에 비해서 약 절반으로 줄어들었다. 이것이 질문 2에 대한 대답이다.

참고사항

위의 SQL들을 보면 인덱스가 cust_id + time_id로 되어 있는 것이 최적이지만 막상 튜너가 현장에 투입되면 인덱스를 변경/생성/삭제 하기는 대단히 어려우므로 위의 방법을 잘 알아놓아야 한다.

결론

Copy_ymd, Copy_ym, Copy_y, Copy_t는 구시대의 유물이다. 성능에도 좋지 않으며, 코드가 길어지고, 장애가 발생할 수 있음에도 여러 가지 이유를 대어 차세대 시스템에 더미 테이블들이 또 포함될 수 있다. 안타깝게도 관행이나 표준으로 생각하는 사람이 많기 때문이다. 이제는 바뀔 때가 되었다. 지금 운영되는 모든 시스템에서 더미테이블을 사용하는 SQL을 모조리 조사해서 고치라는 이야기가 아니다. 그렇게 하기는 힘들 것이다. 다만 모든 더미테이블을 찾아서 미래의 데이터를 미리 그리고 넉넉히 넣자는 이야기 이다. 그리고 앞으로 시작될 프로젝트에서 더미테이블을 사용하지 않았으면 하는 것이 나의 바램이다. 당신이 발 뻗고 잘 수 있도록

저작자표시 비영리 동일조건

'Oracle > SQL Tuning' 카테고리의 다른 글

Sort 부하를 좌우하는 두 가지 원리 (11)	2011.03.29
SQL튜닝 방법론 (20)	2011.01.27
Pagination과 분석함수의 위험한 조합 (26)	2010.12.23
오라클의 Update문은 적절한가? (15)	2010.04.14
Connect By VS ANSI SQL (7)	2010.02.11

Posted by extremedb

,

Sort 부하를 좌우하는 두 가지 원리

Oracle/SQL Tuning 2011. 3. 29. 15:11

▶적절한 인덱스가 없을 때 Sort의 부하를 줄이는 방법

▶Pagination에서 Sort의 부하 줄이기

▶주의사항

Order by 절에 의한 Sort의 부하는 성능에 치명적이다. Block I/O의 최소화는 분명 튜닝의 핵심이다. 하지만, Block I/O를 최소화 해도 Sort의 부하가 심하다면 결코 만족스런 성능을 내지 못한다. 특히 “페이징 처리용 SQL에는 Sort를 대신할 수 있는 인덱스가 있어야 성능을 확보할 수 있다”고 많은 튜너들이 주장한다. 맞는 말이다. 그렇게만 된다면 Sort가 전혀 발생하지 않을 테니까. 하지만, 다음과 같은 어려움도 있다.

인덱스 최적화가 힘든 이유
첫 번째, 인덱스를 모든 조회화면의 기준에 맞게 만들려면 테이블마다 많은 수의 인덱스가 필요할 것이다. 두 번째, 운영중인 환경에서 인덱스를 생성 혹은 변경하기는 매우 어렵다. 따라서, 인덱스를 만들기 어렵다면, Sort의 부하를 최소화하는 다른 방법은 없는지를 고려해야 한다. 분명히 방법은 있다. 이 방법을 알지 못한다면 오직 인덱스에만 목숨을 거는 사람이 될 가능성이 높다. 오늘은 인덱스를 전혀 만들지 않은 상태에서 Sort의 부하를 최소화 하는 방법에 대해 알아볼 것이다.

단 한 가지 개념만 안다면, Order By에 의한 Sort의 부하를 이해한 것이다. Sort의 부하량은 면적에 비례한다는 것. 이 개념은 아래와 같이 표현할 수 있다. 참고로 ∝는 비례한다는 의미이다.

Sort의 부하량(PGA 사용량) ∝ 세로(결과 건수) X 가로(컬럼 Size 합계)

공식의 이해가 부족하다
주위의 지인들에게 위의 식을 질문한 결과 거의 모두가 세로에 대해서는 정확히 이해하고 있었다. 즉, Sort할 건수가 많아지면 Sort의 부하가 증가 한다는 것이다. 이에 반해서 가로에 대해서는 정확한 이해를 하는 사람이 드물었다. 대부분, Order By절에 의해 Sort의 부하가 발생하므로 Order By절에 존재하는 컬럼 Size의 합계가 가로라고 생각하는 것이다. 다시 말해, Order By절의 컬럼이 세 개라면, 세 컬럼의 Size를 합친 것이 가로라는 것이다. 과연 그럴까?

위의 주장을 검증하기 위해 테이블을 하나 만들고, 추가적으로 컬럼을 3개 만들자.

CREATE TABLE SALES_T NOLOGGING AS SELECT * FROM SALES;

ALTER TABLE SALES_T ADD (char_100 CHAR(100) DEFAULT 'a' NOT NULL );

ALTER TABLE SALES_T ADD (char_1000 CHAR(1000) DEFAULT 'a' NOT NULL );

ALTER TABLE SALES_T ADD (char_2000 CHAR(2000) DEFAULT 'a' NOT NULL );

추가된 컬럼은 모두 Char Type이며 Default 값이 ‘a’ 이다. Char Type이므로 Default값인 ‘a’가 들어오는 경우 컬럼 size는 각각 100, 1000, 2000 바이트씩 채워진다. 이제 이 컬럼들을 이용하여 SQL을 각각 실행해보자. 100 byte, 1000 byte, 2000 byte 컬럼으로 각각 Sort하여 Sort의 부하가 어떻게 달라지는지 알아보자.

CREATE TABLE SORT_100 NOLOGGING AS

SELECT /*+ full(p) full(c) */

s.prod_id, p.prod_name, s.cust_id, c.cust_first_name,

c.cust_last_name, s.time_id, s.channel_id, s.char_100

FROM sales_t s, customers c, products p

WHERE s.cust_id = c.cust_id

AND s.prod_id = p.prod_id

AND s.prod_id = 30

ORDER BY s.char_100 ;

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

| 0 | CREATE TABLE STATEMENT | | 1 | 0 |00:00:01.41 | 7323 | |

| 1 | LOAD AS SELECT | | 1 | 0 |00:00:01.41 | 7323 | 521K (0)|

| 2 | SORT ORDER BY | | 1 | 29282 |00:00:01.23 | 5915 | 4708K (0)|

|* 3 | HASH JOIN | | 1 | 29282 |00:00:01.15 | 5915 | 3471K (0)|

| 4 | TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 |00:00:00.21 | 1468 | |

| 5 | NESTED LOOPS | | 1 | 29282 |00:00:00.66 | 4447 | |

|* 6 | TABLE ACCESS FULL | PRODUCTS | 1 | 1 |00:00:00.01 | 7 | |

|* 7 | TABLE ACCESS FULL | SALES_T | 1 | 29282 |00:00:00.59 | 4440 | |

------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."CUST_ID"="C"."CUST_ID")

6 - filter("P"."PROD_ID"=30)

7 - filter("S"."PROD_ID"=30)

100 byte컬럼으로 Sort하니 PGA를 4.7MB 사용하였다. 이제 100 byte보다 10배나 큰 1000 byte 컬럼으로 Sort 하여 PGA 사용량을 비교해보자.

CREATE TABLE SORT_1000 NOLOGGING AS

SELECT /*+ full(p) full(c) */

s.prod_id, p.prod_name, s.cust_id, c.cust_first_name,

c.cust_last_name, s.time_id, s.channel_id, s.char_1000

FROM sales_t s, customers c, products p

WHERE s.cust_id = c.cust_id

AND s.prod_id = p.prod_id

AND s.prod_id = 30

ORDER BY s.char_1000 ;

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

| 0 | CREATE TABLE STATEMENT | | 1 | 0 |00:00:02.17 | 13162 | |

| 1 | LOAD AS SELECT | | 1 | 0 |00:00:02.17 | 13162 | 521K (0)|

| 2 | SORT ORDER BY | | 1 | 29282 |00:00:01.75 | 5915 | 30M (0)|

|* 3 | HASH JOIN | | 1 | 29282 |00:00:01.56 | 5915 | 3486K (0)|

| 4 | TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 |00:00:00.22 | 1468 | |

| 5 | NESTED LOOPS | | 1 | 29282 |00:00:01.05 | 4447 | |

|* 6 | TABLE ACCESS FULL | PRODUCTS | 1 | 1 |00:00:00.02 | 7 | |

|* 7 | TABLE ACCESS FULL | SALES_T | 1 | 29282 |00:00:00.98 | 4440 | |

------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."CUST_ID"="C"."CUST_ID")

6 - filter("P"."PROD_ID"=30)

7 - filter("S"."PROD_ID"=30)

Sort 컬럼의 size를 100에서 1000 byte로 늘리자 PGA 사용량도 4.7 MB에서 30 MB로 크게 늘었다. 내친김에 Order By절을 2000 byte 컬럼으로 바꿔서 PGA 사용량이 얼마나 늘어나는지 테스트 해보자.

CREATE TABLE SORT_2000 NOLOGGING AS

SELECT /*+ full(p) full(c) */

s.prod_id, p.prod_name, s.cust_id, c.cust_first_name,

c.cust_last_name, s.time_id, s.channel_id, s.char_2000

FROM sales_t s, customers c, products p

WHERE s.cust_id = c.cust_id

AND s.prod_id = p.prod_id

AND s.prod_id = 30

ORDER BY s.char_2000 ;

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

| 0 | CREATE TABLE STATEMENT | | 1 | 0 |00:00:03.16 | 19298 | |

| 1 | LOAD AS SELECT | | 1 | 0 |00:00:03.16 | 19298 | 521K (0)|

| 2 | SORT ORDER BY | | 1 | 29282 |00:00:02.06 | 5915 | 58M (0)|

|* 3 | HASH JOIN | | 1 | 29282 |00:00:01.74 | 5915 | 3515K (0)|

| 4 | TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 |00:00:00.24 | 1468 | |

| 5 | NESTED LOOPS | | 1 | 29282 |00:00:01.19 | 4447 | |

|* 6 | TABLE ACCESS FULL | PRODUCTS | 1 | 1 |00:00:00.02 | 7 | |

|* 7 | TABLE ACCESS FULL | SALES_T | 1 | 29282 |00:00:01.12 | 4440 | |

------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."CUST_ID"="C"."CUST_ID")

6 - filter("P"."PROD_ID"=30)

7 - filter("S"."PROD_ID"=30)

예상대로 Sort 대상 컬럼을 1000에서 2000 byte로 바꾸자 PGA 사용량이 30 MB에서 58MB 로 약 두 배 늘었다. 위의 결과를 언뜻 보면, Order By절에 존재하는 컬럼 Size의 합계가 가로라고 생각할 수 있다. 왜냐하면, Sort 대상컬럼의 Size에 비례하여 PGA 사용량이 증가되었다고 판단하기 때문이다. 하지만 이런 생각은 절반만 옳고 나머지 절반은 틀렸다. 제대로 된 식은 다음과 같다.

Sort의 부하를 좌우하는 원리

Sort의 부하량(PGA 사용량) ∝ 세로 X 가로

세로: SQL의 결과 건수

가로: Order by 절의 컬럼 size + Order by 절을 제외한 나머지 컬럼의 size

근거 있는 주장인가?
이 공식이 글 전체의 핵심이다. 하지만, 많은 사람들이 위와 같은 가로 세로 개념을 주장할 수 있는 근거가 무엇인지 궁금해한다. 이제 가로가 Order by 절의 컬럼 size + 나머지 컬럼의 size라는 주장에 대한 근거를 보자.

SELECT s.channel_id, s.char_2000

FROM sales_t s

WHERE s.prod_id = 30

ORDER BY s.channel_id;

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 29282 |00:00:00.84 | 4440 | |

| 1 | SORT ORDER BY | | 1 | 29282 |00:00:00.84 | 4440 | 56M (0)|

|* 2 | TABLE ACCESS FULL| SALES_T | 1 | 29282 |00:00:00.68 | 4440 | |

------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."PROD_ID"=30)

Order By절에는 Size가 작은 channel_id 컬럼 뿐이다. 그런데 PGA 사용량은 56 MB나 된다. 세로가 3만 건도 안 되는 집합을 Sort하는데 그 부하는 56 MB나 된다. 이상하지 않은가? 과부하의 이유는 Select절의 char_2000 컬럼 때문이다. 이 컬럼을 Select 절에서 제거하고 다시 실행해 보자.

SELECT s.channel_id

FROM sales_t s

WHERE s.prod_id = 30

ORDER BY s.channel_id;

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 29282 |00:00:00.64 | 4440 | |

| 1 | SORT ORDER BY | | 1 | 29282 |00:00:00.64 | 4440 | 424K (0)|

|* 2 | TABLE ACCESS FULL| SALES_T | 1 | 29282 |00:00:00.58 | 4440 | |

------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."PROD_ID"=30)

Order By절 이외의 컬럼에 주목하라
Select절의 char_2000 컬럼을 제거하자 Sort의 부하는 424K로 급격히 줄어들었다. 왜냐하면, Sort Area에는 Order By절의 컬럼을 Sort할뿐만 아니라 나머지 컬럼 List도 Loading 되기 때문이다. Order By절 뿐만 아니라, Select 절에도 size가 큰 컬럼이 있다면 성능이 급격히 저하됨을 알 수 있다. 지금까지 Sort부하량 공식에 의해 가로는 Order By절 컬럼 Size + Sort 대상 이외의 컬럼 Size가 됨을 증명해 보았다.

이제 이 개념을 실제 SQL 프로그래밍에 적용해보자. 아래는 전형적인 Pagination SQL이다. 아래의 예제에서 처음의 약속을 지키기 위해 인덱스를 만들지도, 사용하지도 않을 것이다.

SELECT *

FROM (SELECT a.*, ROWNUM rnum

FROM (SELECT s.prod_id, p.prod_name, p.prod_category_desc, s.cust_id,

c.cust_first_name, c.cust_last_name, s.time_id, s.channel_id,

s.char_100, s.char_1000, s.char_2000

FROM sales_t s, customers c, products p

WHERE s.cust_id = c.cust_id

AND s.prod_id = p.prod_id

AND s.channel_id = 3

ORDER BY c.cust_first_name, c.cust_last_name, p.prod_category_desc, s.time_id ) a

WHERE ROWNUM <= :v_max_row ) --> 200 대입

WHERE rnum >= :v_min_row ; --> 1 대입

--------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 200 |00:00:08.71 | 5915 | |

|* 1 | VIEW | | 1 | 200 |00:00:08.71 | 5915 | |

|* 2 | COUNT STOPKEY | | 1 | 200 |00:00:08.71 | 5915 | |

| 3 | VIEW | | 1 | 200 |00:00:08.71 | 5915 | |

|* 4 | SORT ORDER BY STOPKEY| | 1 | 200 |00:00:08.71 | 5915 | 3321K (0)|

|* 5 | HASH JOIN | | 1 | 540K|00:00:06.30 | 5915 | 1176K (0)|

| 6 | TABLE ACCESS FULL | PRODUCTS | 1 | 72 |00:00:00.01 | 7 | |

|* 7 | HASH JOIN | | 1 | 540K|00:00:03.91 | 5908 | 3568K (0)|

| 8 | TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 |00:00:00.21 | 1468 | |

|* 9 | TABLE ACCESS FULL | SALES_T | 1 | 540K|00:00:01.14 | 4440 | |

--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

2 - filter(ROWNUM<=:V_MAX_ROW)

4 - filter(ROWNUM<=:V_MAX_ROW)

5 - access("S"."PROD_ID"="P"."PROD_ID")

7 - access("S"."CUST_ID"="C"."CUST_ID")

9 - filter("S"."CHANNEL_ID"=3)

페이징 처리된 SQL의 Sort 부하량은 3321K 이다. 이제 Sort의 부하를 줄이기 위해 select 절의 모든 컬럼을 제거하자.

SELECT s.prod_id, p.prod_name, p.prod_category_desc, s.cust_id,

c.cust_first_name, c.cust_last_name, s.time_id, s.channel_id,

s.char_100, s.char_1000, s.char_2000

FROM (SELECT a.*, ROWNUM rnum

FROM (SELECT s.rowid as s_rid, p.rowid as p_rid, c.rowid as c_rid

FROM sales_t s, customers c, products p

WHERE s.cust_id = c.cust_id

AND s.prod_id = p.prod_id

AND s.channel_id = 3

ORDER BY c.cust_first_name, c.cust_last_name, p.prod_category_desc, s.time_id ) a

WHERE ROWNUM <= :v_max_row ) a, --> 200 대입

sales_t s, customers c, products p

WHERE s.rowid = a.s_rid

and c.rowid = a.c_rid

and p.rowid = a.p_rid

and rnum >= :v_min_row ; --> 1 대입

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 200 |00:00:06.51 | 6168 | |

| 1 | NESTED LOOPS | | 1 | 200 |00:00:06.51 | 6168 | |

| 2 | NESTED LOOPS | | 1 | 200 |00:00:06.51 | 5969 | |

| 3 | NESTED LOOPS | | 1 | 200 |00:00:06.51 | 5918 | |

|* 4 | VIEW | | 1 | 200 |00:00:06.51 | 5915 | |

|* 5 | COUNT STOPKEY | | 1 | 200 |00:00:06.51 | 5915 | |

| 6 | VIEW | | 1 | 200 |00:00:06.51 | 5915 | |

|* 7 | SORT ORDER BY STOPKEY | | 1 | 200 |00:00:06.51 | 5915 |96256 (0)|

|* 8 | HASH JOIN | | 1 | 540K|00:00:05.81 | 5915 | 1193K (0)|

| 9 | TABLE ACCESS FULL | PRODUCTS | 1 | 72 |00:00:00.01 | 7 | |

|* 10 | HASH JOIN | | 1 | 540K|00:00:03.65 | 5908 | 4514K (0)|

| 11 | TABLE ACCESS FULL | CUSTOMERS | 1 | 55500 |00:00:00.22 | 1468 | |

|* 12 | TABLE ACCESS FULL | SALES_T | 1 | 540K|00:00:01.06 | 4440 | |

| 13 | TABLE ACCESS BY USER ROWID| CUSTOMERS | 200 | 200 |00:00:00.01 | 3 | |

| 14 | TABLE ACCESS BY USER ROWID | PRODUCTS | 200 | 200 |00:00:00.01 | 51 | |

| 15 | TABLE ACCESS BY USER ROWID | SALES_T | 200 | 200 |00:00:00.01 | 199 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - filter("RNUM">=:V_MIN_ROW)

5 - filter(ROWNUM<=:V_MAX_ROW)

7 - filter(ROWNUM<=:V_MAX_ROW)

8 - access("S"."PROD_ID"="P"."PROD_ID")

10 - access("S"."CUST_ID"="C"."CUST_ID")

12 - filter("S"."CHANNEL_ID"=3)

Trade Off가 유리한 경우

Sort 부하량이 3321K에서 96K로 약 34.5배 줄어들었다. 이렇게 ROWID만 남기고 select 절의 모든 컬럼을 제거해도 결과는 같다. 왜냐하면, Sort된 상태로 rowid가 보관되어있기 때문이다. 페이징 처리가 모두 끝나고 200건에 대해서만 rowid로 테이블에 접근하기 때문에 테이블의 중복사용에 의한 비효율은 매우 적다. Buffers 항목을 비교해보면 5915 블록에서 6168 블록으로 비효율은 253 블록(4%) 밖에 차이가 나지 않는다. 하지만 Sort의 부하는 34.5배나 줄어들었다. 약간의 Block I/O를 손해 보더라도 Sort의 부하가 아주 큰 경우는 같은 블록을 중복해서 읽어야 함을 알 수 있다.

장점 + 장점

이렇게 Rowid를 제외한 Select List를 인라인뷰 외부로 빼면, Sort 부하의 최소화 이외에 또 다른 효과를 누릴 수도 있다. 인덱스만 읽고 테이블로의 접근을 하지 않을 수 있다. 즉 Where 조건에 최적화된 인덱스가 존재하고, 그 인덱스가 Order By절 컬럼을 포함 한다면 인라인뷰 내부에서는 테이블 접근을 하지 않는다. 물론 Select List의 모든 컬럼들을 가져오려면 테이블을 접근해야 한다. 하지만 위의 예제처럼 Rowid를 사용했다면 페이징 처리가 끝난 후에, 특정 페이지에 해당하는 건들만 테이블로 접근할 수 있으므로 Random Access 도 최소화 된다. Sort를 최소화 하려고 했더니 Block I/O를 최소화 하는것까지 덤으로 얻을 수 있는 것이다.

주의사항

SELECT 절에 상수나 변수 심지어 NULL이 오더라도 PGA 사용량은 증가하므로 주의해야 한다.

SELECT s.cust_id

FROM sales_t s

ORDER BY s.cust_id;

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 918K|00:00:03.38 | 4440 | |

| 1 | SORT ORDER BY | | 1 | 918K|00:00:03.38 | 4440 | 13M (0)|

| 2 | TABLE ACCESS FULL| SALES_T | 1 | 918K|00:00:01.38 | 4440 | |

------------------------------------------------------------------------------------------

Select 절에 다른 컬럼이 없기 때문에 PGA를 13MB 사용 하였다. 이번에는 Select절에 Null을 추가해보자.

SELECT s.cust_id, null

FROM sales_t s

ORDER BY s.cust_id;

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 918K|00:00:03.48 | 4440 | |

| 1 | SORT ORDER BY | | 1 | 918K|00:00:03.48 | 4440 | 17M (0)|

| 2 | TABLE ACCESS FULL| SALES_T | 1 | 918K|00:00:01.37 | 4440 | |

------------------------------------------------------------------------------------------

Select List에 Null을 추가하자 PGA사용량이 4MB 증가했다. 오라클은 Null이나 상수도 컬럼처럼 취급함을 알 수 있다. 따라서 Order by절이 있는 인라인뷰의 Select List에 상수나 변수 혹은 Null을 집어넣는 것은 Sort의 부하를 증가시킨다. 상수나 변수는 Order By가 있는 인라인뷰에 넣지 말고 외부로 빼서 사용하면 된다.

결론
Sort의 부하를 최소화 하려면 Order By절의 컬럼에만 집중해서는 안되며, 전체 컬럼 List를 바라보아야 한다. 또한 프로그래밍을 할 때 상수 하나, 변수 하나의 위치도 고려해야 최적의 성능을 가진 프로그램이 됨을 알 수 있다. 즉 Sort의 최적화는 튜닝의 문제일 뿐만 아니라 프로그래밍의 문제인 것이다. 이점은 Sort 부하량이 무엇으로 결정되는지 개발자도 알아야 하는 이유가 된다.

면적은 가로와 세로로 구성된다.

Sort의 부하량은 면적의 크기에 비례한다.

Sort의 부하량 ∝ 결과 건수 X 전체 컬럼 Size

저작자표시 비영리 동일조건

'Oracle > SQL Tuning' 카테고리의 다른 글

COPY_T 테이블 필요한가? (6)	2011.04.04
SQL튜닝 방법론 (20)	2011.01.27
Pagination과 분석함수의 위험한 조합 (26)	2010.12.23
오라클의 Update문은 적절한가? (15)	2010.04.14
Connect By VS ANSI SQL (7)	2010.02.11

Posted by extremedb

,

오라클 Upgrade 후에 파티션을 만들 수 없어요

Oracle/Partition 2011. 3. 15. 00:04

▶11.2.0.2에서 파티션 생성시 용량부족 현상

▶Partition Large Extents란 무엇인가

▶Deferred Segment Creation과 Partition Large Extents의 관계

오라클 11.2.0.2 에서 황당한 일이 발생했다. DBA는 데이터가 없는 빈 테이블을 파티션으로 생성하려고 했다. 그런데 느닷없이 용량부족 에러가 발생한 것이다. 디스크용량은 10 Giga Bytes나 여유가 있으므로 이런 에러메시지를 만날 이유가 없다. 아무리 파티션이 많은 테이블이라도 기껏해야 100MB 정도의 공간만 있으면 테이블을 문제없이 생성했던 DBA로서는 이유를 알 수 없었다. 어찌되었건 문제를 해결해야 하므로 디스크를 30 Giga Bytes 추가했더니 더 이상 에러가 발생하지 않았다고 한다.

데이터가 한 건도 없는 파티션 테이블 하나 생성하는데 10 Giga Bytes 이상의 저장공간이 필요하다니? 이런 사실이 이상하다고 생각한다면 오라클 11.2.0.2의 새 기능을 모르고 있는 것이다. 새 기능을 모르면 원인을 파악 할 수 없고, 문제를 해결할 수도 없다. 이 글은 오라클의 새 기능이 어떻게 용량부족 에러를 발생시키는지, 그 에러를 예방하는 방법은 무엇인지 설명한다.

해당 테이블 설명

생성하려는 파티션 테이블은 보관기간이 10년이고, 거래일자로 월별 Range 파티션이 되어있고, 서브파티션은 Hash 파티션이 12개씩 잡혀있었다. 그 테이블을 Create 하려면 Disk가 얼마나 필요할까? dba_segments에서 해당 테이블의 용량을 조회 해보니 빈 테이블 하나가 11.52 Giga Bytes나 차지하고 있었다. 이에 따라 다음과 같이 추론 할 수 있다.

주 파티션( 10년 x 12 개월 ) x 서브 파티션( 12 Hash ) x 8MB = 11520 MB

데이터도 없는데 8MB를 소모하는 이유

위의 계산식을 본다면 데이터가 한 건도 없음에도 불구하고, 오라클이 파티션 하나당 8MB를 할당했다는 결론이 나온다. 이런 현상은 11.2.0.2부터 파티션 테이블에서만 발생한다. 파티션 테이블을 만들었을 뿐, 데이터는 한 건도 없다. 그럼에도 불구하고 각 파티션 마다 저장공간을 8MB씩 낭비한 셈이다. 오라클은 왜 이런 무모한 결정을 했을까? 언제나 그렇듯이 비밀은 매뉴얼에 있는 경우가 많다. 아래의 내용이 저장공간을 낭비하는 이유이다.

Note:

Beginning with release 11.2.0.2 of Oracle Database, the default size of the first extent of any new segment for a partitioned table is 8 MB instead of 64 KB. This helps improve performance of inserts and queries on partitioned tables.

매뉴얼 참조: Estimating the Space Use of a Table

위의 글을 해석해보면 성능 향상을 위한 목적임을 알 수 있다. 즉, 처음에 8MB 만큼 공간을 미리 할당하면, 추후에 INSERT가 들어올 때 공간을 다시 할당할 필요가 없으므로 속도가 좋아진다는 것. 그리고 자잘한 extent로 쪼개짐을 방지하여 쿼리의 성능을 높이자는 것이다. 이를 partition large extent 라고 한다. 이론적으로는 무모한 결정이 아님을 알 수 있다.

성능 때문에 용량 문제가 발생해도 좋은가?

하지만 이 개념 때문에 파티션 개수가 많은 테이블을 생성하지 못하는 문제가 생긴다. 즉 빈 공간이 90 기가 바이트라고 해도, 파티션 개수가 많은 테이블들은 몇 개도 생성하지 못한다는 결론이 나온다. 이런 기능을 성능이 빨라진다고 해서 오라클이 무조건 적용 할 수 있을까? 오라클은 무언가 믿는 구석이 있었기 때문에 자신 있게 적용할 수 있었다. 그것이 무엇일까? 11.2 매뉴얼을 읽어본 사람이라면 추측 할 수 있을 것이다.

빗나간 예측
Understand Deferred Segment Creation 의 note 부분을 참조하면 오라클이 자신감 있게 파티션 마다 8MB를 할당할 수 있었던 이유가 나온다. Deferred Segment Creation(이하 DSC)이라는 기능 때문이다. DSC 기능 덕분에 테이블이 생성될 때는 물리적인 Disk 공간을 차지하지 않는다. 다시 말해, 테이블을 만들 때 공간을 할당하는 것이 아니라, 추후에 데이터가 insert 될 때 각 파티션에 대해 8MB씩 할당한다. DSC는 버전 11.2.0.2 부터 일반테이블 뿐만 아니라, 파티션 테이블에도 적용이 가능해졌다. 오라클은 파티션마다 8MB씩 할당해야 되지만 DSC 기능이 있으므로, 파티션을 생성할 때는 용량문제가 없을 것이라고 생각했을 것이다.

하지만, 항상 문제가 되는 것은 이론이 아니라 현실에서 발생한다. 현실에서는 여러 가지 버그 때문에 DSC를 사용할 수 없다. 따라서 해당 파라미터인 DEFERRED_SEGMENT_CREATION을 False로 놓을 수 밖에 없다. DSC를 사용할 수 없으므로 테이블을 만들 때 각 파티션마다 물리적인 디스크 공간을 8MB씩 차지하게 된다. 따라서, 파티션 개수가 많은 테이블을 만들 때 DSC 기능이 꺼져 있다면 용량부족 현상이 발생할 수 밖에 없다. 오라클로서도 어쩔 수 없는 일이다. 버그를 예상할 수는 없는 노릇 아닌가? DSC의 버그가 해결되면 이런 문제는 자연스럽게 사라질 것이다.

DSC에 관한 버그는 조동욱 님의 글 Deferred Segment Creation의 재미있는 두가지 버그를 참고하기 바란다.

해결방법

DSC는 현재 버그가 있으므로, 기능을 사용하지 못한다. 따라서 무조건 각 파티션에 8MB씩 할당이 되므로 엄청난 Disk 공간이 필요한 것이다. 파티션 테이블을 11.2.0.2 이상에서 생성할 계획이라면 수동으로 STORAGE (INITIAL 65536) 를 주면 된다. 이렇게 하면 처음에 8MB가 아니라 64KB만 공간을 차지한다. 이렇게 설정하면 이전 버전 11.2.0.1처럼 사용하는 것이다.

관련 파라미터

_partition_large_extents의 Default 값은 True이다. True로 되어있으면 각 파티션에 64kb가 아니라 8MB가 할당된다. 이 파라미터는 버전 11.2.0.1의 cell_partition_large_extents 파라미터를 대체한다. _index_partition_large_extents 도 위의 파라미터와 같은 역할을 한다. 다만 파티션이 아니라 파티션 인덱스라는 점만 다르다. 두 가지 파라미터 _partition_large_extents와 _index_partition_large_extents는 모두 11.2.0.2에서 소개되었다.

결론

11.2.0.2에서 버그 때문에 DSC 기능을 막아 놓았다면, 파티션 테이블을 생성할 때 STORAGE 절에 적절한 INITIAL 값을 주기 바란다. 그렇지 않으면 Disk 공간을 많이 차지하게 된다. 특히 각 파티션당 용량이 많지 않지만 관리목적상 파티션을 하는 경우는 INITIAL 값을 주는 것이 유리하다. 이렇게 하면 저장공간을 낭비하지 않고 테이블을 관리 할 수 있다. 또한 개발 DB는 운영 DB에 비해 Disk가 부족하므로 이런 사실을 잘 알아야 에러가 나더라도 당황하지 않는다. 개인적인 목적으로 PC나 노트북등에 오라클을 설치하는 경우도 Disk가 넉넉하지 않을 것이므로 마찬가지이다.

오라클 매뉴얼은 여러 번 보아야 한다. 예를 들어 11.2.0.1 매뉴얼을 이미 정독한 사람은 11.2.0.2 매뉴얼을 볼 필요가 없다고 생각 할 수 있다. 결코 그렇지 않다. 이 글에서 나타난 문제만 보아도 11.2.0.2 매뉴얼을 보았다면 전혀 문제가 되지 않을 것이다. 따라서 이전 매뉴얼을 정독 했더라도 11.2.0.2 버전의 새로운 기능은 익혀야 한다. 물론 매뉴얼 전체를 다시 볼 필요는 없다. 예를 들어 Admin가이드의 경우 매뉴얼의 첫 부분인 What's New in Oracle Database Administrator's Guide? 만 참조하면 무슨 기능이 추가된 것인지 쉽게 파악 할 수 있다. 어디에 무슨 내용이 있는지 안다면, 문제의 절반은 해결한 셈이다.

관련문서

매뉴얼: Oracle® Database Administrator's Guide 11g Release 2 (11.2)
오라클 노트: 1295484.1

저작자표시 비영리 동일조건

'Oracle > Partition' 카테고리의 다른 글

Oracle 10g Partitioning 가이드 (12)	2009.08.05

Posted by extremedb

,

분석함수의 성능개선 그 결과는?

Oracle/Data Access Pattern 2011. 2. 18. 01:04

▶분석함수의 비효율을 찾는 방법
▶분석함수의 성능개선 원리
▶분석함수의 실행계획 3부 - 심화과정의 모범답안

이번 글이 분석함수의 실행계획 시리즈의 마지막이다. 1부와 2부에서 분석함수의 실행계획에 대해서 알아보았다. 이 글(3부)은 새로 작성되었으며, 이전 글( 문제 출제용 )은 삭제하지 않고 그대로 두었음을 밝혀둔다. 나중에라도 문제를 풀어볼 사람은 이 글(답안)을 보지 말고, 이전 글을 보기 바란다. 각각의 답안은 오렌지색으로 표시해 두었으므로 쉽게 채점할 수 있을 것이다.

분석함수의 다섯 가지 원리
많은 수의 개발자, DBA, 튜너들은 분석함수를 만나면 식은 땀을 흘린다. 왜냐하면, 분석함수의 비효율을 어떻게 찾을 수 있는지, 또 그 비효율은 어떻게 제거 할 수 있는지 알 수 없기 때문이다. 기껏해야 분석함수의 over절을 만족하는 적절한 인덱스를 생성하는 정도이다. 어쩌면 이런 결과들은 당연하다고 볼 수 있다. 매뉴얼이나 튜닝 책에 분석함수의 비효율을 발견하는 방법과 개선방법에 대한 언급이 별로 없기 때문이다. 이런 어려움을 겪고 있는 여러 사람들의 요구에 의해서 이 글이 만들어졌다. 분석함수의 비효율을 찾고, 성능을 향상시킬 수 있는 다섯 가지 방법을 공개하니, 많은 사람들이 적용하여 더 이상 식은 땀은 흘리지 않기 바란다.

SQL 두 개에 5가지 비효율이 있다. 이것들을 제거하라
이 글에서 설명되는 두 개의 SQL은 길이가 매우 짧다. 그 중 하나는 비효율을 찾아내기 쉽고, 나머지 하나는 어렵다. 두 개의 SQL에는 총 5가지의 튜닝 포인트가 있다. 각각의 포인트는 20점이며 5가지를 모두 맞추는 경우는 100점이 된다. 채점 시 중요한 점은, 독자들이 직접 튜닝한 SQL이 모범답안과 같은지 비교하는 것이 아니라는 것이다. 그것 보다는 비효율을 몇 개 잡아내었는지, 또한 각각의 비효율을 개선시킬 수 있는 방법은 몇 개나 생각했는지를 채점하는 것이다. 이렇게 채점하면, 내가 아는 것은 무엇이고, 모르는 것은 무엇인지 명확히 드러난다. 즉, 무엇을 더 공부해야 하는지 알 수 있다.

다른 사람들은 몇 점 정도 받았나?
몇몇 지인들에게 퀴즈를 내본 결과 100점은 아무도 없었다. 즉 80점이 평균적인 튜너의 수준이라는 이야기 이다. 개발자의 경우는 60점이면 상위 수준이다. 점수에 대해 오해는 하지 말기 바란다. 이 퀴즈로 받은 점수는 분석함수의 성능과 관련된 것일 뿐, 전반적인 SQL 튜닝능력에 대한 점수가 아니다.

이제 실습을 위한 테이블과 인덱스를 생성하자. 실습환경은 Oracle 10g R2, Oracle 11g R1, Oracle 11g R2로 한정한다.

CREATE TABLE SALES_T NOLOGGING AS SELECT * FROM SALES;

ALTER TABLE SALES_T ADD CONSTRAINT PK_SALES_T

PRIMARY KEY (PROD_ID, CUST_ID, CHANNEL_ID, TIME_ID) USING INDEX;

개발자가 작성한 문제의 SQL 1

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

MAX(TIME_ID) OVER( PARTITION BY CUST_ID ,CHANNEL_ID ) AS MAX_TIME

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE TIME_ID = MAX_TIME;

업무설명 : 상품번호 30인 데이터에 대하여 고객별, 채널 별로 가장 최근의 판매량을 나타내시오.

단 고객별, 채널별로 가장 최근의 데이터는 2건 이상일 수 있음.

-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 12649 |00:00:00.31 | 28337 | |

|* 1 | VIEW | | 12649 |00:00:00.31 | 28337 | |

| 2 | WINDOW BUFFER | | 29282 |00:00:00.27 | 28337 | 1495K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.17 | 28337 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 29282 |00:00:00.03 | 118 | |

-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("TIME_ID"="MAX_TIME")

4 - access("PROD_ID"=30)

WHERE 절에 TIME_ID = MAX_TIME 이 존재하는 이유는 고객별, 채널별로 MAX(TIME_ID)에 해당하는 데이터가 두건 이상일 수 있기 때문이다. 이런 경우는 자주 발생한다. 이해를 돕기 위해 비슷한 예를 들어보자. 부서별로 최대급여를 받는 사람들을 출력하고자 할 때, 1번 부서의 최대급여는 1억 원이라고 하자. 그런데 그 부서에서 1억 원(최대급여)을 받는 사람은 강호동, 유재석 둘이라는 이야기 이다.

위의 SQL은 답이 정확하다. 하지만 성능은 비효율이 있어서 별로 신통치 못하다. 이제 문제를 보자. 위 SQL에 여전히 남아있는 비효율을 개선하는 것이 문제이다.

문제1) 위의 SQL 에서 성능상 문제점을 발견하고 개선하시오. 문제점은 두 가지(분석함수의 관점, 일반적인 SQL튜닝의 관점) 이다. 단 인덱스를 추가로 생성하거나 변경해서는 안 된다.

문제 1의 답안

비효율 1은 Sample 답안이다. 점수에 반영되지 않는다.

문제1의 비효율 1 : SALES_T 테이블에 Random Access가 불필요하게 많이 발생한다. 12649 번만 테이블로 액세스 하면 되지만 실제로는 29282 번 액세스함으로써 비효율이 발생되었다.

문제1의 비효율 1의 해결방법 : PK인덱스에 AMOUNT_SOLD가 포함되어 있지 않으므로 Select 절에서 AMOUNT_SOLD를 빼면 인덱스만 액세스 하게 됨. 이때 Rowid를 추가로 Select 해야 한다. 이후에 이미 인덱스에서 Filter된 Rowid로 테이블을 액세스하면 Random Access는 정확히 12649번 만 시도한다. 아래에 SQL이 있으므로 참조하시오.

문제1의 비효율1이 해결된 SQL과 실행계획 제시:

SELECT /*+ LEADING(S) USE_NL(S1) */

S.PROD_ID, S.CUST_ID, S.TIME_ID, S.CHANNEL_ID, S1.AMOUNT_SOLD

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID,

MAX(TIME_ID) OVER( PARTITION BY CUST_ID ,CHANNEL_ID ) AS MAX_TIME,

ROWID AS RID

FROM SALES_T T

WHERE PROD_ID = 30 ) S,

SALES_T S1

WHERE S.TIME_ID = S.MAX_TIME

AND S1.ROWID = S.RID;

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 12649 |00:00:02.72 | 11237 | |

| 1 | NESTED LOOPS | | 1 | 12649 |00:00:02.72 | 11237 | |

|* 2 | VIEW | | 1 | 12649 |00:00:00.18 | 118 | |

| 3 | WINDOW BUFFER | | 1 | 29282 |00:00:00.13 | 118 | 1432K (0)|

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

| 5 | TABLE ACCESS BY USER ROWID| SALES_T | 12649 | 12649 |00:00:02.48 | 11119 | |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."TIME_ID"="S"."MAX_TIME")

4 - access("PROD_ID"=30)

이렇게 해서 Sample 답안을 작성해 보았다. 이 방법은 분석함수의 튜닝방법이 아니라 예외적으로 SQL 튜닝방법론에서 언급되었던 방법을 사용하였다. 물론 여기서 페이징처리를 한다면 추가적인 성능향상이 가능하지만 Sample이므로 여기서 멈추기로 한다. 위의 답안은 Sample 이므로 점수에서 빠진다. 또한 이 부분은 분석함수의 튜닝 방법이 아니다. 하지만 앞으로 풀게 될 문제들은 모두 분석함수와 관련된 문제들이다.

문제1의 비효율 2

비효율 1을 제거하니 Random Access는 최소화 되었다. 하지만 실행계획을 보면 쓸데없이 PGA를 1432K만큼 사용하고 있다. 즉 불필요한 WINDOW BUFFER Operation 때문에 sort가 발생하였다.

문제1의 비효율 2 해결방법

고객별 채널별로 최종일자의 데이터를 구하는 것이므로, Rank를 사용하면 적절한 인덱스가 존재하므로 sort를 하지 않는다. Rank는 Row_number와는 다르게 1등이 두 명 이상일 수 있으므로 업무조건을 만족한다.

문제1의 비효율 2이 해결된 SQL과 실행계획 제시.

SELECT /*+ LEADING(A) USE_NL(B) */ A.*, B.AMOUNT_SOLD

FROM ( SELECT /*+ INDEX_DESC(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID,

RANK() OVER(PARTITION BY CUST_ID, CHANNEL_ID ORDER BY TIME_ID DESC) RNK,

ROWID AS RID

FROM SALES_T T

WHERE PROD_ID = 30 ) A,

SALES_T B

WHERE A.RNK = 1

AND A.RID = B.ROWID;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 12649 |00:00:00.32 | 11240 | |

| 1 | NESTED LOOPS | | 1 | 12649 |00:00:00.32 | 11240 | |

|* 2 | VIEW | | 1 | 12649 |00:00:00.20 | 120 | |

|* 3 | WINDOW NOSORT | | 1 | 29282 |00:00:00.16 | 120 | |

|* 4 | INDEX RANGE SCAN DESCENDING| PK_SALES_T | 1 | 29282 |00:00:00.06 | 120 | |

| 5 | TABLE ACCESS BY USER ROWID | SALES_T | 12649 | 12649 |00:00:00.05 | 11120 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("A"."RNK"=1)

3 - filter(RANK() OVER ( PARTITION BY "CUST_ID","CHANNEL_ID" ORDER BY INTERNAL_FUNCTION("TIME_ID") DESC )<=1)

4 - access("PROD_ID"=30)

이제 문제2를 풀어보자.

개발자가 작성한 문제의 SQL 2

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER ( PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID NULLS FIRST) AS RN,

SUM(AMOUNT_SOLD) OVER ( ORDER BY CUST_ID,CHANNEL_ID,TIME_ID,PROMO_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.43 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.43 | 28337 | |

|* 2 | WINDOW SORT PUSHED RANK | | 1 | 29282 |00:00:00.40 | 28337 | 1999K (0)|

| 3 | WINDOW SORT | | 1 | 29282 |00:00:00.30 | 28337 | 1684K (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.18 | 28337 | |

|* 5 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.04 | 118 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( PARTITION BY "PROD_ID" ORDER BY "CUST_ID","CHANNEL_ID",INTERNAL_FUNCTION("TIME_ID")

NULLS FIRST)<=10)

5 - access("PROD_ID"=30)

문제2) 위의 SQL 에서 분석함수의 성능상 문제점을 발견하고 개선하시오. 분석함수와 관련된 성능상 문제점은 4가지 이다. 비효율들을 발견하고 이를 모두 개선해야 한다. 단 인덱스를 추가로 생성하거나 변경하면 안 된다.

튜닝의 결과부터 이야기 하자면, Sort량은 3683 K 에서 0 K 로 줄어들었고 Block I/O량은 28337 에서 15 로 줄어들었다. 성능이 몇 배나 개선되었는지 계산하기도 힘들 정도이다. 결과건수가 많아 질수록 이 차이는 점점 더 벌어질 것이다. 성능이 어떻게 개선된 것일까? 지금부터 비효율을 하나씩 벗겨내고 개선방법을 도출해보자.

문제 2의 답안

문제2의 비효율 1

NULLS FIRST를 사용하면 인덱스를 Ascending으로 사용하면 null 값은 가장 마지막에 출력된다. 즉 null 값이 마치 가장 큰 값인 것처럼 저장 되는 것이다. 하지만 NULLS FIRST를 명시하는 순간 sort가 뒤바뀌어 가장 먼저 출력해야 한다. 즉 인덱스를 사용했지만 NULLS FIRST 때문에 추가적인 sort가 필요하다는 이야기 이다. 이러한 문제는 인덱스를 Descending 하게 사용할 때, NULLS LAST를 명시해도 똑같이 발생한다.

문제2의 비효율 1 해결방법

문제의 SQL을 보면 PARTITION BY나 ORDER BY의 컬럼들은 PK 컬럼들이므로 null 일수 없다. 따라서 NULLS FIRST를 삭제해도 무방하다. 다시 작성한 SQL은 다음과 같다.

문제2의 비효율 1이 해결된 SQL과 실행계획 제시

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER ( ORDER BY CUST_ID,CHANNEL_ID,TIME_ID,PROMO_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.45 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.45 | 28337 | |

|* 2 | WINDOW NOSORT | | 1 | 29282 |00:00:00.42 | 28337 | |

| 3 | WINDOW SORT | | 1 | 29282 |00:00:00.32 | 28337 | 1684K (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.17 | 28337 | |

|* 5 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( PARTITION BY "PROD_ID" ORDER BY "CUST_ID","CHANNEL_ID","TIME_ID")<=10)

5 - access("PROD_ID"=30)

ROW_NUMBER에 해당하는 Operation이 WINDOW SORT PUSHED RANK에서 WINDOW NOSORT로 바뀌었다. 그 영향으로 ROW_NUMBER는 Sort가 전혀 발생하지 않는다.

문제2의 비효율 2

비효율 1의 튜닝의 결과를 놓고 보면, ROW_NUMBER와 SUM 분석함수의 Operation이 실행계획에 각각 존재한다. 즉 분석함수가 따로 따로 두 번 실행되는 것이다. 분석함수의 종류는 두 개(row_number와 sum)라 하더라도, 분석함수와 관련된 Operation이 한번만 나와야 한다는 말이다. 또한 분석함수 SUM의 order by절에 PROMO_ID가 존재하여 불필요한 sort가 발생하였다.

문제2의 비효율 2 해결방법

이 비효율을 없애면 마치 분석함수가 하나뿐인 것처럼 만들 수 있다. Partition 절과 Order 절을 일치시키면 된다. 아래의 SQL은 Partition 절과 Order 절을 일치시키기 위해 SUM 분석함수에 PARTITION BY 절을 추가해야 한다. 물론 ROW_NUMBER함수에서 Partition By절을 삭제할 수 있지만, 그와 관련된 이야기는 이후 단계에서 논의 되므로, 여기서는 그냥 Partition By절을 추가하기로 한다. 그리고 WINDOW SORT를 유발하는 PROMO_ID도 삭제해야 한다.

문제2의 비효율 2가 해결된 SQL과 실행계획 제시

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.26 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.26 | 28337 | |

| 2 | WINDOW BUFFER | | 1 | 29282 |00:00:00.23 | 28337 | 1495K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.11 | 28337 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

4 - access("PROD_ID"=30)

만약 해결방법 두 가지(Partition By 추가, PROMO_ID 삭제)중 한가지만 적용했다면 10점으로 처리하면 되므로 채점은 가능하다. 아래의 설명부분과 SQL은 답안이 아니며, 원리를 설명하는 부분이다.

Operation 통합의 원리
분석함수 SUM에 Partition By절을 추가하고, order by절에 PROMO_ID를 삭제하니, 예상대로 분석함수 두 개의 Plan이 하나로 합쳐졌다. 여기서 알 수 있는 점은 두 가지 이다. 첫 번째, Partition By와 Order By를 통일 시키면 Operation이 통합되어 분석함수 하나만 실행시키는 결과를 얻는다. 두 번째, WINDOW NOSORT(ROW_NUMBER) + WINDOW BUFFER(SUM) 가 합쳐져서 WINDOW BUFFER가 되었다는 점이다. 좋지 않은 Operation으로 통합된다는 것을 알 수 있다. 기준은 다음과 같다.

WINDOW NOSORT + WINDOW SORT => WINDOW SORT

WINDOW NOSORT + WINDOW BUFFER => WINDOW BUFFER

WINDOW BUFFER + WINDOW SORT => WINDOW SORT

PROMO_ID를 삭제해도 되는 이유는 ORDER BY에서 모든 PK 컬럼을 사용하였기 때문이다. 즉 PK 컬럼들로 ORDER BY절에서 모두 SORT 되었으므로, 나머지 컬럼으로 아무리 SORT 해보아야 결과는 동일하다는 것이다. Order By절에서 PROMO_ID를 삭제하자 WINDOW SORT가 WINDOW BUFFER 로 바뀌었다. 이에 따라 PGA사용량이 1747K에서 1495K 약간 줄어들었다.

만약 Partition By만 추가하고 PROMO_ID를 삭제하지 않으면 아래와 같이 sort의 비효율이 발생한다.

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID,PROMO_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.33 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.33 | 28337 | |

| 2 | WINDOW SORT | | 1 | 29282 |00:00:00.30 | 28337 | 1747K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.17 | 28337 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

4 - access("PROD_ID"=30)

Order By절이 다르지만, 통합이 가능한 이유
PROMO_ID를 추가하자, WINDOW SORT가 발생하여 PGA 사용량이 늘어났다. 분석함수 SUM의 ORDER BY절을 보면 PROMO_ID가 있는데 ROW_NUMBER 분석함수에는 PROMO_ID가 없다. ORDER BY는 완벽히 같지 않아도 Operation이 통합 될 수 있다는 점을 알 수 있다. ORDER BY의 마지막 항목이 달라도 Operation이 통합 될 수 있는 원리는 간단하다. Sort 작업을 A + B + C로 이미 했다면 Sort를 A + B 로 다시 해야 할 필요가 없기 때문이다. 즉 A + B + C로 Sort 하는 분석함수 기준으로 A + B로 Sort 하는 분석함수가 통합된다는 의미이다.

오해하지 말 것

서로 다른 종류의 분석함수를 실행했을 때, Partition By의 컬럼과 Order By의 컬럼을 각각 똑같이 맞추어야 하는 것은 아니다. Partition By나 Order By의 컬럼을 각각 맞추는 것이 아니라, OVER절 전체의 컬럼을 일치시키면 된다. 아래의 SQL이 좋은 예제이다.

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER (PARTITION BY PROD_ID ORDER BY CUST_ID, CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER (PARTITION BY PROD_ID, CUST_ID ORDER BY CHANNEL_ID,TIME_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.32 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.32 | 28337 | |

| 2 | WINDOW BUFFER | | 1 | 29282 |00:00:00.28 | 28337 | 1495K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.14 | 28337 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.04 | 118 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

4 - access("PROD_ID"=30)

위의 SQL을 보면 분석함수 두 개의 Partition By의 컬럼과 Order By 컬럼이 모두 다르다. 하지만 실행계획상의 operation은 하나로 통합되었다. 즉 OVER절을 바라볼 때 Partition By나 Order By를 삭제하고 컬럼들만 남긴다면, operation이 통합이 될지, 아닐지 판단할 수 있다. 예컨대, over절의 컬럼은 두 개의 분석함수 모두 PROD_ID + CUST_ID + CHANNEL_ID + TIME_ID 로 똑같으므로 operation이 통합된다.

중요한 것은 컬럼의 순서이다. 즉 Partition By나 Order By를 삭제하고 순수하게 over절의 컬럼들만 남겼을 때, 컬럼의 순서가 같아야 operation이 통합된다. 컬럼의 순서가 다르면 통합되지 않는다. 위의 분석함수 둘은 over절의 컬럼순서가 PROD_ID + CUST_ID + CHANNEL_ID + TIME_ID로 같음을 알 수 있다. OVER절 전체의 컬럼순서가 같다면, 컬럼의 개수와는 상관없이 통합이 가능하다. 예를 들어, 분석함수를 두 개 사용하고 컬럼순서가 하나는 A+B+C 이고 다른 하나는 A+B 라면, 컬럼순서가 동일하므로 통합이 가능하다. 하지만 A+B+C 와 A+C의 조합은 컬럼순서가 다르므로 통합이 불가능하다.

문제2의 비효율 3

비효율 2의 튜닝결과를 보면 Ranking family를 사용하고, 인라인뷰 외부에서 분석함수를 Filter로 처리했음에도 불구하고 STOPKEY가 작동하지 않는다. 이에 따라 부분범위처리가 되지 못하고 불필요한 데이터를 모두 Scan해야 한다.

문제2의 비효율 3의 해결방법

STOPKEY가 작동되도록 하려면 ROW_NUMBER의 OVER절에서 불필요한 PARTITION BY PROD_ID를 제거하면 된다. PROD_ID는 이미 WHERE 절의 Equal 조건에 의하여 상수화 되었기 때문에 PARTITION BY는 필요 없다.

문제2의 비효율 3이 해결된 SQL과 실행계획 제시

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER ( ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER (PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.16 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.16 | 28337 | |

|* 2 | WINDOW NOSORT STOPKEY | | 1 | 10 |00:00:00.16 | 28337 | |

| 3 | WINDOW BUFFER | | 1 | 11 |00:00:00.16 | 28337 | 1495K (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.11 | 28337 | |

|* 5 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "CUST_ID","CHANNEL_ID","TIME_ID")<=10)

5 - access("PROD_ID"=30)

아래의 설명부분과 SQL은 답안이 아니며 원리를 설명하는 부분이다.

Ranking family에서 불필요한 Partition By를 삭제하자 WINDOW NOSORT STOPKEY가 발생되었다. 하지만 실행계획을 자세히 보면 비효율이 존재한다. 즉 WINDOW BUFFER 때문에 29282건을 모두 읽은 후에 STOPKEY가 발생되었다. 처음부터 11건만 읽는 방법은 없는 것일까? 그렇다고 위의 SQL에서 분석함수 SUM의 PARTITION BY도 삭제한다면 비효율 2의 실행계획으로 돌아가 버린다. 비효율 2에서 이미 설명했던 원칙(좋지 않은 Operation으로 통합되는 원칙) 때문에 WINDOW NOSORT STOPKEY가 WINDOW BUFFER에 묻혀버리는 것이다.

만약 WINDOW BUFFER(분석함수 SUM)가 없다면 WINDOW NOSORT STOPKEY가 완벽히 동작한다. 아래의 SQL로 증명할 수 있다.

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER ( ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.01 | 15 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.01 | 15 | |

|* 2 | WINDOW NOSORT STOPKEY | | 1 | 10 |00:00:00.01 | 15 | |

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 11 |00:00:00.01 | 15 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 11 |00:00:00.01 | 4 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "CUST_ID","CHANNEL_ID","TIME_ID")<=10)

4 - access("PROD_ID"=30)

분석함수 SUM만 제거한다면 STOPKEY가 비효율 없이 작동하여 정확히 11건만 읽었다. 위의 실행통계와 비효율 3이 튜닝된 SQL의 실행통계를 비교해보라. Buffers와 Used-Mem 항목을 본다면 비교할 수 없을 정도이다. 또한 WINDOW STOPKEY의 활용범위는 ROWNUM 보다 넓다. 물론 ROW_NUMBER는 ROWNUM 처럼 사용 할 수도 있다. 하지만, RANK나 DENSE_RANK의 경우로 본다면 추가적인 활용법이 있다. 예를 들어, 학교에서 수학성적으로 전교석차 2등 까지 출력한다고 치자. 그러면 1등과 2등이 각각 두 명 이상일 수 있다. 이런 경우는 ROWNUM으로는 구현할 수 없다. RANK나 DENSE_RANK가 WINDOW NOSORT STOPKEY로 성능을 충족시켜면서, 업무요구사항을 만족시키는 유일한 방법이다.

Sort량 2K vs 1999K의 비밀

비효율 3에서는 Partition By를 삭제하여 Sort가 전혀 발생하지 않는 경우를 보았다. 만약 Sort를 동반하는 경우라면, Partition By를 삭제함에 따라 Sort의 일량에 어떤 영향을 끼칠까? 아래의 SQL을 보자.

SELECT *

FROM (SELECT /*+ INDEX(T PK_SALES_T) */

PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER () OVER (ORDER BY CUST_ID, CHANNEL_ID, TIME_ID NULLS FIRST) AS RN,

SUM (AMOUNT_SOLD) OVER (ORDER BY CUST_ID, CHANNEL_ID, TIME_ID, PROMO_ID) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30)

WHERE RN <= 10 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.34 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.34 | 28337 | |

|* 2 | WINDOW SORT PUSHED RANK | | 1 | 11 |00:00:00.34 | 28337 | 2048 (0)|

| 3 | WINDOW SORT | | 1 | 29282 |00:00:00.30 | 28337 | 1684K (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.18 | 28337 | |

|* 5 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.04 | 118 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "CUST_ID","CHANNEL_ID",INTERNAL_FUNCTION("TIME_ID") NULLS FIRST)<=10)

5 - access("PROD_ID"=30)

위의 SQL은 개발자가 작성한 원본 SQL에서 ROW_NUMBER 함수의 Partition By절을 삭제하고 실행한 것이다. 이 경우는 over절의 NULLS FIRST 때문에 Sort가 발생되는 경우이다. 이 때에도 Sort가 최소화 되어 PGA 사용량은 2K에 불과하다. 개발자가 작성한 원본 실행통계의 Sort량이 1999K임을 감안하면 Partition By의 존재유무는 성능에 지대한 영향을 끼친다고 할 수 있다. Sort량이 이렇게 큰 차이가 나는 이유는 파티션을 삭제한 효과 + RN <= 10 조건 때문이다. 그 filter 조건에 의해서 10개의 배열만 관리하면 되므로 PGA 사용량은 최소화 된다. WINDOW SORT PUSHED RANK의 이러한 성격은 인덱스를 사용하지 않는 경우에도 동일하게 나타난다. 위의 SQL에서 힌트를 FULL(T)로 바꾸고 실행하여도 PGA 사용량은 동일하다.

위의 SQL 처럼 ROW_NUMBER 함수의 NULLS FIRST 보다 Partition By절을 먼저 삭제한 사람은 이 원리를 답안으로 사용해도 무방하다. 하지만 비효율 3에서 설명되었던, Partition By 삭제에 의한 NOSORT STOPKEY 유도 원리는 WINDOW SORT PUSHED RANK와 성격이 다르므로 반드시 알아두어야 한다.

문제2의 비효율 4

진퇴양란, 포기할 것인가?

비효율 3의 튜닝결과를 보면 STOPKEY를 발생시키려고 ROW_NUMBER의 Partition By를 제거하니 Operation이 두 개로 분리되어 다시 비효율이 발생하였다. 그렇다고 분석함수 SUM을 삭제하자니 업무요구사항이 만족되지 않는다. 어떻게든 STOPKEY를 발생시켜서 29282건을 모두 읽는 비효율을 제거해야 한다.

분석함수 SUM을 삭제하는 것은 답이 아니다

보통 이런 경우(진퇴양란)에서는 둘 중에 한가지를 선택한다. 튜닝을 포기하거나 장애물을 제거한다. 열정이 있는 개발자들은 장애물을 제거할 것이다. 분석함수 SUM을 삭제하고, 조회화면에서 프로그램 스크립트를 작성하여 분석함수 SUM의 로직을 대신한다. 물론 이렇게 하는 것은 목적을 달성하는 것이므로, 포기하는 것보다는 만족스럽다. 하지만 나는 포기하지도 말고, 프로그래밍 언어의 도움도 받지 말라고 주장한다. SQL이 아닌 다른 언어의 도움으로 비효율을 해결한 것은 이 문제의 정답이 아니며, SQL만으로 해결할 수 있다.

문제2의 비효율 4 해결방법

일부 개발자는 분석함수 SUM을 제거하고 프로그래밍 언어의 도움을 받아 해결하였다. 하지만 우리는 분석함수 SUM을 물리적으로 삭제하는 것이 아니라 실행계획상에서만 삭제하고자 한다. 방법은 SUM/MIN/MAX/AVG 등의 분석함수에 WINDOW의 범위를 명시적으로 작성하면 된다. 물론 범위를 명시적으로 작성해도 답은 동일하다.

문제2의 비효율 4가 해결된 SQL과 실행계획 제시

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER (ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ) AS RN,

SUM(AMOUNT_SOLD) OVER (ORDER BY CUST_ID,CHANNEL_ID,TIME_ID

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.01 | 15 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.01 | 15 | |

|* 2 | WINDOW NOSORT STOPKEY | | 1 | 10 |00:00:00.01 | 15 | |

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 11 |00:00:00.01 | 15 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 11 |00:00:00.01 | 4 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "CUST_ID","CHANNEL_ID","TIME_ID")<=10)

4 - access("PROD_ID"=30)

분석함수 SUM을 제거한 것은 아니지만, WINDOW의 범위를 주어 동일한 효과를 얻었다. 정확히 11건만 읽었으므로, 깔끔하게 모든 문제가 정리되었다. Window의 범위를 명시적으로 작성하는 것이 얼마나 중요한지 알 수 있다.

여기까지가 답안이다. 이제 어떻게 된 것인지 알아보기 위해 분석함수 ROW_NUMBER를 삭제해 보자.

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

SUM(AMOUNT_SOLD) OVER (ORDER BY CUST_ID,CHANNEL_ID,TIME_ID

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 ) ;

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 29282 |00:00:00.36 | 28340 | |

| 1 | VIEW | | 1 | 29282 |00:00:00.36 | 28340 | |

| 2 | WINDOW NOSORT | | 1 | 29282 |00:00:00.30 | 28340 | |

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.20 | 28340 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 121 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("PROD_ID"=30)

그룹분석함수와 Ranking Family를 같이 사용해도 STOPKEY가 발생한다

그룹분석함수임에도 SORT가 전혀 발생하지 않았다. 즉 SUM/MIN/MAX/AVG 등의 분석함수에 WINDOW의 범위를 지정해주면 WINDOW BUFFER가 WINDOW NOSORT로 바뀐다는 이야기 이다. 이것은 의미 있는 발견이다. 왜냐하면 이때 까지는 SUM/MIN/MAX/AVG 등의 분석함수 때문에 적절한 인덱스를 사용하였지만 WINDOW BUFFER가 발생하여 STOPKEY를 발생시키지 못했다. 그런데 이제 WINDOW NOSORT가 가능해짐으로 Ranking Family의 STOPKEY가 정상적으로 작동하기 때문이다.

이제 적절한 인덱스가 있고, SUM등의 그룹분석함수를 사용한다면, 다음과 같은 결론을 내릴 수 있다.

“SUM등의 그룹분석함수를 사용한다면, WINDOW의 범위를 지정해주어야 한다. 그렇게 한다면 Sort가 전혀 발생하지 않을 뿐만 아니라, Ranking Family 분석함수를 rownum 처럼 사용할 때, STOPKEY를 발생시켜 성능이 개선된다.”

분석함수를 만날 때의 자세
2번 문제의 원본 SQL는 매우 짧은 코드이지만, 비효율은 4개나 된다. 튜닝을 완료했다고 자신하는 순간이라도, 마지막 남은 분석함수의 비효율 하나 때문에 SQL의 성능향상은 도루묵이 될 수 있다. 이런 사실은 SQL을 튜닝 할 때, 분석함수를 만나면 안테나를 세워야 하는 이유가 된다.

미래지향

다섯 가지 비효율에 대해 80점 혹은 그 이상을 받은 사람은 분석함수에 관한 튜닝은 상당한 수준에 있다고 생각한다. 반대로, 80점이 안 된다고 실망하지 말자. 왜냐하면 퀴즈에서 실패했더라도, 실무튜닝에서 100점을 받으면 그만이다. 물론 이렇게 되려면, SQL과 실행계획을 보고 비효율을 읽어내는 능력이 필요하다.

마지막으로 다섯 가지의 원리로 이 글 전부를 정리 해보자. 다섯 가지의 원리는 대부분 아래의 구조로 되어있다.

1) 소제목
2) ~ 를 하라.
3) 그렇게 하면 ~ 효과가 있다.

분석함수의 성능향상 원리

1. min/max 분석함수를 Ranking family로 대체하는 원리

적절한 인덱스를 사용하면서, 최종일자에 해당하는 데이터를 구할 때, MAX(최종일자) 분석함수를 사용하지 말고 Ranking family를 사용하라. 그렇게 하면 WINDOW BUFFER를 WINDOW NOSORT로 바꾸어 sort를 방지한다.

2. sort의 기준을 유지하는 원리
적절한 인덱스가 존재하는 경우, 분석함수의 ORDER BY절에 NULL FIRST나 LAST를 삭제할 수 있는지 검토하라. 그렇게 하면 인덱스 사용에 의한 Sort 기준이 유지되므로, 추가적인 sort를 방지한다. 주의사항은 NULL FIRST나 LAST를 사용한다고 해서 항상 Sort의 기준이 바뀌는 것은 아니며, 아래의 경우만 해당한다.

ex1) Index ASC로 사용 + 분석함수의 ORDER BY절에 NULL FIRST 는 추가적인 sort발생

ex2) Index DESC로 사용 + 분석함수의 ORDER BY절에 NULL LAST 는 추가적인 sort발생

3. 여러 개의 분석함수를 하나의 Operation으로 통합하는 원리

적절한 인덱스가 존재하고, 분석함수를 여러 개 사용할 때, 가능하면 OVER절의 Partition By와 Order By절을 일치시켜라. 그렇게 하면 여러 개의 OPERATION이 통합된다. 다시 말해, 분석함수를 하나만 실행하는 효과를 얻어서 실행시간을 단축시킨다. 이때 ORDER BY는 완전히 같지 않아도 Operation은 통합될 수 있다. 단 아래와 같이 좋지 않은 Operation 을 기준으로 통합된다.

ex1) WINDOW NOSORT + WINDOW SORT => WINDOW SORT

ex2) WINDOW NOSORT + WINDOW BUFFER => WINDOW BUFFER

ex3) WINDOW BUFFER + WINDOW SORT => WINDOW SORT

ORDER BY가 다를 때, Operation이 통합될 수 있는 조건이 있다. 그 세부내용은 본문을 참조하라.

4. Ranking Family를 이용한 TOP SQL에서 Sort 최소화의 원리

Ranking Family 분석함수를 인라인뷰 외부에서 Rownum 처럼 Filter로 사용했을 때, 불필요한 Partition By절을 삭제하라. 그렇게 하면 두 가지 경우에 성능이 향상된다. 주의사항은 Partition By절 전체를 제거해야 한다는 것이다. 만약 Partition By절에 컬럼이 하나라도 있으면 Sort가 대량으로 발생된다. 각각의 파티션 값마다 sort를 해야 하므로 어쩔 수 없는 일이다.

첫 번째, 적절한 인덱스가 없어서 FULL SCAN을 하거나 혹은 OVER절의 NULL FIRST나 LAST등의 원인으로 sort가 발생될 때 이다. 이럴 경우 Partition By을 제거하면 필요한 개수 + 1 만큼만 sort가 발생하므로 성능이 향상된다. 하지만 Rownum과는 달리 STOPKEY가 발생되지 않으므로 비효율은 존재한다. 이 때 발생되는 Operation은 WINDOW SORT PUSHED RANK 이다.

두 번째, 적절한 인덱스가 있어서 sort가 발생되지 않는 경우이다. 이 경우는 첫 번째의 경우와는 달리 sort가 전혀 발생하지 않으며, Rownum 처럼 STOPKEY를 발생시켜 부분범위 처리의 효과를 얻는다. 다시 말해, 분석함수를 Rownum 처럼 사용할 수 있다. 이 때 발생되는 Operation은 WINDOW NOSORT STOPKEY 이다. 이 기능은 10g R2에서 추가 되었다.

WINDOW NOSORT STOPKEY는 주의사항이 있다. 그룹분석함수의 OVER절과 Ranking Family의 OVER절의 컬럼순서가 다르면 Operation이 하나로 통합되지 못한다. 이 경우는 성능이 저하된다. 왜냐하면 WINDOW SORT 혹은 WINDOW BUFFER 가 먼저 실행되고 그 후에 WINDOW NOSORT STOPKEY가 발생하기 때문에 Block I/O나 sort량을 감소시키지 못한다. 이런 비효율 때문에 분석함수 여러 개를 하나의 Operation으로 통합하는 원리(원리 3번)의 역할이 중요한 것이다. 이와 관련된 예제는 비효율3이 해결된 SQL과 실행계획을 참조하기 바란다.

5. 그룹분석함수의 NO-SORT 원리

이 원리는 장점이 두 가지 이다. Sort를 방지하고, STOPKEY를 작동시킨다.

적절한 인덱스가 존재하고, sum/min/max/avg등의 Group 분석함수를 사용할 경우 명시적으로 WINDOW의 범위를 지정하라. 그렇게 하면 WINDOW BUFFER Operation을 WINDOW NOSORT로 바꾸어 불필요한 sort를 방지한다. 물론 여기서 이야기 하는 그룹분석함수는 현재 row 까지의 누적집계(Cumulative total) 이다.

더욱 좋은 것은, Ranking family를 Rownum 처럼 사용하고 있다면, STOPKEY를 사용할 수 있게 한다. 즉 Group 분석함수를 사용하면, WINDOW BUFFER가 발생하고, sort가 발생되는데, 이 때문에 STOPKEY를 작동 시킬 수 없다. 그런데 WINDOW의 범위를 지정하여 WINDOW NOSORT로 바꾸면 sort가 발생하지 않기 때문에 STOPKEY가 작동한다. WINDOW의 범위를 지정하는 방법은 아래와 같다. 범위를 생략해도 결과는 같지만, 성능이 저하된다.

ex) SUM(AMOUNT_SOLD) OVER(ORDER BY CUST_ID,CHANNEL_ID,TIME_ID ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)

참고: Ranking family를 사용하여 WINDOW STOPKEY가 발생하는 경우는 SORT가 발생하지 않는 경우(NOSORT)뿐이다. 그룹분석함수에 의해서 추가적인 SORT를 해야 한다면, 전체범위로 처리됨으로 STOPKEY가 발생하지 않는다.

위의 다섯 가지 원리가 적용되지 않은 것이 각각의 비효율이다. 즉 위의 다섯 가지 원리를 비효율의 해결방법으로 작성한 사람은 100점이다.

자동튜닝기능이 아쉬워

이 글의 결론을 보고 많은 이들이 두 가지를 아쉬워할 것이다. 예컨대, 분석함수 SUM에 WINDOW의 범위를 생략했더라도 자동으로 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW를 추가해 준다면 얼마나 좋을까? 불필요한 Partition By절을 수동으로 삭제해야 하는 것 또한 마찬가지이다. 아직까지 옵티마이저는 사람을 따라올 수 없다. 사람의 손길을 여전히 필요로 한다. 따라서 전문 개발자라면 Partition By나 Order By 혹은 Window의 범위지정 등의 코딩을 할 때 내부적으로 어떤 일이 발생하는지 알아야 한다. 그냥 코딩을 하는 사람과 그것이 성능상 어떤 의미를 지니는지 알고 개발하는 사람과는 차이가 크다.

이상으로 분석함수의 내부에 대해 3회에 걸쳐 알아보았다. 1부/2부의 내용과 위의 결론 다섯 가지를 완벽히 이해한다면, 분석함수를 사용한 SQL과 실행계획, 그리고 인덱스 구조만 보고도 순간적으로 비효율을 잡아낼 수 있다. 분석함수의 비효율을 만나면 번개가 치듯이 생각이 번쩍 들것이다. 실행계획을 보고 비효율의 냄새를 맡을 줄 아는 능력은 중요하다.

마지막으로, 분석함수의 실행계획에 관한 글을 의뢰한 개발자에게 감사를 표한다. 아무래도 내가 그 개발자에게 맥주를 사는 것이 더 좋을 것 같다. 왜냐하면 그 사람 덕분에 좋은 것(Window의 범위 지정의 효과)을 발견할 수 있었기 때문이다. 두서 없는 긴 글을 읽어주신 독자 여러분들께 감사 드린다.

------------------------------------------------------------------------------------------------------------------------------------------------

이번 글은 여기까지 이다. 아래의 글은 이전에 올렸던 글의 정답보다 더 좋은 것이 발견되었음을 알리는 것이다.

분석함수의 실행계획을 정리하면서 Group(SUM/MIN/MAX/AVG) 분석함수에 WINDOW의 범위를 명시적으로 작성하는 것이 얼마나 중요한지 필자도 깨닫게 되었다. 예컨대, Pagination과 분석함수의 위험한 조합 글에서 도출된 정답보다 더 좋은 것은 WINDOW의 범위를 명시하는 것이다. 따라서 분석함수를 밖으로 빼는 것보다, 아래와 같이 window의 범위를 지정해 주는 것이 더 유리하다.

SELECT *

FROM (SELECT s.*, ROWNUM rnum

FROM (SELECT /*+ INDEX(S PK_SALES_T) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold,

sum (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS sum_amt

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) s

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.01 | 24 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.01 | 24 | |

|* 2 | COUNT STOPKEY | | 1 | 20 |00:00:00.01 | 24 | |

| 3 | VIEW | | 1 | 20 |00:00:00.01 | 24 | |

| 4 | WINDOW NOSORT | | 1 | 20 |00:00:00.01 | 24 | |

| 5 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 20 |00:00:00.01 | 24 | |

|* 6 | INDEX RANGE SCAN | PK_SALES_T | 1 | 20 |00:00:00.01 | 4 | |

----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

2 - filter(ROWNUM<=:V_MAX_ROW)

6 - access("S"."PROD_ID"=:V_PROD_ID)

20건에 대해서 조차 SORT가 전혀 발생하지 않는다. 따라서 Pagination과 분석함수의 위험한 조합 이라는 글은 수정되어야만 한다. 내가 작성한 글을 내가 뒤집었다. 내 것이라도 비판적으로 바라보아야 한다. 최종이론이란 없는 것이므로

------------------------------------------------------------------------------------------------------------------------------------------------

PS: 몇분이 구두로 혹은 메일로 괴상한 질문을 해서 답글을 남긴다.

Question: 어떻게 이런 책과 글을 쓰며, 주제는 어떻게 잡으며, 연구는 어떻게 하는가?

--> 이상한 질문이다. 내가 용빼는 재주라도 있나?

Answer:

필자의 머리가 좋아서 글을 쓸 수 있는 게 아니다. 오히려 그 반대이다. 똑똑한 다른 사람이라면, 내가 연구랍시고 소비한 시간의 절반만 투자해도 이 글을 썼을 것이다. 나는 다른 사람과 달리 영민하지 못하여 하찮은 문제에도 많은 시간을 소모하며, 실패하면 다시 조금씩 앞으로 전진 할 수 밖에 없다. 그렇다고 다른 재주가 있느냐 하면 그렇지 않다. 방향감각이 둔하여 연구가 막다른 길로 빠진 적이 여러 번일 뿐만 아니라 남들이 가지고 있는 창의성, 순발력, 영어실력, 문장력, 준수한 외모를 나는 가지지 못했고, 심지어 노래방에서는 박자를 못 맞추는 절대음감까지 그 어느 것도 잘하는 게 없다. 아무리 생각해도 세상은 불공평 한 듯 하다.

내가 할 수 있는 일은 나의 유일한 단점이자 장점을 살리는 수뿐이다. 실수를 하더라도, 거북이 근성으로 시간이 나는 대로 조금씩 연구를 하여 이런 글을 쓰는 수 밖에 없다. 글의 주제와 관련된 것도 특별한 것은 없다. 소주한잔 마시면서 어떤 글을 쓸지 동료들과 소통하거나, 독자들이 필요한 글을 나에게 요청한다. 내가 직접 글감을 고른 적은 5번중의 한번 정도이다. 글의 주제가 정해지면 무작정 글을 쓴다. 글을 쓰다가 모르는 것이 있으면(모르는 게 많다) 그에 맞춰 test(연구)를 한다. 궁금증이 해결되면 다시 글을 쓴다. 이것이 끝이다.

이 글도 위에서 설명한 절차와 똑같이 진행되었다. 단언하건대, 분석함수의 성능에 대해 이 문서만큼 깊이 다룬 책이나 매뉴얼은 지금까지 없다. 이런 일이 가능한 이유는 내가 아둔하고, 모르는 게 많은 거북이라서 그런 것이 아닐까?

저작자표시 비영리 동일조건

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 실행계획 - 심화과정 (12)	2011.02.14
분석함수의 실행계획 - 2부 (12)	2011.02.10
분석함수의 실행계획 - 1부 (12)	2011.02.07
Index_desc 힌트와 rownum = 1 조합은 안전한가? (12)	2010.11.09
Bloom Filter와 Group By의 관계 (10)	2010.09.09

Posted by extremedb

,

분석함수의 실행계획 - 심화과정

Oracle/Data Access Pattern 2011. 2. 14. 17:18

필자가 제안한 SQL 튜닝방법론을 읽어 보았다면 다음을 기억할 것이다.

“SQL 튜닝방법론은 온라인 SQL 중 90% 만 해결할 수 있으며, 나머지 10%는 그때 그때 마다 다르게(On the fly 모드) 처리된다. 또한 그것들은 책이나 매뉴얼에 나와있지 않기 때문에 경험치 이거나 실험과 연구의 결과로 알아내는 것들이다.”

이번 글은 방법론에서 다룰 수 없는, 나머지 10%에 해당하는 경험치와 연구의 결과이다.

분석함수의 나머지 10%

오늘은 SQL 튜닝방법론에서 언급한 나머지 10%를 만났을 때 어떻게 해야 하는지 알아보자. 이번 글이 분석함수의 실행계획 시리즈의 마지막이다. 1부와 2부에서 분석함수의 실행계획에 대해서 알아보았다. 하지만 두 개의 글로도 분석함수와 관련된 성능이슈를 모두 알 수는 없다. 왜냐하면 분석함수와 관련된 세밀한 튜닝포인트가 더 있기 때문이다. 이번에 다루게 될 실전 튜닝은 단순히 적절한 인덱스를 생성하여 비효율을 없애는 것이 아니다. 적절한 인덱스를 생성하는 것은 1부와 2부만 이해해도 충분하며, 이 글에서는 1부와 2부에서 언급하지 않은 것들을 설명하게 된다. 따라서 이 글에서 제시된 문제를 해결하지 못하면 분석함수를 튜닝 할 수 없는 경우를 많이 만날 것이다.

퀴즈는 SQL 두 개이며, 5가지 비효율을 개선해야 한다

이번에는 실전에서 발생할 수 있는 비효율에 대해서 두 가지 관점으로 논의한다. 분석함수를 사용할 때, 실행계획을 보고 비효율을 잡아내는 능력을 향상시키고, 실제로 SQL튜닝을 해보는 것이다. 반드시 문제를 직접 풀어보기 바란다. 당신이 튜너의 입장이 되어, 성능이 좋지 않은 SQL을 두 개 받았다고 가정하고 튜닝문제를 풀어보기 바란다. 두 가지 SQL 중 하나는 쉽고 나머지 하나는 어렵다. 두 개의 SQL에는 5가지의 튜닝 포인트가 있다. 각각의 포인트는 20점이며 5가지를 모두 맞추는 경우는 100점이 된다. 채점 시 중요한 점은 SQL을 맞추는 것이 아니라 비효율을 몇 개 잡아내었는지, 또한 각각의 비효율을 개선시킬 수 있는 방법은 몇 개나 생각했는지를 채점하는 것이다.

이제 실습을 위한 테이블과 인덱스를 생성하자.

CREATE TABLE SALES_T NOLOGGING AS SELECT * FROM SALES;

ALTER TABLE SALES_T ADD CONSTRAINT PK_SALES_T

PRIMARY KEY (PROD_ID, CUST_ID, CHANNEL_ID, TIME_ID) USING INDEX;

개발자가 작성한 문제의 SQL 1

SELECT *

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

MAX(TIME_ID) OVER( PARTITION BY CUST_ID ,CHANNEL_ID ) AS MAX_TIME

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE TIME_ID = MAX_TIME;

업무설명 : 상품번호 30인 데이터에 대하여 고객별, 채널 별로 가장 최근의 판매량을 나타내시오.

단 고객별, 채널별로 가장 최근의 데이터는 2건 이상일 수 있음.

-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 12649 |00:00:00.31 | 28337 | |

|* 1 | VIEW | | 12649 |00:00:00.31 | 28337 | |

| 2 | WINDOW BUFFER | | 29282 |00:00:00.27 | 28337 | 1495K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.17 | 28337 | |

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 29282 |00:00:00.03 | 118 | |

-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("TIME_ID"="MAX_TIME")

4 - access("PROD_ID"=30)

WHERE 절에 TIME_ID = MAX_TIME 이 존재하는 이유는 고객별, 채널별로 MAX(TIME_ID)에 해당하는 데이터가 두건 이상일 수 있기 때문이다. 이런 경우는 자주 발생한다. 이해를 돕기 위해 비슷한 예를 들어보자. 부서별로 최대급여를 받는 사람들을 출력하고자 할 때, 1번 부서의 최대급여는 1억 원이라고 하자. 그런데 그 부서에서 1억 원(최대급여)을 받는 사람은 강호동, 유재석 둘이라는 이야기 이다.

위의 SQL은 답이 정확하다. 하지만 성능은 비효율이 있어서 별로 신통치 못하다. 이제 문제를 보자. 위 SQL의 비효율을 개선하는 것이 문제이다.

문제1) 위의 SQL 에서 성능상 문제점을 발견하고 개선하시오. 문제점은 두 가지(분석함수의 관점, 일반적인 SQL튜닝의 관점) 이다. 단 인덱스를 추가로 생성하거나 변경해서는 안 된다.

아래처럼 정답을 제시하면 된다.

문제1의 비효율 1 : 구체적인 설명

문제1의 비효율 1의 해결방법 : 구체적인 설명

문제1의 비효율 1이 해결된 SQL과 실행계획 제시

문제1의 비효율 2 : 구체적인 설명

문제1의 비효율 2의 해결방법 : 구체적인 설명

문제1의 비효율 2이 해결된 SQL과 실행계획 제시

이제 실제로 답안을 작성해보자.(답안 Sample)

문제1의 비효율 1 : SALES_T 테이블에 Random Access가 불필요하게 많이 발생한다. 12649 번만 테이블로 액세스 하면 되지만 실제로는 29282 번 액세스함으로써 비효율이 발생되었다.

문제1의 비효율 1의 해결방법 : PK인덱스에 AMOUNT_SOLD가 포함되어 있지 않으므로 Select 절에서 AMOUNT_SOLD를 빼면 인덱스만 액세스 하게 됨. 이때 Rowid를 추가로 Select 해야 한다. 이후에 이미 인덱스에서 Filter된 Rowid로 테이블을 액세스하면 Random Access는 정확히 12649번 만 시도한다. 아래에 SQL이 있으므로 참조하시오.

문제1의 비효율1이 해결된 SQL과 실행계획 제시:

SELECT /*+ LEADING(S) USE_NL(S1) */

S.PROD_ID, S.CUST_ID, S.TIME_ID, S.CHANNEL_ID, S1.AMOUNT_SOLD

FROM ( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID,

MAX(TIME_ID) OVER( PARTITION BY CUST_ID ,CHANNEL_ID ) AS MAX_TIME,

ROWID AS RID

FROM SALES_T T

WHERE PROD_ID = 30 ) S,

SALES_T S1

WHERE S.TIME_ID = S.MAX_TIME

AND S1.ROWID = S.RID;

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 12649 |00:00:02.72 | 11237 | |

| 1 | NESTED LOOPS | | 1 | 12649 |00:00:02.72 | 11237 | |

|* 2 | VIEW | | 1 | 12649 |00:00:00.18 | 118 | |

| 3 | WINDOW BUFFER | | 1 | 29282 |00:00:00.13 | 118 | 1432K (0)|

|* 4 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

| 5 | TABLE ACCESS BY USER ROWID| SALES_T | 12649 | 12649 |00:00:02.48 | 11119 | |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("S"."TIME_ID"="S"."MAX_TIME")

4 - access("PROD_ID"=30)

이렇게 해서 Sample 답안을 작성해 보았다. 이 방법은 분석함수의 튜닝방법이 아니라 예외적으로 SQL 튜닝방법론에서 언급되었던 방법을 사용하였다. 물론 여기서 페이징처리를 한다면 추가적인 성능향상이 가능하지만 Sample이므로 여기서 멈추기로 한다. 위의 답안은 Sample 이므로 점수에서 빠진다. 또한 이 부분은 분석함수의 튜닝 방법이 아니다. 하지만 앞으로 풀게 될 문제들은 모두 분석함수와 관련된 문제들이다.

이제 시작해보자.

문제1에서 분석함수와 관련된 비효율이 하나 있다. 이와 관련된 비효율, 해결방법, 그리고 해결된 SQL과 실행계획을 제시해야 한다.

문제1의 비효율 2 : 구체적인 설명

문제1의 비효율 2 해결방법 : 구체적인 설명

문제1의 비효율 2가 해결된 SQL과 실행계획 제시

이제 좀더 어려운 문제를 풀어보자. 아래의 문제를 100% 맞춘 사람은 아무도 없었다.

문제2) 아래의 SQL 에서 성능상 문제점을 발견하고 개선하시오. 성능상 문제점은 4가지 이다. 4가지의 비효율을 발견하고 이를 모두 개선해야 한다. 단 인덱스를 추가로 생성하거나 변경하면 안 된다.

SELECT *

FROM

( SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER ( PARTITION BY PROD_ID ORDER BY CUST_ID,CHANNEL_ID,TIME_ID NULLS FIRST) AS RN,

SUM(AMOUNT_SOLD) OVER ( ORDER BY CUST_ID,CHANNEL_ID,TIME_ID,PROMO_ID ) AS SUM_AMT

FROM SALES_T T

WHERE PROD_ID = 30 )

WHERE RN <= 10 ;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 10 |00:00:00.43 | 28337 | |

|* 1 | VIEW | | 1 | 10 |00:00:00.43 | 28337 | |

|* 2 | WINDOW SORT PUSHED RANK | | 1 | 29282 |00:00:00.40 | 28337 | 1999K (0)|

| 3 | WINDOW SORT | | 1 | 29282 |00:00:00.30 | 28337 | 1684K (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.18 | 28337 | |

|* 5 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.04 | 118 | |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( PARTITION BY "PROD_ID" ORDER BY "CUST_ID","CHANNEL_ID",INTERNAL_FUNCTION("TIME_ID")

NULLS FIRST)<=10)

5 - access("PROD_ID"=30)

아래처럼 정답을 제시하면 된다.

문제2의 비효율 1 : 구체적인 설명

문제2의 비효율 1의 해결방법 : 구체적인 설명

문제2의 비효율 1이 해결된 SQL과 실행계획 제시

문제2의 비효율 2 : 구체적인 설명

문제2의 비효율 2의 해결방법 : 구체적인 설명

문제2의 비효율 2가 해결된 SQL과 실행계획 제시

문제2의 비효율 3 : 구체적인 설명

문제2의 비효율 3의 해결방법 : 구체적인 설명

문제2의 비효율 3이 해결된 SQL과 실행계획 제시

문제2의 비효율 4 : 구체적인 설명

문제2의 비효율 4의 해결방법 : 구체적인 설명

문제2의 비효율 4가 해결된 SQL과 실행계획 제시

문제의 구성
이렇게 하여 총 다섯 문제가 출제되었다. 문제 1에는 비효율이 하나이고 문제 2에는 비효율이 넷이다. 다섯 가지 비효율 모두 분석함수와 관련된 것들이다. 실습환경은 Oracle 10g R2, Oracle 11g R1, Oracle 11g R2로 한정한다. 답안은 2011년 2월 18일 공개될 예정이다. 답안을 바로 공개하지 않는 이유는 튜닝실습을 유도하기 위함이다. SQL 두개를 분석하는데 이틀이면 넉넉한 시간이므로 충분히 생각하고 답을 작성하기 바란다. 자신이 튜너가 되었다고 가정하고 비효율을 모두 찾아보길 바란다.

다른 사람들은 몇 점 정도 받았나?

몇몇 지인들에게 퀴즈를 내본 결과 100점은 아무도 없었다. 즉 80점이 평균적인 튜너의 수준이라는 이야기 이다. 개발자의 경우는 60점을 받더라도 실망해서는 안 된다. 개발자가 60점이면 괜찮은 수준이다. 점수에 대해 오해는 하지 말기 바란다. 이 퀴즈로 받은 점수는 분석함수와 관련된 것일 뿐, 전반적인 SQL 튜닝능력에 대한 점수가 아니다. 또한 100 점 이상을 받을 수도 있다. 필자가 알고 있는 튜닝포인트는 5가지뿐이다. 여러분들이 6~7가지 이상의 비효율과 튜닝 포인트를 잡아내어 필자를 능가하는 점수를 받는 것도 가능하다.

행운을 빈다.

저작자표시 비영리 동일조건

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 성능개선 그 결과는? (14)	2011.02.18
분석함수의 실행계획 - 2부 (12)	2011.02.10
분석함수의 실행계획 - 1부 (12)	2011.02.07
Index_desc 힌트와 rownum = 1 조합은 안전한가? (12)	2010.11.09
Bloom Filter와 Group By의 관계 (10)	2010.09.09

Posted by extremedb

,

분석함수의 실행계획 - 2부

Oracle/Data Access Pattern 2011. 2. 10. 11:23

빠른 이해를 위해서 이전 글을 먼저 보고 이 글을 읽기 바란다. 이 글의 1부에서 WINDOW SORT, WINDOW SORT PUSHED RANK, WINDOW NOSORT, WINDOW NOSORT STOPKEY OPERATION들을 정리해 보았다. 이번에는 나머지 네 가지 Operation에 관해 알아볼 것이다. 이번 시간을 마치면 분석함수의 실행계획은 모두 정리된다.

WINDOW (SORT)

WINDOW (SORT PUSHED RANK)

WINDOW (NOSORT)

WINDOW (NOSORT STOPKEY) <-- 저번 시간에는 여기까지

WINDOW (BUFFER)

WINDOW (BUFFER PUSHED RANK)

WINDOW (CHILD PUSHED RANK)

WINDOW (IN SQL MODEL) SORT <-- 이번 시간에는 여기까지

5. WINDOW BUFFER

WINDOW BUFFER는 기본적으로 Ranking Family를 사용하지 않는 경우에 발생한다. 또한 인덱스가 적절하거나, 혹은 OVER절에 ORDER BY구문이 없는 경우에 발생한다. where절의 filter 조건이 있다면, 전체 건을 Sort 하지 않지만 최종 결과 건(Window의 범위)에 대해서는 sort가 필요하다.

SELECT PROD_ID,

SUM(AMOUNT_SOLD) OVER() AS SUM_AVG

FROM SALES_T

WHERE PROMO_ID = 33;

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2074 |00:00:00.04 | 4440 | |

| 1 | WINDOW BUFFER | | 2074 |00:00:00.04 | 4440 |59392 (0)|

|* 2 | TABLE ACCESS FULL| SALES_T | 2074 |00:00:00.03 | 4440 | |

---------------------------------------------------------------------------------

위의 결과를 보면 2074건에 대하여 Sort가 발생하였다. 하지만 아래는 다르다.

SELECT PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

SUM(AMOUNT_SOLD) OVER(ORDER BY NULL) AS RN

FROM SALES_T ;

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 918K|00:00:03.69 | 4440 | |

| 1 | WINDOW BUFFER | | 918K|00:00:03.69 | 4440 | 35M (0)|

| 2 | TABLE ACCESS FULL| SALES_T | 918K|00:00:00.96 | 4440 | |

---------------------------------------------------------------------------------

WHERE 절이 없으므로 WINDOW의 범위는 전체이다. 전체 건(약 92만건)을 SORT해야 하므로 PGA를 35M나 사용하였다. OVER절에 ORDER BY가 없지만, 전체 건을 SORT 했으므로 WINDOW BUFFER는 WINDOW SORT Operation이 발생한 것과 마찬가지 이다.

이제 인덱스를 사용하면서 OVER절에 ORDER BY가 있는 경우를 살펴보자.

SELECT /*+ INDEX(S PK_SALES_T) */

SUM(AMOUNT_SOLD) OVER(ORDER BY S.CUST_ID, S.CHANNEL_ID, S.TIME_ID ) AS "누적금액",

S.*

FROM SALES_T S

WHERE S.PROD_ID = 22

ORDER BY S.CUST_ID, S.CHANNEL_ID, S.TIME_ID ;

----------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 3441 |00:00:00.06 | 2911 | |

| 1 | WINDOW BUFFER | | 3441 |00:00:00.06 | 2911 | 206K (0)|

| 2 | TABLE ACCESS BY INDEX ROWID| SALES_T | 3441 |00:00:00.05 | 2911 | |

|* 3 | INDEX RANGE SCAN | PK_SALES_T | 3441 |00:00:00.04 | 17 | |

----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."PROD_ID"=22)

인덱스 (PROD_ID + CUST_ID + CHANNEL_ID + TIME_ID)컬럼과 OVER절의 ORDER BY구문의 컬럼순서가 동일하므로 WINDOW SORT 가 발생하지 않고 WINDOW BUFFER 가 발생하였다. SQL의 마지막에 위치한 ORDER BY 구문은 인덱스 컬럼과 일치하므로 별도의 SORT가 필요하지 않다.

6. WINDOW BUFFER PUSHED RANK

OPERATION에 RANK가 있으므로 Ranking Family를 사용한 것이다. 이 OPERATION을 볼 수 있으면 좋겠지만 10g에서 사라졌다. Oracle 9i 까지는 적절한 인덱스가 있는 경우에 Ranking Family를 사용하고, 뷰/인라인 뷰 외부에서 분석함수를 Filter로 사용한다면 WINDOW BUFFER PUSHED RANK가 발생하였다. 하지만 10g부터는 더 효율적인 WINDOW NOSORT(10g R1) 혹은 WINDOW NOSORT STOPKEY(10g R2)로 대체되었다. 참고로 야함나르 독자님에 의하면 버전 9.2.0.7에서도 WINDOW NOSORT가 발생한다고 한다. (관련링크)

9i에서 직접 테스트 해보면 좋겠지만 환경이 그렇지 못하므로 Julian Dyke의 테스트 내용을 인용한다.

This example was developed using Oracle 9.2.0.1 on Windows 2000

This example requires the following table definition

CREATE TABLE t1 (c1 NUMBER NOT NULL,c2 NUMBER);

CREATE INDEX i1 ON t1 (c1);

The table must be analysed

ANALYZE TABLE t1 COMPUTE STATISTICS;

The statement

SELECT c2,r1

FROM ( SELECT c2,RANK () OVER (ORDER BY c1) AS r1

FROM t1 )

WHERE r1 < 10;

9i의 실행계획

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 VIEW

2 1 WINDOW (BUFFER PUSHED RANK)

3 2 TABLE ACCESS (BY INDEX ROWID) OF 'T1'

4 3 INDEX (FULL SCAN) OF 'I1' (NON-UNIQUE)

테스트의 출처 http://www.juliandyke.com/Optimisation/Operations/WindowBufferPushedRank.html

10g R2의 실행계획

---------------------------------------------------------------------------

---------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 26 | 1 (0)|

|* 1 | VIEW | | 1 | 26 | 1 (0)|

|* 2 | WINDOW NOSORT STOPKEY | | 1 | 26 | 1 (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 26 | 1 (0)|

| 4 | INDEX FULL SCAN | I1 | 1 | | 1 (0)|

---------------------------------------------------------------------------

10g R2에서는 WINDOW BUFFER PUSHED RANK 대신에 WINDOW NOSORT STOPKEY 가 발생하므로 SORT가 전혀 발생하지 않으며 STOPKEY가 발생하여 필요한 부분만 SCAN된다. 따라서 TOP SQL이나 페이징 처리시 상당한 성능개선 효과를 볼 수 있다.

7. WINDOW CHILD PUSHED RANK

Ranking Family를 사용하고 인라인 뷰 외부에서 분석함수를 Filter로 사용한다면 실행계획에 ~PUSHED RANK 혹은 ~STOPKEY가 발생한다고 하였다. WINDOW CHILD PUSHED RANK도 마찬가지이다. 단 하나의 차이점은 Parallel Query를 사용했다는 것이다.

SELECT *

FROM (SELECT /*+ FULL(T) PARALLEL(T 4) */ PROMO_ID,

RANK() OVER(ORDER BY PROD_ID) AS RN

FROM SALES_T T)

WHERE RN = 1

--------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 6002 |00:00:01.84 | 5 | |

|* 1 | VIEW | | 6002 |00:00:01.84 | 5 | |

|* 2 | WINDOW SORT PUSHED RANK | | 6003 |00:00:01.83 | 5 | 142K (0)|

| 3 | PX COORDINATOR | | 6006 |00:00:01.81 | 5 | |

| 4 | PX SEND QC (RANDOM) | :TQ10000 | 0 |00:00:00.01 | 0 | |

|* 5 | WINDOW CHILD PUSHED RANK| | 0 |00:00:00.01 | 0 |96256 (0)|

| 6 | PX BLOCK ITERATOR | | 0 |00:00:00.01 | 0 | |

|* 7 | TABLE ACCESS FULL | SALES_T | 0 |00:00:00.01 | 0 | |

--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"=1)

2 - filter(RANK() OVER ( ORDER BY "PROD_ID")<=1)

5 - filter(RANK() OVER ( ORDER BY "PROD_ID")<=1)

7 - access(:Z>=:Z AND :Z<=:Z)

ID 5번에 WINDOW CHILD PUSHED RANK가 발생했음에도 ID 2번에 WINDOW SORT PUSHED RANK가 발생한 이유는 QUERY COORDINATOR가 개별 PARALLEL SLAVE들을 취합해야 하기 때문이다.

8. WINDOW IN SQL MODEL SORT

MODEL절에서 분석함수를 사용하는 경우에 발생한다.

SELECT PROD_ID,a1,a2

FROM (SELECT PROD_ID,SUM(AMOUNT_SOLD) a1

FROM SALES_T

GROUP BY PROD_ID )

MODEL DIMENSION BY (PROD_ID)

MEASURES (a1,0 a2)

RULES ( a2[any] = SUM (a1) OVER () ) ; --> 분석함수 사용

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 72 |00:00:01.91 | 4440 | |

| 1 | SQL MODEL ORDERED | | 72 |00:00:01.91 | 4440 | 405K (0)|

| 2 | HASH GROUP BY | | 72 |00:00:01.91 | 4440 | 2516K (0)|

| 3 | TABLE ACCESS FULL | SALES_T | 918K|00:00:00.93 | 4440 | |

| 4 | WINDOW (IN SQL MODEL) SORT| | 72 |00:00:00.01 | 0 | 2048 (0)|

------------------------------------------------------------------------------------------

위와 아래의 SQL은 같은 결과를 출력한다. 그리고 PGA 사용량도 비슷하다.

SELECT PROD_ID,SUM(AMOUNT_SOLD) a1, sum(SUM(AMOUNT_SOLD)) OVER() as a2

FROM SALES_T

GROUP BY PROD_ID ;

----------------------------------------------------------------------------------

----------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 72 |00:00:01.91 | 4440 | |

| 1 | WINDOW BUFFER | | 72 |00:00:01.91 | 4440 | 2048 (0)|

| 2 | HASH GROUP BY | | 72 |00:00:01.91 | 4440 | 2515K (0)|

| 3 | TABLE ACCESS FULL| SALES_T | 918K|00:00:00.93 | 4440 | |

----------------------------------------------------------------------------------

단순히 전체 합계를 출력하는 것이라면 MODEL절 보다는 분석함수를 사용하는 것이 조금 유리하다. SQL MODEL ORDERED OPERATION이 없기 때문이다. 참고로 MODEL절이 무엇인지 궁금한 사람은 SQL 포기하지마라 , Model 절에 대하여 라는 두 가지 글을 보기 바란다.

결론

WINDOW (SORT) :

-FTS를 사용하거나 인덱스가 적절하지 않은 경우 발생

WINDOW (SORT PUSHED RANK) :

-위와 같으나 Ranking Family를 사용해야 하며, 뷰/인라인뷰 외부에서 분석함수를 filter로 사용하는 경우 발생

WINDOW (NOSORT) :

-인덱스가 적절한 경우나, OVER절에 ORDER BY가 없는 Ranking Family를 사용한 경우 발생

WINDOW (NOSORT STOPKEY) :

-위와 같으나 Ranking Family를 사용해야 하며, 뷰/인라인뷰 외부에서 분석함수를 filter로 사용하는 경우 발생

-10g R2 신기능

WINDOW (BUFFER) :

- Ranking Family를 사용하지 않고 ORDER BY가 없는 경우이거나 적절한 인덱스를 사용하는 경우 발생

WINDOW (BUFFER PUSHED RANK) :

- Ranking Family를 사용하고, 뷰/인라인뷰 외부에서 분석함수를 filter로 사용해야 하며, 8i~9i 에서만 발생됨.

- 비효율을 개선하여 10g R1에서는 WINDOW (NOSORT)가 발생하며, 10g R2에서는 WINDOW (NOSORT STOPKEY)가 발생됨

WINDOW (CHILD PUSHED RANK) :

- Ranking Family를 사용하고, 뷰/인라인뷰 외부에서 분석함수를 filter로 사용해야 하며, Parallel Query를 사용하는 경우 발생

WINDOW (IN SQL MODEL) SORT

- Model 절에서 분석함수로 Rule을 정하는 경우 발생

심화학습이 필요한 이유

저번 글과 이번 글에서 분석함수를 사용할 때 나올 수 있는 실행계획을 정리해 보았다. 이제 분석함수의 실행계획을 보면 어떤 환경에서 실행되었는지, 어떤 비효율이 있는지 감을 잡을 수 있을 것이다. 다음 글에서는 위의 결론을 이용하여 좀더 고차원적인 심화과정에 도전할 것이다. 다음 글의 목적은 실전에서 분석함수를 사용할 때, 비효율을 잡아내는 능력을 향상시키고, 실제로 성능개선을 해보는 것이다.

저작자표시 비영리 동일조건

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 성능개선 그 결과는? (14)	2011.02.18
분석함수의 실행계획 - 심화과정 (12)	2011.02.14
분석함수의 실행계획 - 1부 (12)	2011.02.07
Index_desc 힌트와 rownum = 1 조합은 안전한가? (12)	2010.11.09
Bloom Filter와 Group By의 관계 (10)	2010.09.09

Posted by extremedb

,

분석함수의 실행계획 - 1부

Oracle/Data Access Pattern 2011. 2. 7. 07:00

Oracle Data Access Pattern

Partition Access Pattern

Oracle 조인 방법 25가지

필자는 위의 글들을 이미 게시하였다. 그래서 Access Path와 Join Method는 정리가 되었고, 블로그로 배포되었으므로 그것으로 끝이라고 생각했다. 하지만 어느 개발자와 대화를 해보니 그런 생각이 짧았음을 알게 되었다.

개발자 : 위의 3가지 문서는 잘 보고 있습니다. 하지만 Access Path에 관해서는 큰 구멍이 있습니다.

필자 : 네? 무슨 말인가요?

개발자 : 분석함수는 Access Path를 변경시킵니다. 즉 분석함수를 어떻게 사용하느냐에 따라 실행계획의 Operation이 변경되므로 여타의 함수와는 엄연히 다릅니다. 그러므로 수석님께서 분석함수와 관련된 Access Path를 정리해 주셨으면 합니다.

필자 : 음…. 프로젝트도 있고, 블로그도 관리해야 하고, 책도 써야 하고, 개인적인 공부도 해야 하는데요. 시간이 나질 않습니다. (헉! 말을 하자마자 실수였다는 것을 알아차렸다. 블로그 관리라니……)

개발자 : 지금 하시고 계신 네 가지 이외의 일을 해달라는 게 아닙니다. 분석함수의 실행계획을 정리하셔서 블로그에 올리시면, 그게 블로그 관리 아닌가요?

필자 : …..

이번에는 공짜가 아니다

이렇게 해서 이 글을 쓰게 되었다. 해당개발자는 언제 나에게 맥주 한잔 사기 바란다. 이런 식으로 말려들어서 글을 작성한 적이 한두번이 아니다. ^^

분석함수의 내부

분석함수를 이용하여 답을 잘 내었으므로 그것으로 만족하는 사람들이 있다. 답을 내는 것은 표면적인 것(문법)을 이해한 것이다. 하지만 그것만 알아서는 내부적인 매커니즘을 이해할 수 없다. 즉 분석함수를 사용함에 따라 Access Path(Operation)가 어떻게 변경되는지도 알아야 모두를 아는 것이다. 분석함수의 내부적인 Operation을 모른다면 SQL 작성은 할지 몰라도, 성능을 향상시킬 수는 없다. 오늘의 목표는 분석함수의 내부를 정복함으로써 튜닝을 가능하게 하는 것이다.

분석함수의 실행계획은 아래와 같이 총 8가지로 예상된다. 만약, 아래의 List 이외의 것을 발견하면 이 글을 보는 독자들을 위해 알려주기 바란다. 글이 너무 길어지므로, 이번 시간에는 8개중에 위의 4개를 알아보고자 한다. 어떤 경우에 아래의 4가지 실행계획이 발생하는지 알아보자.

WINDOW (SORT)

WINDOW (SORT PUSHED RANK)

WINDOW (NOSORT)

WINDOW (NOSORT STOPKEY) <-- 이번 시간에는 여기까지

WINDOW (BUFFER)

WINDOW (BUFFER PUSHED RANK)

WINDOW (CHILD PUSHED RANK)

WINDOW (IN SQL MODEL) SORT

환경: Oracle 11.2.0.1

테스트를 위해 테이블과 인덱스를 만든다.

CREATE TABLE SALES_T NOLOGGING AS SELECT * FROM SALES;

CREATE INDEX IX_PROD ON SALES_T( PROD_ID );

1. WINDOW SORT

분석함수를 사용하면 기본적으로 SORT가 발생한다. 이때 SORT를 대체할 수 있는 적절한 인덱스가 없다면 WINDOW SORT가 발생한다. 아래의 경우가 대표적이다.

-인덱스와 분석함수 OVER절의 컬럼이 일치하지 않을 때 발생한다.

-분석함수를 사용하고 Full Table Scan을 사용할 때 발생한다.

먼저 인덱스와 OVER 절의 컬럼이 일치하지 않는 경우를 살펴보자.

SELECT PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER(ORDER BY CUST_ID) AS RN

FROM SALES_T

WHERE PROD_ID = 30;

-------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 29282 |00:00:00.18 | 424 | |

| 1 | WINDOW SORT | | 29282 |00:00:00.18 | 424 | 1558K (0)|

| 2 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.09 | 424 | |

|* 3 | INDEX RANGE SCAN | IX_PROD | 29282 |00:00:00.03 | 60 | |

-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("PROD_ID"=30)

인덱스는 PROD_ID 로 구성되었지만, OVER절은 CUST_ID로 되어 서로 다르므로 실행계획의 Id 2번에 WINDOW SORT가 발생하였다.

이제 분석함수를 사용하면서 FTS(Full Table Scan)이 발생하는 경우를 보자.

SELECT PROD_ID,

SUM(AMOUNT_SOLD) OVER() AS SUM_AVG

FROM SALES_T

WHERE PROMO_ID = 33

ORDER BY CUST_ID;

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2074 |00:00:00.04 | 4440 | |

| 1 | WINDOW SORT | | 2074 |00:00:00.04 | 4440 | 102K (0)|

|* 2 | TABLE ACCESS FULL| SALES_T | 2074 |00:00:00.04 | 4440 | |

---------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("PROMO_ID"=33)

WHERE 절이 PROD_ID가 아니라 PROMO_ID이므로 FTS가 발생하였다. 이때 분석함수를 사용하면 WINDOW SORT가 발생된다.

이때 ORDER BY절이 있더라도 별도의 SORT ORDER BY operation이 발생하지 않는다. 분석함수가 SORT를 대신하기 때문이다. 이때 SORT의 일량은 동일하다. 즉 분석함수와 ORDER BY절이 동시에 존재한다면, SORT의 일량은 분석함수가 없고 ORDER BY만 존재하는 SQL과 동일 하다. 아래의 SQL이 이 사실을 증명한다.

SELECT PROD_ID, AMOUNT_SOLD

FROM SALES_T

WHERE PROMO_ID = 33

ORDER BY CUST_ID;

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2074 |00:00:00.04 | 4440 | |

| 1 | SORT ORDER BY | | 2074 |00:00:00.04 | 4440 | 102K (0)|

|* 2 | TABLE ACCESS FULL| SALES_T | 2074 |00:00:00.04 | 4440 | |

---------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter("PROMO_ID"=33)

위에서 설명된 SQL의 분석함수 + ORDER BY의 SORT 일량과 ORDER BY만 사용한 SORT의 일량은 102K로 동일함을 알 수 있다. 즉 분석함수와 ORDER BY를 같이 사용하던지, 아니면 ORDER BY만 사용하던지 간에 SORT의 부하는 동일하다는 이야기 이다.

2.WINDOW SORT PUSHED RANK

위에서 적당한 인덱스가 없을 때, 분석함수를 사용하면 WINDOW SORT가 발생한다고 하였다. 이번에는 WINDOW SORT에 대해 좀더 깊이 들어가 보자.

SELECT *

FROM ( SELECT PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER(ORDER BY CUST_ID) AS RN

FROM SALES_T

WHERE PROD_ID = 30 )

WHERE RN <= 10;

--------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 10 |00:00:00.13 | 424 | |

|* 1 | VIEW | | 10 |00:00:00.13 | 424 | |

|* 2 | WINDOW SORT PUSHED RANK | | 11 |00:00:00.13 | 424 | 2048 (0)|

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.10 | 424 | |

|* 4 | INDEX RANGE SCAN | IX_PROD | 29282 |00:00:00.03 | 60 | |

--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "CUST_ID")<=10)

4 - access("PROD_ID"=30)

이 글에서 처음 소개된 SQL과 같지만, 인라인뷰 외부에서 분석함수 컬럼을 filter 조건으로 사용하였다. 즉 상위 10건만 보자고 한 것이다. 이런 경우 WINDOW SORT PUSHED RANK operation이 발생하며 SORT의 부하는 제한된다. 다시 말해 RN <= 10 조건에 의해 전체를 SORT할 필요가 없이 10건의 배열을 만들고, 그 배열만 SORT 하면 된다. 이 글에서 최초로 설명된 SQL의 SORT 일량과 WINDOW SORT PUSHED RANK의 일량을 비교해보면 1558K 과 2K 로 천지차이이다. 분석함수 중에 순위를 구하는 것(RANK, DENSE_RANK, ROW_NUMBER)을 인라인뷰 외수에서 filter로 사용하면 적절한 인덱스가 없더라도 Sort의 부하는 최소화 된다는 것을 기억하자.

이런 사실은 분석함수를 사용하지 않더라도 동일하게 발생한다. 즉 위에서 실행된 SQL의 SORT량과 아래의 SORT이 동일하다. 아래는 분석함수를 사용하지 않고 ROWNUM을 사용하였다.

SELECT *

FROM ( SELECT /*+ INDEX(T IX_PROD) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD

FROM SALES_T T

WHERE PROD_ID = 30

ORDER BY CUST_ID)

WHERE ROWNUM <= 10;

---------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 10 |00:00:00.13 | 424 | |

|* 1 | COUNT STOPKEY | | 10 |00:00:00.13 | 424 | |

| 2 | VIEW | | 10 |00:00:00.13 | 424 | |

|* 3 | SORT ORDER BY STOPKEY | | 10 |00:00:00.13 | 424 | 2048 (0)|

| 4 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.09 | 424 | |

|* 5 | INDEX RANGE SCAN | IX_PROD | 29282 |00:00:00.03 | 60 | |

---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM<=10)

3 - filter(ROWNUM<=10)

5 - access("PROD_ID"=30)

WINDOW SORT PUSHED RANK 대신에 SORT ORDER BY STOPKEY operation이 사용되었지만 하는 일과 원리는 동일하므로 SORT량도 동일하다.

3.WINDOW NOSORT

적절한 인덱스가 없을 때 분석함수를 사용하면 WINDOW SORT가 발생한다고 하였다. 이번에는 동일한 SQL을 실행하되 적절한 인덱스를 만들고 실행해보자.

CREATE INDEX PK_SALES_T ON SALES_T(PROD_ID, CUST_ID, CHANNEL_ID, TIME_ID);

SELECT /*+ INDEX(T PK_SALES_T) */ PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER(ORDER BY CUST_ID) AS RN

FROM SALES_T T

WHERE PROD_ID = 30;

----------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 29282 |00:00:00.34 | 28352 | |

| 1 | WINDOW NOSORT | | 29282 |00:00:00.34 | 28352 | |

| 2 | TABLE ACCESS BY INDEX ROWID| SALES_T | 29282 |00:00:00.24 | 28352 | |

|* 3 | INDEX RANGE SCAN | PK_SALES_T | 29282 |00:00:00.07 | 133 | |

----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("PROD_ID"=30)

WHERE절과 OVER절의 ORDER BY에 만족하는 인덱스를 생성하였더니 SORT가 전혀 발생하지 않는다. 또한 OPERATION도 WINDOW SORT에서 WINDOW NOSORT로 바뀌었다. 적절한 인덱스가 왜 필요한지 알 수 있는 대목이다. 참고로 OVER 절의 ORDER BY 구문은 PROD_ID , CUST_ID 로 바꾸어도 동일한 결과를 얻을 수 있다.

또 다른 경우를 보자. 분석함수를 사용하고, Full Table Scan을 사용하더라도 WINDOW NOSORT가 발생할 수 있다.

SELECT PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER(ORDER BY NULL) AS RN

FROM SALES_T ;

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 918K|00:00:04.81 | 4898 | |

| 1 | WINDOW NOSORT | | 918K|00:00:04.81 | 4898 | |

| 2 | TABLE ACCESS FULL| SALES_T | 918K|00:00:01.99 | 4898 | |

---------------------------------------------------------------------------------

FTS를 사용했지만 분석함수에 ORDER BY절이 없으므로 SORT는 발생하지 않는다. 무작위로 10건을 추출하는 경우에 사용할 수 있다. 물론 ROWNUM을 사용해도 동일한 효과를 낼 것이다.

4.WINDOW NOSORT STOPKEY

인덱스의 컬럼순서와 분석함수 OVER절에 존재하는 ORDER BY 컬럼순서가 동일하며, Ranking Family 함수를 인라인뷰 외부에서 filter 조건으로 사용할 때 발생한다.

SELECT *

FROM ( SELECT PROD_ID, CUST_ID, TIME_ID, CHANNEL_ID, AMOUNT_SOLD,

ROW_NUMBER() OVER(ORDER BY PROD_ID) AS RN

FROM SALES_T

WHERE PROD_ID = 30 )

WHERE RN <= 10;

--------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 10 |00:00:00.01 | 6 | |

|* 1 | VIEW | | 10 |00:00:00.01 | 6 | |

|* 2 | WINDOW NOSORT STOPKEY | | 10 |00:00:00.01 | 6 | |

| 3 | TABLE ACCESS BY INDEX ROWID| SALES_T | 11 |00:00:00.01 | 6 | |

|* 4 | INDEX RANGE SCAN | IX_PROD | 11 |00:00:00.01 | 4 | |

--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RN"<=10)

2 - filter(ROW_NUMBER() OVER ( ORDER BY "PROD_ID")<=10)

4 - access("PROD_ID"=30)

WINDOW NOSORT STOPKEY는 부분범위처리에 최적화되어 있다

분석함수를 Rownum처럼 사용하였기 때문에 WINDOW NOSORT STOPKEY가 발생하였다. 1건을 더 읽었지만 비효율은 느낄 수 없는 정도이다. WINDOW NOSORT STOPKEY와 이미 위에서 설명된 WINDOW SORT PUSHED RANK와의 차이는 단순히 SORT의 유무뿐만이 아니다. Block I/O량도 차이가 난다. 즉 WINDOW SORT PUSHED RANK는 전체 건을 읽은 후에 다 버리고 10건만 출력한다. 이에 반해 WINDOW NOSORT STOPKEY는 11건을 읽고 한 건만 버리므로 부분범위처리의 효율이 좋다. 2번과 4번의 Block I/O량을 비교해보기 바란다. 몇 십 배나 차이가 난다..

참고: Ranking Family 분석함수란 RANK, DENSE_RANK, ROW_NUMBER를 말한다.

결론

WINDOW (SORT) :

-FTS를 사용하거나 인덱스가 적절하지 않은 경우 발생

WINDOW (SORT PUSHED RANK) :

-위와 같으나 Ranking Family를 사용해야 하며, 인라인뷰 외부에서 분석함수를 filter로 사용하는 경우 발생

WINDOW (NOSORT) :

-인덱스가 적절한 경우나, OVER절에 ORDER BY가 없는 Ranking Family를 사용한 경우 발생

WINDOW (NOSORT STOPKEY) :

-위와 같으나 Ranking Family를 사용해야 하며, 인라인뷰 외부에서 분석함수를 filter로 사용하는 경우 발생

“실행계획만 보고도 SQL을 어느 정도 짐작 할 수 있다” 라고 주장하는 튜닝의 고수가 있다. 필자는 때에 따라 그럴 수도, 아닐 수도 있다고 생각한다. 하지만 최소한 분석함수에 관해서는 어느 정도 가능하다고 생각한다. 분석함수의 내부를 이해했다면 충분히 그럴 수 있다. 이제 위의 결론을 이용하여, 실행계획만 보고도 어떤 분석함수를 어떤 상황에서 사용한 것인지 짐작 할 수 있겠는가? 대충 짐작 할 수 있다면 성공한 것이다.

다음 글(2 부)에서 소개될 내용

WINDOW (BUFFER)

WINDOW (BUFFER PUSHED RANK)

WINDOW (CHILD PUSHED RANK)

WINDOW (IN SQL MODEL) SORT

저작자표시 비영리 동일조건

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 실행계획 - 심화과정 (12)	2011.02.14
분석함수의 실행계획 - 2부 (12)	2011.02.10
Index_desc 힌트와 rownum = 1 조합은 안전한가? (12)	2010.11.09
Bloom Filter와 Group By의 관계 (10)	2010.09.09
Inlist Iterator를 사용하지 말아야 할 때 (13)	2010.06.23

Posted by extremedb

,

SQL튜닝 방법론

Oracle/SQL Tuning 2011. 1. 27. 17:49

SQL 튜닝책을 세 권정도 읽은 신입사원이 SQL 튜닝방법론을 요청하였다. 이유는 튜닝책에 방법론이 없다는 것이다. 튜닝 방법론이란 “SQL을 튜닝 해달라고 요청 받았을 때 내가 무엇 무엇을 해야 하나?” 이다. 즉 SQL 튜닝시의 To-Do 리스트(체크리스트)를 요구한 것이다.

SQL 튜닝을 자주 하면서도, 그 안에 몇 가지 작업이 있는지 생각하지 못했다. 누가 그랬던가? 일상을 낯설게 느껴보라고… SQL 튜닝요청을 받았을 때 내가 어떤 일을 하는지 가르쳐 주면 되겠구나 하는 생각이 들었다. 그 결과 7가지 방법이 결론으로 도출되었다. 만약 7가지 방법을 모두 적용할 수 있는 경우임에도 불구하고 하나라도 빠진다면 최적화된 SQL을 만들 수 없다.

아래는 필자와 신입사원의 대화이다.

신입사원 : SQL 튜닝의 원칙 몇 가지를 저에게 일러 주실 수 있나요? 튜닝책도 몇 가지 보았고, 강의도 많이 들었지만 “이 원칙만 지키면 100점 만점에 90점은 맞는다.” 는 원칙 같은 것은 없더군요. 저는 이제 입문하는 단계이므로 모든 경우에 100점을 맞을 필요는 없습니다.

필자 : 온라인 SQL이냐 대용량 배치 SQL이냐에 따라 튜닝방법이 달라지므로 설명하기가 힘들군요.

신입사원 : 걱정 하실 것 없습니다. 대용량 배치는 프로그램이 많지 않으므로 제외하고, 온라인 SQL 튜닝 원칙을 몇 가지 일러주세요.

필자 : 온라인 SQL이라 하더라도 관점에 따라 튜닝방법이 다릅니다. 예를 들어 Peak Time에 Insert 문이나 Update 문, Select문이 집중적으로 몰릴 때의 튜닝방법이 있고, 단순히 SQL 하나에 에 집중해서 응답시간을 최소화 하는 튜닝방법이 있습니다.

신입사원 : 그런 것을 지금 모두 알아야 할 필요는 없습니다. 제가 튜닝 프로젝트에 투입되었다고 가정하고, 성능이 느린 Select문 하나를 받았을 때 튜닝을 어떻게 해야 하는지에 대해서만 설명해주시면 됩니다.

고단수 신입사원

이렇게 해서 신입사원에게 말려들게 되었다. 즉, 초보라도 몇 가지 원칙만 지키면 온라인 Select문에 대한 튜닝을 100점 만점에 90점을 맞을 수 있는 방법을 요구하는 것이다. 사실 이런 질문에 가장 적합한 답변은 “SQL 튜닝책을 읽어보라”는 것이다. 그런데 신입사원이 필자와 대화과정(튜닝책도 몇 가지 보았고 ~)에서 이런 답변을 못하도록 교묘히 막고 있다. 고단수이다. 몇 가지 방법만 알게 된다면 90점을 받는다고? 처음부터 그런 방법은 없다고 할 걸 그랬나? 후회가 된다. 어찌되었든 약속처럼 되어버렸으므로 이 글을 쓰게 되었다. 음…..머리가 아파온다.

온라인 Select문 튜닝 방법론

온라인 SQL의 튜닝방법은 여러 가지가 있을 수 있다. 하지만 그 중에서 가장 기초적이고, 기본적인 방법을 공개한다. 아래의 7가지 항목을 점검하고 약한 곳을 보강하면 된다. 이 글은 SQL 튜닝책을 두 권 정도 본 사람들을 위한 것이다. 튜닝에 자신있는 사람들은 볼 필요가 없다.

1. 적절한 인덱스를 사용하여 Block I/O를 최소화 하라

조인이 없는 경우는 적절한 인덱스를 사용하는 것 만으로도 상당한 효과를 볼 수 있다. 조인이 있는 경우는 특히 Driving(선행) 집합에 신경을 써야 한다. 왜냐하면 Nested Loop 조인을 사용했고, 선행집합의 건수가 많다면, 후행집합의 조인의 시도횟수가 증가하므로 성능이 느려진다. 따라서 적절한 인덱스를 이용하여 선행집합의 건수를 줄인다면, 혹은 가장 적은 집합을 선행으로 놓는다면, 후행집합으로의 조인건수는 줄어든다. 물론 이때에도 후행집합의 적절한 인덱스는 필수 조건이다. Driving 집합의 Block I/O를 줄이기 위하여 최적화된 인덱스가 없다면 생성하고, 있다면 그것을 사용하라. 다시 말해 최적의 Access Path를 만들어라.

운영중인 시스템이라면 최적의 Access Path를 위해 인덱스를 변경하거나 생성할 때는 주의해야 한다. 현재 튜닝하고 있는 SQL에 최적화된 인덱스를 생성하더라도 다른 SQL에 악영향을 줄 수 있기 때문이다. 인덱스를 생성하거나 변경할 때는 그 테이블을 사용하는 다른 SQL의 실행계획이 변경되지 않는지 각별히 신경을 써야 한다. 이런 이유 때문에 개발과정에서 효율적인 인덱스 설계가 중요시 된다.

2. 조인방법과 조인순서를 최적화 하라

온라인에서 사용하는 Select문은 좁은 범위를 검색하는 경우가 많다. 이럴 때는 대부분 Nested Loop Join이 유리하다. 그러므로 조인건수가 소량인 SQL에 Hash Join이나 Sort Merge Join이 발견되면 Nested Loop Join으로 변경하는 것이 더 유리한지 검토해야 한다. 물론 여기서도 Nested Loop 조인에 관해서만 다룬다.

Nested Loop 조인에서 가장 중요한 것은 조인순서이다. From절에 테이블(집합)이 두 개라면 후행집합의 관점에서는 적절한 인덱스만 존재한다면 그것으로 족하다. 만약 From절에 테이블(집합)이 세 개 이상이라면 조인순서를 변경할 수 있는지에 대한 두 가지 원리를 사용하라. 두 가지 원리는 아래의 단락에서 소개된다. 아무리 조인할 집합이 많다고 하더라도 이 두 가지의 원리는 동일하게 적용될 수 있다. 두 가지 원리를 이용할 때 필요하다면 Leading 힌트를 사용해야 한다.

첫 번째, 후행집합에 적절한 인덱스가 없는 경우에 조인순서를 바꾸면, 최적의 인덱스를 사용할 수 있는 경우가 많다. 예컨대, 튜닝전의 조인순서가 Aà B à C 라고 하면, 중간집합인 B에 적절한 인덱스가 없고 오히려 C에 적절한 인덱스가 존재하는 경우가 있다. 이럴 때는 B에 인덱스를 무작정 생성하지 말고, 조인순서를 A à C à B로 바꿀 수 있는지, 바꾸는 것이 더 효율적인지 검증하라. 조인순서만 바꾸어 주어도 일량이 획기적으로 줄어드는 경우가 많다. 만약 조인순서를 바꿀 수 없거나, C를 중간집합으로 하는 것이 비효율적이라면, B를 중간집합으로 유지하고 적절한 인덱스를 사용해야 한다.

두 번째, 조인되는 집합 중 특정 인덱스에서 Block I/O가 증가하는 경우에 조인순서의 변경을 검토하라. 이때 10046 Trace나 DBMS_XPLAN.Display_Corsor를 이용하면 조인집합들의 Block I/O량을 관찰할 수 있다. 예를 들어, 튜닝전의 조인순서가 Aà B à C 라고 하고, 집합 B에서 Block I/O량이 증가하면 A à C à B로 바꾸면 일량이 줄어드는 경우가 많다. C를 먼저 조인(Filter)하여 선행집합(B의 입장에서는 C가 선행이다)의 건수를 줄이고 B에 조인하면 성능이 향상된다.

3. Table Access(Random Access)를 최소화 하라

Random Access란 rowid로 테이블을 엑세스하는 것을 말한다. 1번과 2번을 최적화 했다면 Random Access도 자동으로 많이 줄어들었을 것이다. 하지만 그것이 끝은 아니다. 여전히 성능이 만족스럽지 못하다면 Random Access 횟수를 줄이는 것을 간과해서는 안 된다.

인덱스를 사용하면 rowid가 자동으로 획득된다. 만약 인덱스에 없는 컬럼을 Select 해야 한다면 rowid로 테이블을 엑세스 해야 한다. 이때 테이블로 엑세스 해야 할 건수가 많고, 인덱스의 컬럼순으로 테이블이 sort되어있지 않다면 성능이 매우 저하된다. 왜냐하면 테이블이 인덱스 기준으로 sort되어 있지 않기 때문에 테이블을 방문할 때마다 서로 다른 블럭을 읽어야 하기 때문이다.

비유적으로 설명해보자. 우리가 심부름을 할 때 세 군대의 상점(A,B,C)을 들러야 한다고 치자. 그 상점들이 모두 한 건물 내부에 존재한다면 얼마나 좋겠는가? 그 심부름은 매우 빠른 시간에 끝날 것이다. 하지만 반대로 상점 A는 부산에 있고 상점 B는 대구에 있고, 상점 C는 서울에 있다면? 만약 당신의 성격이 매우 좋아서 그 심부름을 한다고 해도 시간이 많이 걸릴 것이다. Random Access도 마찬가지이다. 인덱스의 rowid로 테이블을 방문할 때, 테이블이 인덱스기준으로 sort되어 상점처럼 다닥다닥 붙어있다면 성능은 매우 빠르고, 흩어져 있을수록 성능이 느려진다. (오라클에서는 테이블이 인덱스 기준으로 sort 되어 있는 정도를 Clustering Factor라고 한다.) 바로 이런 이유 때문에 index scan보다는 Table Scan이 느린 것이다. 따라서 우리는 Random Access의 부하를 최소화 해야 한다.

Random Access의 부하를 줄이는 방법은 네 가지이다. 첫 번째, 테이블의 종류를 변경하는 방법이다. IOT나 클러스터를 이용하면 Clustering Factor가 극단적으로 좋아진다. 또한 파티션을 이용하면 같은 범위의 데이터를 밀집시킬 수 있다. 두 번째, 효율적인 인덱스를 사용하거나 조인방법과 순서를 조정하여 Table Access를 최소화 하는 방법이다. 이 방법은 1번과 2번에서 이미 설명 되었다. 세 번째, 인덱스에 컬럼을 추가하여 Table Access를 방지하는 방법이다. 예를 들어 Select절의 특정 컬럼 때문에 테이블이 엑세스 된다면, 인덱스의 마지막에 그 컬럼을 추가하면 된다. 네 번째, 인덱스만 엑세스 하고 테이블로의 엑세스는 모든 조인을 끝내고 마지막에 시도하여 Random Access의 횟수를 줄이는 방법이다. 해당 글을 참조하라.

4. Sort나 Hash 작업을 최소화 하라

1,2,3번을 통하여 최적의 Access Path와 Join을 사용했다면, Block I/O의 관점에서는 튜닝이 끝난 것이다. 하지만 1,2,3번이 모두 해결되었다 해도 Order by나 Group By 때문에 성능이 저하 될 수 있다. 특히 결과가 많은 경우, sort는 치명적이다.

인덱스가 sort 되어있다는 특성을 이용하면 order by 작업을 대신할 수 있다. Group By도 sort 가 발생하는데 group by 단위와 인덱스의 컬럼이 동일 하다면 sort는 발생하지 않는다. 최적의 인덱스를 사용하면 Access Path를 개선하는 효과뿐만 아니라 Sort의 부하도 없어진다.

Union All을 제외한 집합연산(Union, Minus, Intersect)를 사용하면 Sort Unique 혹은 Hash Unique가 발생한다. Union은 Union All로 바꿀 수 없는지 검토해야 하고, Minus는 Not Exists 서브쿼리를 이용하여 Anti Join으로 바꿀 수 없는지 고려해야 한다. Intersect는 교집합이므로 조인으로 바꿀 수 있는지 검토해야 한다. 아주 가끔 Distinct를 사용한 SQL이 눈에 뛰는데 이 또한 Sort Unique 혹은 Hash Unique를 발생시킨다. 모델러나 설계자에게 문의하여 Distinct를 제거할 방법이 없는지 문의해야 한다.

Oracle 10g부터는 Hash Group By가 발생할 수 있는데, 이미 적절한 인덱스를 사용하는 경우라면 Hash Group By를 사용할 필요는 없다. 이런 경우 NO_USE_HASH_AGGREGATION 힌트를 사용하면 Sort Group By로 바꿀 수 있다. 이렇게 해주면 실행계획에 “SORT GROUP BY NOSORT” Operation이 발생하며, Sort나 Hashing 작업이 전혀 발생하지 않는다. Group By의 부하를 해결하는 또 하나의 방법은 스칼라 서브쿼리를 사용하는 것이다. 조인을 사용하면 Sum 값을 구하기 위해 Group By가 필수적이다. 하지만 스칼라 서브쿼리를 사용하면 Group By를 사용하지 않고도 sum 이나 Min/Max 값을 구할 수 있다. 또한 분석함수의 Ranking Family(rank, dens_rank, row_number)를 최적화된 인덱스와 같이 사용하면 Group By나 Sort를 하지 않고도 Min/Max 값을 구할 수 있다. 이때는 실행계획에 “WINDOW NOSORT” Operation이 발생한다. 관련 글을 참조하기 바란다.

5. 한 블록은 한번만 Scan하고 끝내라

같은 데이터를 반복적으로 Scan하는 SQL이 의외로 많다. 대표적인 경우가 Union All로 분리되었지만 실제로는 그럴 필요가 없는 경우이다. 예를 들어 Where 절에 구분코드가 1일 때 , 2일 때, 3일 때 별로 SQL이 나누어져 있는 경우이다. Where 절을 구분코드 in (1,2,3) 으로 처리하고, Select절에서 Decode나 Case 문을 사용하여 구분코드별로 처리해준다면 Union All은 필요 없다. Union All을 사용하는 또 한가지의 경우는 Sub Total(소계)과 Grand Total(총계)를 구해야 하는 경우이다. 이 경우도 Rollup/Cube나 Grouping Sets를 Group By절에 사용한다면 소계나 총계를 위한 별도의 Select문을 실행 시킬 필요는 없다. 1~4번의 과정은 SQL문의 변경이 없거나 최소화 된다. 하지만 5번의 경우는 SQL을 통합시켜야 하기 때문에 시간이 많이 소모되며, 많은 사고가 요구되는 창조적인 과정이다. 여기까지 했다면 진행되었다면 원본 SQL 자체의 튜닝은 완료 된 셈이다.

6. 온라인의 조회화면이라면 페이징처리는 필수이다

부분범위 처리를 해야 한다. 물론 전체 건을 처리해야 하는 경우는 있을 것이다. 하지만 조회화면이라면 몇 십만 건 혹은 몇 만 건이나 되는 결과를 모두 볼 수 없다. 따라서 볼 수 있는 단위로 끊어서 출력해야 한다. 예를 들어 결과 건수가 10만 건이라고 해도 최초의 50건을 화면에 먼저 뿌린다면 1,2,3,4 번에서 설명했던 모든 부하(Block I/O의 부하, 조인의 부하, Random Access의 부하, Sort의 부하)를 한꺼번에 감소시킬 수 있다. 따라서 가능하면 개발자를 설득하거나 책임자를 설득하여 페이징 처리를 하는 것이 바람직하다.

페이징 처리를 해도 효과를 볼 수 없는 몇 가지 예외가 있다. 분석함수를 사용하거나, Connect By + Start With를 사용한다면 페이징 처리의 효과는 없다. 분석함수의 경우 인라인뷰의 외부로 뺄 수 있다면 부분범위 처리가 가능하다. 이에 관해서는 해당 글을 참조하기 바란다. Connect By + Start With를 사용한 경우는 부분범위처리가 불가능하다. 하지만 11g R2의 신기능인 Recursive With절을 사용한다면 페이징 처리의 효과를 볼 수 있다. 이때, Recursive With절에 Search절(Order By절과 같은 기능)을 사용한다면 Connect By와 마찬가지로 페이징 처리의 효과가 없으니 주의해야 한다. 즉 인덱스의 구성을 적절히 하여 Sort를 대신해야 한다. Recursive With가 무엇인지 궁금한 사람은 관련 글을 참조하기 바란다.

7. 답이 틀리면 안 된다. SQL을 검증하라

7번은 SQL 자체를 튜닝하는 것은 아니다. 하지만 7번을 튜닝 방법에 추가한 이유는 있다. 튜닝을 하였음에도 답이 틀린다면, 튜닝을 하지 않은 것 보다 못하다. 그러므로 튜닝 후에 답이 옳은지 항상 검증해야 한다. 1번~ 7번 중에 가장 중요한 것이 7번이다.

방법론 정리

1. 적절한 인덱스를 사용하여 Block I/O를 최소화 하라.

2. 조인방법과 조인순서를 최적화 하라.

3. Table Access(Random Access)를 최소화 하라

4. Sort나 Hash 작업을 최소화 하라

5. 한 블록은 한번만 Scan하고 끝내라

6. 온라인의 조회화면이라면 페이징처리는 필수이다

7. 답이 틀리면 안 된다. SQL을 검증하라

방법론의 의미

만약 1~7번을 모두 적용할 수 있는 경우임에도 불구하고 하나라도 빠진다면 그것은 최적화된 SQL이 아니다. 물론 튜닝을 할 때 위의 1~6번을 항상 적용할 수 있는 것은 아니다. 경우에 따라서는 하나만 적용될 수도 있고, 두 개만 적용할 수 있는 SQL도 있다. 하지만 1~6번을 모두 적용할 수 있는지 꼼꼼히 살펴야 한다.

이 글은 튜닝 입문하여 관련 책들을 몇 권 본 사람들을 위한 기본적인 튜닝방법에 관한 것이다. 1번부터 7번까지의 방법은 기본 중에 기본이다. 이것들만 알아도 온라인 조회화면에서 사용하는 SQL을 튜닝하는데 어려움이 없을 것이다. 다시 말해 90%는 해결 할 수 있다. 그렇다면 나머지 10%는? 그것들은 그때 그때 마다 다르게(On the fly 모드) 처리된다. 또한 그것들은 책이나 매뉴얼에 나와있지 않기 때문에 경험치 이거나 실험과 연구의 결과로 알아내는 것들이다.

일상을 낯설게 느껴보니 좋은 점이 많다. 언제 필자의 다른 일상(모델링, 시스템분석/진단)에 대한 방법론도 만들어 보려고 한다.

저작자표시 비영리 동일조건

'Oracle > SQL Tuning' 카테고리의 다른 글

COPY_T 테이블 필요한가? (6)	2011.04.04
Sort 부하를 좌우하는 두 가지 원리 (11)	2011.03.29
Pagination과 분석함수의 위험한 조합 (26)	2010.12.23
오라클의 Update문은 적절한가? (15)	2010.04.14
Connect By VS ANSI SQL (7)	2010.02.11

Posted by extremedb

,

같은 테이블을 두 번 읽었지만 일량이 틀려요

Oracle/Data Join Method 2011. 1. 14. 00:33

select /*+ full(a) full(b) leading(a) use_hash(b) */

a.col1, b.col2

from tab1 a,

tab1 b

where a.col1 = b.col2 ;

오해와 현실

“위의 SQL을 보면 from 절의 두 테이블은 동일하다. 그리고 건수가 많아서 힌트를 주었으므로, 둘 다 full table scan을 할 것이다. 따라서 위의 SQL을 실행하고 결과를 본다면, a 와 b의 일량(block I/O량)은 동일하다.”라고 알고 있는 사람이 많이 있다. 즉 a를 읽었더니 block I/O 량이 1000 블럭이라면 b를 읽을 때도 1000 블럭이 나올 것이라는 이야기다. 이런 주장이 사실일까? 결론부터 말하자면 사실이 아니다. b쪽이 더 많은 블럭을 scan 해야 한다. 그래서 b쪽을 scan할 때 더 느리다. b쪽에 더 많은 일량이 나온다면 버그라고 생각하는 사람도 있지만, 버그가 아니라 정상적인 결과이다.

이 글의 목적

위의 결론에 따르면 후행테이블을 scan 할 때 심각한 성능저하가 발생 할 수 있다. 이런 현상을 주위의 지인들에게 질문한 결과 적절한 이유나 원인을 말하는 사람은 거의 없었다. 성능문제의 원인을 모르면 튜닝을 할 수 없다. 그러므로 이 글에서는 성능이 저하되는 이유를 독자에게 제시하고, 비효율을 해결 할 수 있는 방법을 설명한다. 또한 이런 문제가 발생하지 않는 예외적인 경우도 살펴본다.

이제 테스트를 진행하기 위해 테이블을 하나 만들자.

create table test1 as

select lpad(level, 5, '0') as num,

lpad(level, 60, '0') as num_txt

from dual

connect by level <= 50000 ;

인덱스가 없음으로 앞으로 모든 실행계획은 full table scan이 될 것이다. 정확한 분석을 위해 test1 테이블의 full table scan 일량(logical reads)을 알아보자.

select count(*)

from test1;

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.01 | 504 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.01 | 504 |

| 2 | TABLE ACCESS FULL| TEST1 | 1 | 50000 |00:00:00.06 | 504 |

-----------------------------------------------------------------------------

full table scan의 결과 일량은 504 블럭이다. 따라서 test1 테이블의 데이터가 변경되지 않는다면 항상 504 블럭이 나와야 한다. 정말 그렇게 될까?

아래 SQL의 조인 순서는 a--> b 이다.

select /*+ leading(a b) */ a.num

from test1 a,

test1 b

where a.num = b.num

and a.num > '00100'

and substr(b.num_txt, -5) > '00100'; --> substr의 인자 -5는 마지막 다섯 자리라는 뜻이다.

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 49900 |00:00:00.45 | 5998 |

|* 1 | HASH JOIN | | 1 | 49900 |00:00:00.45 | 5998 |

|* 2 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.06 | 504 |

|* 3 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.15 | 5494 |

-----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("A"."NUM"="B"."NUM")

2 - filter("A"."NUM">'00100')

3 - filter((SUBSTR("B"."NUM_TXT",(-5))>'00100' AND "B"."NUM">'00100'))

무려 11배나 차이가 난다

선행테이블은 정상적으로 504블록이 나왔다. 하지만 이상하게도 선행테이블과 동일한 테이블인 후행테이블( b )의 일량이 약 11배나 많다. 수행시간도 후행테이블이 더 느리다. 같은 테이블을 동일한 방법으로 scan 했는데 왜 Block I/O 수가 11배나 차이가 날까?

힌트를 주어 조인 순서를 바꿔보자.

select /*+ leading(b a) */ a.num

from test1 a,

test1 b

where a.num = b.num

and a.num > '00100'

and substr(b.num_txt, -5) > '00100';

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 49900 |00:00:00.34 | 5998 |

|* 1 | HASH JOIN | | 1 | 49900 |00:00:00.34 | 5998 |

|* 2 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.11 | 504 |

|* 3 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.06 | 5494 |

-----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("A"."NUM"="B"."NUM")

2 - filter((SUBSTR("B"."NUM_TXT",(-5))>'00100' AND "B"."NUM">'00100'))

3 - filter("A"."NUM">'00100')

array size가 원인이다

이번에는 반대로 a의 일량이 b보다 11배 많게 나왔다. 즉 일관성 있게 후행테이블의 일량이 11배가 많다. 그 이유는 툴(오렌지)의 array size가 10 으로 되어있었기 때문이다. 다른 말로 바꾸면 array size가 10 이기 때문에 49900건을 모두 출력하려면 4990번 fetch 해야 한다. 즉 위의 일량 5494는 원래의 블록 수인 504에 fetch 회수(4990 블럭)을 더한 것이다. 여기까지는 이해가 될 것인데 문제는 “왜 fetch 할 때마다 한 블록을 더 읽어야 하는가?” 이다.

Fetch 할 때마다 이전에 읽었던 1블럭을 더 읽어야 한다

한 블록에 20건이 들어있다고 가정하고, Array size가 10 이라고 치자. 그러면 한 블럭의 데이터(20건)를 모두 출력 하려면 동일한 블럭을 반복적으로 두 번 fetch 해야 한다. 바로 이것이 fetch 할 때마다 이미 읽었던 블럭(직전에 fetch 했던 block중 마지막 block)을 다시 Scan 할 수 밖에 없는 이유이다.

비효율을 없애려면 array size를 적정 수준으로 늘려라

set arraysize 100 --array size 100으로 변경

select /*+ leading(a b) */ a.num

from test1 a,

test1 b

where a.num = b.num

and a.num > '00100'

and substr(b.num_txt, -5) > '00100';

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 49900 |00:00:00.38 | 1507 |

|* 1 | HASH JOIN | | 1 | 49900 |00:00:00.38 | 1507 |

|* 2 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.06 | 504 |

|* 3 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.11 | 1003 |

-----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("A"."NUM"="B"."NUM")

2 - filter("A"."NUM">'00100')

3 - filter((SUBSTR("B"."NUM_TXT",(-5))>'00100' AND "B"."NUM">'00100'))

array size를 올리자 logical read가 5494 에서 1003 으로 변경되었다. 5배 이상 일량(logical reads 량)이 줄어들었다. 하지만 아직도 원래의 블록 수인 504 보다 두 배정도 많다.

set arraysize 1000 --array size 1000으로 변경

select /*+ leading(a b) */ a.num

from test1 a,

test1 b

where a.num = b.num

and a.num > '00100'

and substr(b.num_txt, -5) > '00100';

-----------------------------------------------------------------------------

-----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 49900 |00:00:00.34 | 1058 |

|* 1 | HASH JOIN | | 1 | 49900 |00:00:00.34 | 1058 |

|* 2 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.06 | 504 |

|* 3 | TABLE ACCESS FULL| TEST1 | 1 | 49900 |00:00:00.09 | 554 |

-----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("A"."NUM"="B"."NUM")

2 - filter("A"."NUM">'00100')

3 - filter((SUBSTR("B"."NUM_TXT",(-5))>'00100' AND "B"."NUM">'00100'))

array size를 1000으로 올리자 logical read가 1003 에서 554로 변경되었다. 이 정도면 원래의 블럭수인 504와 비슷하다. 554와 504의 차이는 50 블럭이므로 fetch를 50번 했다는 것을 알 수 있다.

해결방법
테스트의 결과는 fetch가 발생할 때마다 직전 블럭을 읽어야 함을 알 수 있다. 따라서 array size를 적절히 늘리면 fetch 회수가 줄어들므로 이전 블럭을 읽는 횟수도 같이 줄어든다. 이에 따라 성능도 향상된다. 하지만 array size를 늘려도 선행테이블은 logical read의 변화가 없다. 왜냐하면 선행테이블은 fetch에 영향을 끼치지 못하며, 후행 테이블이 scan 되어 조인에 성공될 때만 데이터가 client로 전송(fetch) 되기 때문이다.

조인이 없을 때도 비효율은 발생한다
이런 현상은 full table scan과 해시조인의 조합에서만 발생하는 것은 아니다. 조인 없이 from 절에 테이블이 하나뿐일 때도 동일하게 발생한다. 아래의 SQL이 전형적인 예제이다.

array size가 10일 때

select num

from test1;

Trace Version : Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

Environment : Array Size = 10

Long Size = 80

********************************************************************************

Call Count CPU Time Elapsed Time Disk Query Current Rows

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Parse 1 0.000 0.000 0 0 0 0

Execute 1 0.000 0.000 0 0 0 0

Fetch 5001 0.328 0.219 0 5504 0 50000

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Total 5003 0.328 0.219 0 5504 0 50000

Misses in library cache during parse: 0

Optimizer goal: ALL_ROWS

Parsing user: SYS (ID=0)

Rows Row Source Operation

------- ---------------------------------------------------

0 STATEMENT

50000 TABLE ACCESS FULL TEST1 (cr=5504 pr=0 pw=0 time=67049 us cost=143 size=300000 card=50000)

fetch를 5001 번 했기 때문에 원래의 블럭수( 504 )에 비해 logical read량도 약 5000 블럭이 늘었다.

array size가 100일 때

Trace Version : Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

Environment : Array Size = 100

Long Size = 80

********************************************************************************

Call Count CPU Time Elapsed Time Disk Query Current Rows

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Parse 1 0.000 0.000 0 0 0 0

Execute 1 0.000 0.000 0 0 0 0

Fetch 501 0.063 0.041 0 1004 0 50000

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Total 503 0.063 0.041 0 1004 0 50000

Misses in library cache during parse: 1

Optimizer goal: ALL_ROWS

Parsing user: SYS (ID=0)

Rows Row Source Operation

------- ---------------------------------------------------

0 STATEMENT

50000 TABLE ACCESS FULL TEST1 (cr=1004 pr=0 pw=0 time=75254 us cost=143 size=300000 card=50000)

Array size가 10인 경우(5504)에 비해 일량이 약 5배 정도 감소했다. 그 이유는 fetch 회수가 10배로 줄어들었기 때문이다.

array size가 1000 일 때

Trace Version : Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

Environment : Array Size = 1000

Long Size = 80

********************************************************************************

Call Count CPU Time Elapsed Time Disk Query Current Rows

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Parse 1 0.000 0.000 0 0 0 0

Execute 1 0.000 0.000 0 0 0 0

Fetch 51 0.031 0.016 0 554 0 50000

------- ------ -------- ------------ ---------- ---------- ---------- ----------

Total 53 0.031 0.017 0 554 0 50000

Misses in library cache during parse: 1

Optimizer goal: ALL_ROWS

Parsing user: SYS (ID=0)

Rows Row Source Operation

------- ---------------------------------------------------

0 STATEMENT

50000 TABLE ACCESS FULL TEST1 (cr=554 pr=0 pw=0 time=50383 us cost=143 size=300000 card=50000)

무작정 크게 한다고 좋아지지 않는다

array size를 1000으로 변경하니 array size가 10인 경우(5504 블럭)에 비해 일량이 약 10배 정도 감소했다. 하지만 array size가 100 인 경우와 비교해 보면 일량이 고작 2배 정도만 줄어들었다. 다시 말해 여기서 array size를 더 크게 하더라도 얻는 이익은 별로 없다는 것이다. 따라서 무작정 array size를 늘려서는 안 된다. 메모리에 부하를 줄 뿐만 아니라 한번에 많은 데이터가 client로 전송되므로 네트웍 I/O가 과도 하게 늘어날 수 있다. 따라서 client로 fetch 할 건수가 많고, 네트웍 망의 성능이 좋다면 1000~ 2000 정도를 유지하는 것이 적당하다. 물론 조회 프로그램에서는 페이징 처리를 하는 것이 가장 좋지만, 업무적으로 전체 건을 볼 수 밖에 없는 경우는 array size를 적절히 조절하는 것이 대안이 될 수 있다.

성능문제의 발생조건
fetch의 비효율은 select문에서만 발생한다. 즉 insert–select 나 CTAS(create table as select) 그리고 merge 문 등에서는 이런 종류의 성능저하가 발생하지 않는다. 왜냐하면 DML문은 select문과 달리 조회(데이터를 client로 fetch) 할 필요가 없고, commit이 되면 바로 종료되기 때문이다.

모든 규칙에 예외는 있다

full table scan + sort merge join 의 조합에서는 fetch의 비효율이 발생하지 않는다. 왜냐하면 full table scan + sort merge join 조합은 hash join의 조합과 달라서 모든 데이터를 sort 해야하기 때문이다. 모든 데이터를 sort하려면 어차피 모든 블럭을 scan해야 하므로 fetch를 여러번 해야만 하는 array size를 사용할 필요가 없는 것이다. 그리고 fetch를 여러번 하지 않기 때문에 항상 일량이 일정하다.

또 다른 예외의 경우는 1 블럭에 1 row만 저장되는 경우이다. 이런 경우는 블럭을 한번만 엑세스 해도 그 블럭의 모든 데이터를 한번에 fetch 할 수 있으므로, 같은 블록을 반복해서 읽을 필요가 없다. 따라서 array size를 변경해도 일량이 달라지지 않는다.

호기심이 있는 독자는 아래의 테이블을 만들고 위의 테스트를 똑같이 진행 해보기 바란다. 위의 test 결과와는 다를 것이다.

drop table test1 ;

create table test1 as

select lpad(level, 5, '0') as num,

lpad(level, 7000, '0') as num_txt

from dual

connect by level <= 50000 ;

array size 항상 나쁜가?
우리는 array size가 있음으로 해서 부분범위처리를 할 수있다. full table scan을 동반하는 해시조인의 경우에도 중간에 효율적으로 멈출 수 있다. 예를 들어 결과건수가 1억건이며, 만건을 먼저 조회한 후에 다음 만건을 보고 싶다고 할때, 운반단위(array size)가 1000 이라면 10번 fetch 하면 멈출 수 있다. 반면에 array size가 없다면 중간에 멈출 수 없으므로 1억건을 모두 fetch 한후에나 결과를 화면에서 볼 수 있다.

결론

같은 테이블을 두 번 full table scan 하고, 그 둘을 해시조인하면 대부분의 경우 후행 테이블의 I/O량이 더 많다. 그래서 후행테이블을 scan 할 때가 더 느리다. 왜냐하면 직전 fetch 때에 이미 읽었던 block의 데이터가 모두 fetch 되지 않을 수 있으므로 그 블럭을 한번 더 읽어보아야 확인 할 수 있기 때문이다. 이런 비효율이 많이 발생하는 경우는 array size가 작기 때문이다. 따라서 적절한 array size로 늘려주면 성능문제를 해결 할 수 있다.

fetch의 비효율은 full table scan이나 full table scan + hash join 조합을 사용할 때만 발생하는 것은 아니다. index scan을 할때도 똑같이 비효율이 발생한다.(주1) 즉 fetch의 비효율 문제는 인덱스를 사용할때나 테이블을 scan할때를 가리지 않고 모두 발생한다. 이런 사실들로 미루어 볼때, 위에서 언급한 몇가지의 예외를 제외한다면, 우리는 다음과 같은 결말을 낼 수 있다.

"select문의 결과건수가 많음에도 불구하고, 페이징 처리가 되지 않고, array size가 작은 조회용 프로그램이라면 fetch의 비효율은 존재한다."

주1 : 인덱스 사용시 fetch의 비효율 문제는 이미 책으로 정리가 되어 있으므로 필자가 언급하지 않는다. 이 문제에 관심이 있는 사람은 조동욱 님의 책 Optimizing Oracle Optimizer를 참조하기 바란다.

저작자표시 비영리 동일조건

'Oracle > Data Join Method' 카테고리의 다른 글

PARTITION WISE JOIN이란 무엇인가? (406)	2013.05.21
Sort Merge Join에 대한 오만과 편견 (476)	2011.04.28
Oracle 조인 방법 25가지 (15)	2010.02.26
Nested Loop Join 성능향상과 관련된 2가지 원리 (17)	2009.05.09
Hash Join Right (Semi/Anti/Outer) 의 용도 (17)	2009.03.02

Posted by extremedb

,

Pagination과 분석함수의 위험한 조합

Oracle/SQL Tuning 2010. 12. 23. 13:08

-대표적인 페이징 처리방법

-누적집계가 필요할 때 페이징(부분범위) 처리방법

-Pagination의 단점을 이용하는 방법

주의사항

이 글에서 사용되는 분석함수는 현재 row 까지의 누적집계(Cumulative total) 이다. 이와 반대로 전체집계(Grand Total)나 그룹집계(Sub total)는 부분범위처리를 할 수 없다. 왜냐하면 데이터를 모두 읽어야만 결과를 낼 수 있기 때문이다. 하지만 누적집계는 데이터가 sort 되어 있고, 이미 출력된 컬럼들의 값을 알 수 있다면 부분범위처리가 가능하다. 우리는 이점을 이용할 것이다.

상황

Time Out이 발생하여 개발자가 종이 한 장을 들고 급하게 뛰어왔다.

개발자: 페이징 처리를 했고, 최적의 인덱스도 존재하고, 그 인덱스를 잘 타는데도 Time Out이 발생합니다.

필자 : 그럴 리가요?

개발자: 이 SQL입니다. 한번 봐주세요.

필자 : 음….분석함수 때문에 전체 건을 읽고, 전체 건을 sort하는 군요. 페이징 처리방법을 약간 변경하면 됩니다.

개발자: 이 방법은 SQL 작성 가이드에 나온 방법입니다. 이 방법을 쓰지 않으면 사수에게 혼납니다.

필자 : 이 방법을 사용하지 말라는 이야기가 아니라, 분석함수의 위치만 옮기라는 이야기 입니다.

개발자: 그렇군요. 감사합니다.

이렇게 해서 장애상황은 없어졌다. 이후에 SQL 작성가이드에 페이징 처리시 누적집계가 있는 경우의 처리방법을 추가하였다고 한다.

Pagination SQL

개발자가 사용한 페이징 처리용 SQL은 아래와 같았다.

SELECT *

FROM (SELECT a.*, ROWNUM rnum

FROM ( ) a --> 여기에 order by 가 포함된 SQL 을 넣는다.

WHERE ROWNUM <= :v_max_row )

WHERE rnum >= :v_min_row ;

인라인뷰 a에 SQL을 넣기만 하면 페이징 처리가 된다. 물론 조회시 정렬이 필요하다면 order by가 포함된 SQL을 넣어야 한다. 이 방법은 토마스 카이트가 제시하였다. 이 기법은 약간의 비효율이 있다. 첫 페이지에서는 최적이지만, 뒤쪽 페이지를 읽을 때는 이전 페이지의 데이터를 모두 scan 해야 한다.(화면에 출력되지는 않는다.) 하지만 경험적으로 볼 때 비효율이 크지 않다. 왜냐하면 우리가 구글이나 네이버로 검색을 할 때 통상적으로 앞쪽의 몇 페이지만 보고 검색을 끝내기 때문이다. 만약 네이버에서 “트위터”라는 단어로 검색을 했더니 5729 페이지가 나왔다고 치면, 대부분 첫 페이지 혹은 두 번째, 세 번째 페이지에서 찾고자 하는 정보를 볼 수 있을 것이다. 5729 페이지를 모두 넘겨본 사람은 거의 없을 것이다. (만약 있다면 존경스럽다.) 따라서 위의 방법을 사용한다고 해도 성능저하는 거의 발생하지 않는다.

그런데 인라인뷰 a에 포함될 SQL에 누적집계용 분석함수가 포함될 때는 위의 방법에 약간의 변형을 가해야 한다. 그렇지 않고 위의 방법을 그대로 사용하면 심각한 성능저하가 발생할 수 있다. 즉 분석함수가 존재한다면 위의 방법은 무늬만 페이징 처리가 되며 실제로는 전체범위를 처리하여 Time Out이 발생 할 수 있다. 이 글에서는 누적집계용 분석함수가 있는 경우에 기존방법의 문제점을 제시하고 효과인 페이징 처리방법에 대해 논의 한다.

테스트를 위해 테이블과 인덱스를 생성한다.

CREATE TABLE sales_t AS SELECT * FROM sales;

CREATE INDEX ix_prod ON sales_t (prod_id);

먼저 인라인뷰 a 에 들어갈 SQL을 보자.

SQL1

SELECT /*+ INDEX(S IX_PROD) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold,

SUM (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id ;

----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 29282 |00:00:00.12 | 424 | |

| 1 | WINDOW SORT | | 1 | 29282 |00:00:00.12 | 424 | 1621K (0)|

| 2 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.10 | 424 | |

|* 3 | INDEX RANGE SCAN | IX_PROD | 1 | 29282 |00:00:00.03 | 60 | |

----------------------------------------------------------------------------------------------------

고객별로 channel_id와 time_id로 sort하여 누적합계를 구하는 SQL이다. 위의 SQL은 페이징 처리(부분범위 처리)가 되지 않은 것이다. 따라서 29282건이 결과로 출력되었고 424 블럭을 Scan 하였다. WINDOW SORT라는 operation이 존재하는 이유는 분석함수 때문이다. SQL에 order by가 있지만 별도의 SORT ORDER BY operation이 존재하지 않는다. 그 이유는 WINDOW SORT가 order by가 할 일을 대신해 주고 있기 때문이다. WINDOW SORT operation 때문에 PGA를 1621K만큼 사용하였다.

이제 페이징 처리를 해보자. 먼저 차이를 보여주기 위하여 분석함수를 제거하고 페이징 처리를 하였다.

SQL2

SELECT *

FROM (SELECT a.*, ROWNUM rnum

FROM (SELECT /*+ INDEX(S IX_PROD) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) a

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.02 | 424 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.02 | 424 | |

|* 2 | COUNT STOPKEY | | 1 | 20 |00:00:00.02 | 424 | |

| 3 | VIEW | | 1 | 20 |00:00:00.02 | 424 | |

|* 4 | SORT ORDER BY STOPKEY | | 1 | 20 |00:00:00.02 | 424 | 2048 (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.13 | 424 | |

|* 6 | INDEX RANGE SCAN | IX_PROD | 1 | 29282 |00:00:00.03 | 60 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

2 - filter(ROWNUM<=:V_MAX_ROW)

4 - filter(ROWNUM<=:V_MAX_ROW)

6 - access("S"."PROD_ID"=:V_PROD_ID)

페이징 처리를 하였음에도 똑같이 전체 블록인 424 블럭을 scan 하였다. 그 이유는 전체 건을 읽어서 정렬작업을 해야 하기 때문이다. 반면에 PGA의 사용은 2048에 불과하다. 왜냐하면 부분범위를 처리할 때는 전체 건을 sort하는 것이 아니라, 20 row 짜리 배열을 만들고 그 배열만 관리하면 되기 때문이다. 자세한 내용은 관련 글을 참조하라.

이제 분석함수를 추가해 보자.

SELECT *

FROM (SELECT a.*, ROWNUM rnum

FROM (SELECT /*+ INDEX(S IX_PROD) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold,

SUM(amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) a

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.03 | 424 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.03 | 424 | |

|* 2 | COUNT STOPKEY | | 1 | 20 |00:00:00.03 | 424 | |

| 3 | VIEW | | 1 | 20 |00:00:00.03 | 424 | |

| 4 | WINDOW SORT | | 1 | 20 |00:00:00.03 | 424 | 1621K (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.15 | 424 | |

|* 6 | INDEX RANGE SCAN | IX_PROD | 1 | 29282 |00:00:00.03 | 60 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

2 - filter(ROWNUM<=:V_MAX_ROW)

6 - access("S"."PROD_ID"=:V_PROD_ID)

성능저하의 원인은 분석함수

분석함수를 사용하자 PGA사용량이 급격히 늘었다. 분석함수가 없는 경우와 비교해보면 무려 791배나 차이가 난다. SQL1의 PGA 사용량과 위 실행계획의 PGA 사용량을 비교해 보면 분석함수의 PGA 사용량은 페이징 처리를 하지 않았을 때와 똑같다. 즉 페이징 처리를 하였지만 분석함수의 영향으로 전체범위 처리가 되어버린 것이다. 바로 이점이 페이징 처리를 하였음에도 Time-Out이 발생하는 이유였다. 어떻게 하면 비효율을 제거할 수 있을까? 아래의 SQL이 정답이다.

SELECT *

FROM (SELECT s.*, ROWNUM rnum,

SUM (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM (SELECT /*+ INDEX(S IX_PROD) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) s

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.02 | 424 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.02 | 424 | |

| 2 | WINDOW BUFFER | | 1 | 20 |00:00:00.02 | 424 | 2048 (0)|

|* 3 | COUNT STOPKEY | | 1 | 20 |00:00:00.02 | 424 | |

| 4 | VIEW | | 1 | 20 |00:00:00.02 | 424 | |

|* 5 | SORT ORDER BY STOPKEY | | 1 | 20 |00:00:00.02 | 424 | 2048 (0)|

| 6 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.14 | 424 | |

|* 7 | INDEX RANGE SCAN | IX_PROD | 1 | 29282 |00:00:00.04 | 60 | |

--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

3 - filter(ROWNUM<=:V_MAX_ROW)

5 - filter(ROWNUM<=:V_MAX_ROW)

7 - access("S"."PROD_ID"=:V_PROD_ID)

분석함수는 인라인뷰 밖으로 빼라

분석함수를 뷰의 외부로 위치를 바꾸자 PGA를 거의 사용하지 않는다. 분석함수가 추가되었음에도 PGA 사용량이 분석함수를 사용하지 않은 경우(SQL2)와 비슷하다. 그 이유는 20건에 대해서만 분석함수가 실행되었기 때문이다. 즉 ID 2번에서 사용한 PGA는 SORT를 위한 것이 아니다. 왜냐하면 이미 인라인뷰 내에서 SORT가 되었으므로 같은 작업을 반복할 필요가 없기 때문이다. 이런 경우는 order by절의 컬럼과 분석함수 OVER절의 컬럼이 일치한 경우만 나타난다. 이에 따라 Operation도 WINDOW SORT가 아니라 WINDOW BUFFER로 바뀌었다. 즉 20 row로 구성된 배열만 관리하면 된다. Order by 작업 또한 전체 건을 sort하지 않고 페이징 처리된 20건에 대해서 배열만 관리한 것이다.

절반의 성공

위의 실행계획이 best 인가 하면 그렇지는 않다. 왜냐하면 페이징 처리가 되지 않은 SQL1의 실행계획을 보면 29282건을 모두 읽었고, 페이징 처리가 된 위의 SQL 또한 마찬가지 이다. 다시 말해 위의 SQL은 결과적으로 20건만 출력되므로 비효율적인 전체범위를 처리한 것이다. 즉 PGA 사용(Sort)의 관점에서는 부분범위 처리가 되었지만 Block I/O의 관점에서는 전체범위를 처리하고 말았다.

이제 Block I/O 문제를 해결하기 위해 인덱스를 생성해보자.

CREATE UNIQUE INDEX PK_SALES_T ON SALES_T(PROD_ID, CUST_ID, CHANNEL_ID, TIME_ID);

이제 위의 인덱스를 이용하여 페이징 처리되지 않은 SQL을 실행해 보자.

SELECT /*+ INDEX(S PK_SALES_T) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold,

SUM (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id ;

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 29282 |00:00:00.11 | 28337 | |

| 1 | WINDOW BUFFER | | 1 | 29282 |00:00:00.11 | 28337 | 1495K (0)|

| 2 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.12 | 28337 | |

|* 3 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("S"."PROD_ID"=:V_PROD_ID)

28337 블록을 scan 하였고 PGA를 1495K나 사용하였다. WINDOW BUFFER operation을 본다면 전체 건을 sort한 것은 아니다. 하지만 배열(WINDOW)의 크기가 20건이 아니라 29282건이나 되므로 전체 건을 sort한 경우와 PGA 사용량이 비슷해져 버렸다. 전체 건을 sort한 SQL1의 PGA 사용량이 1621K 이므로 비슷하다고 할 수 있다.

페이징 처리를 해도...

이런 현상은 페이징 처리를 해도 분석함수를 인라인뷰 외부로 이동하지 않으면 마찬가지로 발생한다. 아래의 SQL을 보자.

SELECT *

FROM (SELECT a.*, ROWNUM rnum

FROM (SELECT /*+ INDEX(S PK_SALES_T) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold,

SUM (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) a

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.04 | 28337 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.04 | 28337 | |

|* 2 | COUNT STOPKEY | | 1 | 20 |00:00:00.04 | 28337 | |

| 3 | VIEW | | 1 | 20 |00:00:00.04 | 28337 | |

| 4 | WINDOW BUFFER | | 1 | 20 |00:00:00.04 | 28337 | 1495K (0)|

| 5 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 29282 |00:00:00.13 | 28337 | |

|* 6 | INDEX RANGE SCAN | PK_SALES_T | 1 | 29282 |00:00:00.03 | 118 | |

----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

2 - filter(ROWNUM<=:V_MAX_ROW)

6 - access("S"."PROD_ID"=:V_PROD_ID)

부분범위 처리가 아니라 전체범위 처리이다

많은 이들이 착각하는 것이 위의 SQL이다. 다시 말해 “order by와 분석함수의 over절에 최적화된 인덱스를 생성하면 부분처리가 되겠지” 라고 생각한다. 하지만 사실은 이와 다르다. 인덱스의 영향으로 Plan상에 sort order by와 window sort operation이 없으므로 부분범위 처리가 된 것으로 판단하면 안 된다. 20건을 읽은 것이 아니라 전체 건인 29282건을 읽었으며 PGA 사용량도 전체 건을 sort했던 경우(SQL1)와 비슷하다.

이런 상황에서도 해결방법은 분석함수를 밖으로 빼는 것이다. 아래의 SQL을 보자.

SELECT *

FROM (SELECT s.*, ROWNUM rnum,

SUM (amount_sold) OVER (PARTITION BY s.cust_id ORDER BY s.channel_id, s.time_id) AS sum_amt

FROM (SELECT /*+ INDEX(S PK_SALES_T) */

s.prod_id, s.cust_id, s.channel_id, s.time_id, amount_sold

FROM sales_t s

WHERE s.prod_id = :v_prod_id --> 30 대입

ORDER BY s.cust_id, s.channel_id, s.time_id

) s

WHERE ROWNUM <= :v_max_row --> 20 대입

)

WHERE rnum >= :v_min_row ; --> 1 대입

----------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 20 |00:00:00.01 | 23 | |

|* 1 | VIEW | | 1 | 20 |00:00:00.01 | 23 | |

| 2 | WINDOW BUFFER | | 1 | 20 |00:00:00.01 | 23 | 2048 (0)|

|* 3 | COUNT STOPKEY | | 1 | 20 |00:00:00.01 | 23 | |

| 4 | VIEW | | 1 | 20 |00:00:00.01 | 23 | |

| 5 | TABLE ACCESS BY INDEX ROWID| SALES_T | 1 | 20 |00:00:00.01 | 23 | |

|* 6 | INDEX RANGE SCAN | PK_SALES_T | 1 | 20 |00:00:00.01 | 3 | |

----------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("RNUM">=:V_MIN_ROW)

3 - filter(ROWNUM<=:V_MAX_ROW)

6 - access("S"."PROD_ID"=:V_PROD_ID)

정확히 20건에 대해서만 WINDOW BUFFER operation 이 발생하였다. 이에 따라 PGA 사용량도 최적이 되었다. 또한 Block I/O 관점에서도 최상이다. 28337 Block을 scan한 것이 아니라 고작 23 Block을 scan 하였다. 분석함수의 위치가 성능에 얼마나 큰 영향을 미치는지 알 수 있는 장면이다.

결론

페이징 처리가 되었음에도 Time Out이 발생한다면 누적집계용 분석함수를 의심해보아야 한다. 만약 분석함수가 존재한다면 인라인뷰 밖으로 빼야 한다. 그렇게 한다면 분석함수의 실행이 최소화되며 이에 따라 성능이 향상된다. 또한 order by와 분석함수에 최적화된 인덱스를 만든다면 전체 건을 읽지 않아도 되며 sort의 부하 또한 없어질 것이다. 다시 말해 비효율이 없는 페이징 처리가 가능하다.

원리는 따로 있다

이 글의 결론까지 보았음에도 한가지 의문점을 떠올리지 못한다면 핵심원리를 놓친 것이다. 의문점이란 “분석함수를 인라인뷰 밖으로 빼도 답이 달라지지 않는가?” 이다. 분석함수를 인라인뷰 밖으로 빼는 방법이 가능한 이유가 뭐라고 생각하는가? 답을 보기 전에 잠시 이유를 생각해보기 바란다. 답은 아래에 있다.

답을 보려면 아래의 글을 마우스로 드래그 하시오

이 글의 처음에 언급했던 페이징 처리시 약간의 비효율 있다고 했는데 이것이 원리이다. Tomas Kyte가 제시한 pagination 방법을 사용하면 뒤쪽 페이지를 읽을 때는 이전 페이지의 데이터를 모두 scan 해야 만 한다. 이 비효율을 이용하는 것이 핵심이다. 왜냐하면 한 페이지의 누적집계를 구하려면 이전 페이지의 값들을 모두 알아야 하기 때문이다. 예를 들어 홍길동 고객의 실적이 1 페이지와 2 페이지에 걸쳐서 나온다고 할 때, 1 페이지 있는 홍길동의 실적과 2페이지에 있는 홍길동의 실적을 더해야만 2 페이지의 누적집계를 구할 수 있다. 그런데 위의 방법을 사용하면 분석함수를 인라인뷰 밖으로 빼더라도 이전 페이지의 값을 보존하기 때문에 누적집계의 값은 정확하다.

“페이징 처리시 누적집계용 분석함수를 인라인뷰 밖으로 빼라”고 누군가에게 guide할 때 단점(비효율)을 장점으로 이용했음을 같이 알려주기 바란다. 그것이 원리이자 핵심이기 때문이다.

PS

즐거운 성탄절을 보내시기 바랍니다.

지난 1년간 이 블로그를 이용해 주셔서 감사합니다.

저작자표시 비영리 동일조건

'Oracle > SQL Tuning' 카테고리의 다른 글

Sort 부하를 좌우하는 두 가지 원리 (11)	2011.03.29
SQL튜닝 방법론 (20)	2011.01.27
오라클의 Update문은 적절한가? (15)	2010.04.14
Connect By VS ANSI SQL (7)	2010.02.11
USE_CONCAT 힌트 제대로 알기 (5)	2009.07.17

Posted by extremedb

,

검색조건을 동적으로 바꾸어야 할 때

Oracle/SQL Pattern 2010. 12. 14. 07:01

-동적인 조회조건에서 SQL 작성법
-다양한 검색조건에서 SQL 튜닝방법

-쿼리변환의 부정적 측면 해결

아래는 신입사원과 김대리의 대화내용이다. 신입사원이 머리를 긁고 있다. 문제가 어려운 모양이다.

신입사원: 상황에 따라서 조회조건이 달라지는데 어떻게 처리하죠?

김대리: 각각의 상황에 대해 union all로 처리하고 서로 다른 SQL로 처리하면 되.

신입사원: 네 알겠습니다. (조금 후에) 김대리님, 그렇게 하면 SQL이 너무 길어서 복잡해져요.

총 6가지의 조건이 상황에 따라 달라지기 때문이죠.

김대리: 그럼 방법이 없지. Dynamic SQL로 작성해. 단 Dynamic SQL을 쓰되 바인드 변수를 사용해야 돼.

신입사원: 그건 어떻게 사용하죠? 제가 Dynamic SQL 사용법을 몰라서 그럽니다.

김대리: 내가 조금 있다가 가르쳐 줄게.

신입사원: 감사합니다.

이런 상황에서는 Union all로 여러 개의 SQL을 작성하는 것 보다는 Dynamic SQL을 사용하는 것이 해결책이 될 수 있다. 또한 많은 사람들이 그렇게 하고 있다. 하지만 꼭 둘 중에 하나만 골라야 한다는 생각은 버려야 한다. 그렇지 않으면 Union all을 사용하여 SQL이 매우 길어지거나 C나 JAVA 언어의 도움을 받아 IF Then ELSE 로직으로 SQL을 동적으로 생성하는 불리함을 감수해야 한다. 따라서 이보다 더 쉽고 간단한 방법이 있다면 그것을 사용하면 된다.

환경

DBMS: Oracle11g R2

각 테이블의 PK 인덱스는 이미 존재하므로 추가적인 인덱스만 설명한다.

EMP_MGR_HR_DT_IX: employee( manager_id + hire_date )

EMP_DEPT_IX : employee( department_id )

EMP_JOB_IX : employee( job_id )

다양한 조회조건을 제외하면 SQL은 다음과 같이 단순하다.

SELECT e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

여기까지는 SQL이 쉽다. 하지만 여기서부터는 까다로운 요구사항 때문에 SQL에 분기가 발생한다. 원래는 6가지의 where 조건을 적용해야 하지만 지면관계상 요구사항은 네 가지로 한정한다.

업무 요구사항

l 네 가지 패턴으로 조회조건이 들어온다. 각각의 패턴들은 :v_delimit(구분자)로 식별이 가능하다.

l 패턴 1 :v_delimit = 1 인 경우는 j.job_id = :v_job 조건으로 조회한다.

l 패턴 2 :v_delimit = 2 인 경우는 e.manager_id = :v_emp AND e.hire_date BETWEEN :v_hr_fr AND :v_hr_to 조건으로 조회한다.

l 패턴 3 :v_delimit = 3 인 경우는 d.department_id = :v_dept 조건으로 조회한다.

l 패턴 4 :v_delimit = 4 인 경우는 l.location_id = :v_loc 조건으로 조회한다.

l 모든 패턴 1~4에 filter 조건 d.manager_id > 0 가 공통적으로 적용되어야 한다.

성능 요구사항

여기까지는 업무팀의 요구사항이지만 개발자의 요구사항도 있다. 즉 where 조건이 패턴에 따라 동적으로 변경되면서도 각 패턴의 실행계획을 튜너의 마음대로 조정할 수 있어야 한다. 즉 네 가지 패턴의 SQL에 대해 서로 다른 힌트를 사용할 수 있어야 한다.

이런 까다로운 요구사항을 보고 가장 먼저 떠올릴 수 있는 생각은 Union all로 분기하는 것이다. 하지만 이 방법은 SQL이 길어지므로 코딩량을 증가시킨다. 두 번째로 생각할 수 있는 방법은 Dynamic SQL을 사용하는 것이다. 하지만 이 경우는 Where 조건뿐만 아니라 Select 절도 동적으로 변경되어야 한다. 왜냐하면 구분자의 값에 따라 힌트를 동적으로 만들어야 하기 때문이다. 따라서 우리는 이런 방법들을 사용하지 않을 것이다.

아래의 SQL을 실행할 때는 구분자인 :v_delimit의 값에 1을 대입해야 한다. 즉 패턴 1의 경우이다. 따라서 :v_job 과 :v_delimit를 제외한 나머지 변수 값은 모두 null이다.

SELECT /*+ USE_CONCAT */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND ( ( :v_delimit = 1 AND j.job_id = :v_job ) --> :v_delimit = 1 입력, :v_job = 'SA_MAN' 입력

OR ( :v_delimit = 2 AND e.manager_id = :v_emp

AND e.hire_date BETWEEN :v_hr_fr AND :v_hr_to )

OR ( :v_delimit = 3 AND d.department_id = :v_dept )

OR ( :v_delimit = 4 AND l.location_id = :v_loc )

)

AND d.manager_id > 0;

OR를 Union all로 바꿔서 생각한다면 이해가 빠를 것이다. 복잡한 요구사항을 만족하면서도 SQL이 매우 가벼워졌다. Union all을 사용한 경우와 SQL을 비교해 보기 바란다. 길이는 많이 짧아졌지만 Union all을 사용할 때와 성능상 동일하다. 다시 말해 실행시점에서 하나의 SQL이 4개의 SQL로 분리될 것이다. (이를 OR-Expansion 이라 부른다) 이 정도 길이의 SQL 이라면 Union all로 구분하여 SQL을 각각 작성하는 방법이나 Dynamic SQL을 일부러 사용할 필요는 없다. 주의사항은 각 패턴 별로 적절한 인덱스가 있어야 한다는 것이다. 그렇지 않으면 구분자의 의미는 사라질 것이다. 이제 실행계획을 보자.

------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 5 |00:00:00.03 | 19 | |

| 1 | CONCATENATION | | 1 | 5 |00:00:00.03 | 19 | |

|* 2 | FILTER | | 1 | 0 |00:00:00.01 | 0 | |

|* 3 | HASH JOIN | | 0 | 0 |00:00:00.01 | 0 | 988K (0)|

| 4 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 5 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 6 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 7 | TABLE ACCESS BY INDEX ROWID| LOCATION | 0 | 0 |00:00:00.01 | 0 | |

|* 8 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

|* 9 | TABLE ACCESS BY INDEX ROWID| DEPARTMENT | 0 | 0 |00:00:00.01 | 0 | |

|* 10 | INDEX RANGE SCAN | DEPT_LOCATION_IX | 0 | 0 |00:00:00.01 | 0 | |

|* 11 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 | |

| 12 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 | |

| 13 | TABLE ACCESS FULL | JOB | 0 | 0 |00:00:00.01 | 0 | |

|* 14 | FILTER | | 1 | 0 |00:00:00.01 | 0 | |

|* 15 | HASH JOIN | | 0 | 0 |00:00:00.01 | 0 | |

| 16 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 17 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

|* 18 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 0 | 0 |00:00:00.01 | 0 | |

|* 19 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

|* 20 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 | |

|* 21 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

| 22 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 | |

|* 23 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 | |

| 24 | TABLE ACCESS FULL | JOB | 0 | 0 |00:00:00.01 | 0 | |

|* 25 | FILTER | | 1 | 0 |00:00:00.01 | 0 | |

| 26 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 27 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 28 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 29 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 | |

| 30 | TABLE ACCESS BY INDEX ROWID| EMPLOYEE | 0 | 0 |00:00:00.01 | 0 | |

|* 31 | INDEX RANGE SCAN | EMP_MGR_HR_DT_IX | 0 | 0 |00:00:00.01 | 0 | |

| 32 | TABLE ACCESS BY INDEX ROWID| JOB | 0 | 0 |00:00:00.01 | 0 | |

|* 33 | INDEX UNIQUE SCAN | JOB_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

|* 34 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 0 | 0 |00:00:00.01 | 0 | |

|* 35 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

|* 36 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 | |

|* 37 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 | |

|* 38 | FILTER | | 1 | 5 |00:00:00.03 | 19 | |

|* 39 | HASH JOIN | | 1 | 5 |00:00:00.03 | 19 | 360K (0)|

|* 40 | HASH JOIN | | 1 | 5 |00:00:00.01 | 11 | 385K (0)|

| 41 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 4 | |

| 42 | TABLE ACCESS BY INDEX ROWID | JOB | 1 | 1 |00:00:00.01 | 2 | |

|* 43 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | 1 |00:00:00.01 | 1 | |

|* 44 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 1 | 5 |00:00:00.01 | 2 | |

|* 45 | INDEX RANGE SCAN | EMP_JOB_IX | 1 | 5 |00:00:00.01 | 1 | |

|* 46 | TABLE ACCESS FULL | DEPARTMENT | 1 | 11 |00:00:00.01 | 7 | |

|* 47 | TABLE ACCESS FULL | LOCATION | 1 | 23 |00:00:00.03 | 8 | |

------------------------------------------------------------------------------------------------------------------

4개의 SQL이 각각 다른 조건의 인덱스로 Driving 되었다. 실행계획도 최적이다. 다시 말해 :v_delimit = 1 이 아닌 경우의 SQL은 전혀 실행되지 않았다. 하지만 만약 Hash Join이 맘에 걸린다면 아래처럼 힌트를 추가할 수 있다. Global Hint를 사용하면 하나의 SQL에는 하나의 힌트만 사용한다는 제약을 극복할 수 있다.

SELECT /*+ USE_CONCAT LEADING(@SEL$1_1 l d e j) USE_NL(@SEL$1_1 d e j)

LEADING(@SEL$1_2 d e l j) USE_NL(@SEL$1_2 e l j)

LEADING(@SEL$1_3 e d l j) USE_NL(@SEL$1_3 d l j)

LEADING(@SEL$1_4 j e d l) USE_NL(@SEL$1_4 e d l) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND ( ( :v_delimit = 1 AND j.job_id = :v_job ) --> :v_delimit = 1 입력, :v_job = 'SA_MAN' 입력

OR ( :v_delimit = 2 AND e.manager_id = :v_emp

AND e.hire_date BETWEEN :v_hr_fr AND :v_hr_to )

OR ( :v_delimit = 3 AND d.department_id = :v_dept )

OR ( :v_delimit = 4 AND l.location_id = :v_loc )

)

AND d.manager_id > 0;

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 5 |00:00:00.01 | 20 |

| 1 | CONCATENATION | | 1 | 5 |00:00:00.01 | 20 |

|* 2 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 3 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 4 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 5 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 6 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 7 | TABLE ACCESS BY INDEX ROWID| LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 8 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 9 | TABLE ACCESS BY INDEX ROWID| DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 10 | INDEX RANGE SCAN | DEPT_LOCATION_IX | 0 | 0 |00:00:00.01 | 0 |

| 11 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

|* 12 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 |

|* 13 | INDEX UNIQUE SCAN | JOB_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 14 | TABLE ACCESS BY INDEX ROWID | JOB | 0 | 0 |00:00:00.01 | 0 |

|* 15 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 16 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 17 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 18 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 19 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

|* 20 | TABLE ACCESS BY INDEX ROWID| DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 21 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 22 | TABLE ACCESS BY INDEX ROWID| EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

|* 23 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 |

|* 24 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 25 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 26 | INDEX UNIQUE SCAN | JOB_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 27 | TABLE ACCESS BY INDEX ROWID | JOB | 0 | 0 |00:00:00.01 | 0 |

|* 28 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 29 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 30 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 31 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 32 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 33 | TABLE ACCESS BY INDEX ROWID| EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

|* 34 | INDEX RANGE SCAN | EMP_MGR_HR_DT_IX | 0 | 0 |00:00:00.01 | 0 |

|* 35 | TABLE ACCESS BY INDEX ROWID| DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 36 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 37 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 38 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 39 | INDEX UNIQUE SCAN | JOB_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 40 | TABLE ACCESS BY INDEX ROWID | JOB | 0 | 0 |00:00:00.01 | 0 |

|* 41 | FILTER | | 1 | 5 |00:00:00.01 | 20 |

| 42 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 20 |

| 43 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 15 |

| 44 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 13 |

| 45 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 6 |

| 46 | TABLE ACCESS BY INDEX ROWID| JOB | 1 | 1 |00:00:00.01 | 2 |

|* 47 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | 1 |00:00:00.01 | 1 |

|* 48 | TABLE ACCESS BY INDEX ROWID| EMPLOYEE | 1 | 5 |00:00:00.01 | 4 |

|* 49 | INDEX RANGE SCAN | EMP_JOB_IX | 1 | 5 |00:00:00.01 | 2 |

|* 50 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 5 | 5 |00:00:00.01 | 7 |

|* 51 | INDEX UNIQUE SCAN | DEPT_ID_PK | 5 | 5 |00:00:00.01 | 2 |

|* 52 | INDEX UNIQUE SCAN | LOC_ID_PK | 5 | 5 |00:00:00.01 | 2 |

|* 53 | TABLE ACCESS BY INDEX ROWID | LOCATION | 5 | 5 |00:00:00.01 | 5 |

-------------------------------------------------------------------------------------------------------

힌트에 쿼리블럭명을 사용하였다. 각각의 쿼리블럭명은 DBMS_XPLAN.DISPLAY_CURSOR 함수에 +ALIAS 옵션을 추가하면 조회할 수 있다. 아래의 예제가 그것이다.

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +ALIAS' ));

…중간생략

Query Block Name / Object Alias (identified by operation id):

-------------------------------------------------------------

1 - SEL$1

7 - SEL$1_1 / L@SEL$1

8 - SEL$1_1 / L@SEL$1

9 - SEL$1_1 / D@SEL$1

10 - SEL$1_1 / D@SEL$1

11 - SEL$1_1 / E@SEL$1

12 - SEL$1_1 / E@SEL$1

13 - SEL$1_1 / J@SEL$1

14 - SEL$1_1 / J@SEL$1

20 - SEL$1_2 / D@SEL$1_2

21 - SEL$1_2 / D@SEL$1_2
…중간생략

53 - SEL$1_4 / L@SEL$1_4

…중간생략

가장 좌측의 번호는 Plan 상의 id에 해당한다. 쿼리블럭명은 ‘/’을 기준으로 좌측이다. SEL$1_1부터 SEL$1_4까지 쿼리블럭명들을 볼 수 있다. 이것들을 힌트에 사용하면 조건절에 OR로 분기된 SQL이 아무리 많아도 원하는 SQL(쿼리블럭)만을 콕 집어서 실행계획을 변경시킬 수 있다.

OR-Expansion VS Union All

이제 OR를 이용한 경우와 Union all을 사용한 경우를 비교해보자. 아래의 SQL은 Union all로 분기한 경우인데 두가지 단점이 있다. 특히 Oracle11g R2를 사용하는 사람은 눈 여겨 보아야 한다. 여기서도 구분자에는 1을 대입한다. 네가지 SQL의 힌트가 서로 다름을 주목하자.

SELECT /*+ leading(j e d l) use_nl(e d l) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND j.job_id = :v_job --> ‘SA_MAN’ 입력

AND d.manager_id > 0

AND :v_delimit = 1 --> 1 입력

UNION ALL

SELECT /*+ leading(e d l j) use_nl(d l j) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND e.manager_id = :v_emp

AND e.hire_date BETWEEN :v_hr_fr AND :v_hr_to

AND d.manager_id > 0

AND :v_delimit = 2

UNION ALL

SELECT /*+ leading(d e l j) use_nl(e l j) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND d.department_id = :v_dept

AND d.manager_id > 0

AND :v_delimit = 3

UNION ALL

SELECT /*+ leading(l d e j) use_nl(d e j) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND l.location_id = :v_loc

AND d.manager_id > 0

AND :v_delimit = 4 ;

단점 1: SQL의 길이가 너무 길다

구분자 별로 OR를 사용할 때보다 SQL이 많이 길어졌다. Union을 사용하는 방법의 단점은 SQL의 길이뿐만이 아니다. Oracle11g R2 에서는 개발자의 의도를 무시하는 결과가 발생할 수 있다. 개발자의 의도란 :v_delimit = 1 인 경우의 SQL만 실행하는 것이다. 즉 :v_delimit의 값이 2~4인 경우는 한 블록도 Scan해서는 안 된다. 과연 그렇게 되는지 아래의 Plan을 보자.

------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 5 |00:00:00.01 | 22 |

| 1 | UNION-ALL | | 1 | 5 |00:00:00.01 | 22 |

|* 2 | FILTER | | 1 | 5 |00:00:00.01 | 20 |

| 3 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 20 |

| 4 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 15 |

| 5 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 13 |

| 6 | NESTED LOOPS | | 1 | 5 |00:00:00.01 | 6 |

| 7 | TABLE ACCESS BY INDEX ROWID | JOB | 1 | 1 |00:00:00.01 | 2 |

|* 8 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | 1 |00:00:00.01 | 1 |

| 9 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 1 | 5 |00:00:00.01 | 4 |

|* 10 | INDEX RANGE SCAN | EMP_JOB_IX | 1 | 5 |00:00:00.01 | 2 |

|* 11 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 5 | 5 |00:00:00.01 | 7 |

|* 12 | INDEX UNIQUE SCAN | DEPT_ID_PK | 5 | 5 |00:00:00.01 | 2 |

|* 13 | INDEX UNIQUE SCAN | LOC_ID_PK | 5 | 5 |00:00:00.01 | 2 |

| 14 | TABLE ACCESS BY INDEX ROWID | LOCATION | 5 | 5 |00:00:00.01 | 5 |

|* 15 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 16 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 17 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 18 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 19 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 20 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

|* 21 | INDEX RANGE SCAN | EMP_MGR_HR_DT_IX | 0 | 0 |00:00:00.01 | 0 |

|* 22 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 23 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 24 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 25 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 26 | INDEX UNIQUE SCAN | JOB_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 27 | TABLE ACCESS BY INDEX ROWID | JOB | 0 | 0 |00:00:00.01 | 0 |

| 28 | MERGE JOIN | | 1 | 0 |00:00:00.01 | 2 |

| 29 | TABLE ACCESS BY INDEX ROWID | JOB | 1 | 1 |00:00:00.01 | 2 |

| 30 | INDEX FULL SCAN | JOB_ID_PK | 1 | 1 |00:00:00.01 | 1 |

|* 31 | SORT JOIN | | 1 | 0 |00:00:00.01 | 0 |

| 32 | VIEW | VW_JF_SET$B71A25AA | 1 | 0 |00:00:00.01 | 0 |

| 33 | UNION-ALL | | 1 | 0 |00:00:00.01 | 0 |

|* 34 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 35 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 36 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

|* 37 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 38 | INDEX UNIQUE SCAN | DEPT_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 39 | TABLE ACCESS BY INDEX ROWID | LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 40 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

| 41 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

|* 42 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 |

|* 43 | FILTER | | 1 | 0 |00:00:00.01 | 0 |

| 44 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 45 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 46 | NESTED LOOPS | | 0 | 0 |00:00:00.01 | 0 |

| 47 | TABLE ACCESS BY INDEX ROWID| LOCATION | 0 | 0 |00:00:00.01 | 0 |

|* 48 | INDEX UNIQUE SCAN | LOC_ID_PK | 0 | 0 |00:00:00.01 | 0 |

|* 49 | TABLE ACCESS BY INDEX ROWID| DEPARTMENT | 0 | 0 |00:00:00.01 | 0 |

|* 50 | INDEX RANGE SCAN | DEPT_LOCATION_IX | 0 | 0 |00:00:00.01 | 0 |

|* 51 | INDEX RANGE SCAN | EMP_DEPT_IX | 0 | 0 |00:00:00.01 | 0 |

| 52 | TABLE ACCESS BY INDEX ROWID | EMPLOYEE | 0 | 0 |00:00:00.01 | 0 |

------------------------------------------------------------------------------------------------------------

단점 2 : 불필요한 쿼리블럭을 Scan 하며 힌트가 무시된다

Join factorization(주1) 이라는 쿼리변환이 발생하여 불필요한 두 블록(Plan의 빨강색 부분)을 Scan 하였다. : v_delimit = 3 인 경우와 :v_delimit = 4인 경우의 SQL이 실행되어 버린 것이다. 확률은 많지 않겠지만 만약 테이블이 대용량이라면 index full scan과 그에 따른 테이블로의 접근은 성능에 치명적일 것이다. 또한 쿼리변환으로 인해 개발자가 작성한 힌트도 무시되어 sort merge join이 발생되었다.

의도하지 않은 쿼리변환을 경계하라
이렇게 다양한 검색조건에서 Union을 사용하는 경우는 11g R2부터 발생되는 Join factorization의 악영향에 주의해야 한다. 왜냐하면 :v_delimit = 1에 해당하는 SQL만 실행되어야 하지만 Join factorization으로 인해 인라인뷰 외부로 빠진 쿼리블럭은 구분자(:v_delimit )의 값에 영향을 받지 않기 때문이다.

그런데 Join factorization을 발생시키지 않을 목적으로 SQL 마다 rownum을 사용하는 사람이 있다. 아래의 SQL이 그것인데 그럴 필요 없다.

SELECT /*+ leading(j e d l) use_nl(e d l) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND j.job_id = :v_job --> 'SA_MAN' 입력

AND d.manager_id > 0

AND ROWNUM > 0

AND :v_delimit = 1 --> 1 입력

UNION ALL

SELECT /*+ leading(e d l j) use_nl(d l j) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND e.manager_id = :v_emp

AND e.hire_date BETWEEN :v_hr_fr AND :v_hr_to

AND d.manager_id > 0

AND ROWNUM > 0

AND :v_delimit = 2

UNION ALL

…중간생략

Rownum을 네 번 사용하면 Join factorization이 방지 되기는 하지만 SQL마다 조건절을 추가해야 하므로 막노동에 가깝고 SQL이 길어진다. 가장 쉬운 방법은 쿼리변환을 방지하는 힌트를 사용하는 것이다. 가장 위쪽 SQL의 힌트에 NO_FACTORIZE_JOIN(@SET$1)을 추가하면 된다. SQL마다 힌트를 추가할 필요는 없다. 아래의 예제를 보자.

SELECT /*+ leading(j e d l) use_nl(e d l) NO_FACTORIZE_JOIN(@SET$1) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

j.job_title, d.department_name, l.city,l.country_id

FROM employee e,

job j,

department d,

location l

WHERE e.job_id = j.job_id

AND e.department_id = d.department_id

AND d.location_id = l.location_id

AND j.job_id = :v_job --> 'SA_MAN' 입력

AND d.manager_id > 0

AND :v_delimit = 1 --> 1 입력

UNION ALL

SELECT /*+ leading(e d l j) use_nl(d l j) */

e.employee_id, e.email, e.phone_number, e.hire_date, e.salary,

…중간생략

위처럼 힌트를 한번만 추가하여 쿼리변환을 방지하면 하면 불필요한 블록을 Scan하지 않으며, 개발자가 작성한 힌트를 무시하지 않는다. Oracle11g R2를 사용한다면 직접 실행계획을 확인해보기 바란다.

결론

동적인 검색조건이 많지 않아 Union all을 사용할 때에도 쿼리변환을 조심해야 한다. 원하지 않는 블록을 Scan할 수 있기 때문이다. 이때 쿼리변환을 방지할 목적으로 Rownum을 사용하는 것은 좋지 않다. 왜냐하면 Join factorization을 막을 수는 있지만 또 다른 쿼리변환인 FPD(주2)와 JPPD(주3)등의 쿼리변환도 같이 막혀버린다. 따라서 NO_FACTORIZE_JOIN 힌트를 사용하는 것이 적절하다.

오라클의 버전이 올라갈수록 쿼리변환의 기능이 많아진다. 하지만 기능이 많아질수록 어두운 측면도 부각된다. 물론 쿼리변환의 문제점은 자주 발생하지는 않으며 예외적인 경우이다. 하지만 그 예외가 발생된다면 위의 SQL처럼 원하지 않을 때도 쿼리변환이 발생하여 문제가 될 것이다. 지금은 CBQT의 태동기이므로 앞으로 문제가 개선될 것으로 기대한다.

검색조건이 동적으로 바뀔 때는OR로 분기하는 방법을 사용하라. 이 방법을 적절히 사용하면 Union all을 사용하는 방법의 단점인 SQL이 길어지는 것을 피할 수 있다. 또한 Dynamic SQL처럼 힌트와 where절을 동적으로 교체할 필요 없이 명시적으로 작성할 수 있다. Where 절에 OR를 사용하는 것이 항상 나쁜 것은 아니며 분명 뭔가 남다른 장점이 있다. 우리는 그 점을 이해해야 한다.

주1: JF(Join factorization)을 간단히 설명하면 Union / Union All 사용시 공통으로 사용하는 테이블을 분리시키는 것이다. 즉 아래와 같이 SQL1이 SQL2로 변경되는 기능이다.

SQL1

SELECT /*+ USE_HASH(c s) */

s.prod_id, s.cust_id, s.quantity_sold,

s.amount_sold, c.channel_desc

FROM sales s, channels c

WHERE c.channel_id = s.channel_id

AND c.channel_id = 3

UNION ALL

SELECT /*+ USE_HASH(c s) */

s.prod_id, s.cust_id, s.quantity_sold,

s.amount_sold, c.channel_desc

FROM sales s, channels c

WHERE c.channel_id = s.channel_id

AND c.channel_id = 9 ;

SQL2

SELECT s.prod_id prod_id, s.cust_id cust_id, s.quantity_sold,

s.amount_sold, vw_jf_set$0a277f6d.item_2 channel_desc

FROM (SELECT c.channel_id AS item_1, c.channel_desc AS item_2

FROM channels c

WHERE c.channel_id = 3

UNION ALL

SELECT c.channel_id AS item_1, c.channel_desc AS item_2

FROM channels c

WHERE c.channel_id = 9) vw_jf_set$0a277f6d, --> JF 가 발생하면 인라인뷰vw_jf ~ 가 생성된다.

sales s --> sales 테이블을 인라인뷰 외부로 분리시킴

WHERE vw_jf_set$0a277f6d.item_1 = s.channel_id ;

주2: FPD(Filter Push Down)는 뷰/인라인뷰 외부의 조건이 뷰 내부로 파고드는 기능이다.

주3: JPPD(Join Predicate Push Down)는 뷰/인라인뷰 외부의 조인조건이 뷰 내부로 파고드는 기능이다. FPD와 JPP의 차이는 FPD는 상수조건이 파고드는 것이며 JPPD는 조인절이 파고든다는 점이다.

참고: JF 와 JPPD는 CBQT(Cost Based Query Transformation)이며 FPD는 HQT(Heuristic Query Transformation)이다. HQT를 Rule Based Query Transformation 이라고 부르기도 한다.

'Oracle > SQL Pattern' 카테고리의 다른 글

Oracle Analytic Function의 모든 것 (20)	2010.03.29
오라클 Regular Expressions 완전정복 (22)	2009.10.07
간단한 집합개념 Test (7)	2009.07.06
스칼라 서브쿼리에서 Multi Column, Multi Row Return 하기. (7)	2009.06.29
Model 절에 대하여 (10)	2009.05.28

Posted by extremedb

,

Index_desc 힌트와 rownum = 1 조합은 안전한가?

Oracle/Data Access Pattern 2010. 11. 9. 00:01

부제 : min/max값을 안전하고 빠르게 구하는 방법

최종일자, 최종순번을 구하기 위한 전통적인 방법은 index desc 힌트와 rownum = 1 조합이었다. 하지만 이것은 대단히 위험한 방법이다. 왜냐하면 튜닝을 하기 전에 값이 맞아야 하며, 성능튜닝은 그 이후의 문제이기 때문이다. 위의 방법은 인덱스의 구성컬럼이 변경 혹은 삭제되거나, 인덱스명이 바뀌면 max 값을 구하지 못한다. 즉 성능을 향상시키기 위해 값이 틀릴 수 있는 가능성을 열어놓은 것이다. 이런 방법은 어떤 이유로도 받아들여져서는 안 된다. 나 또한 예전에 이런 방법을 사용했지만 이는 필자의 명백한 잘못이었다.

올바른 값을 얻어야 하고 성능도 충족해야 하므로 오라클은 first_row(min/max) operation을 내놓았다. 따라서 우리는 index_desc + rownum 대신에 first_row(min/max)을 사용해야 한다. 그런데 항상 first_row(min/max)를 사용해야 할까? first_row(min/max)가 비효율적인 경우는 index_desc + rownum 조합을 생각해 볼 수 있다. 하지만 인덱스가 변경 및 삭제될 때 성능이 느려질지언정 답이 틀리면 안 된다. 만약 max가 아닌 잘못된 값으로 update 되었다고 상상해보라. 큰일이다. 원복시키기도 어렵다. update 가 여러번 되었을 수 있기 때문이다.

환경 :Oracle11g R2

CREATE INDEX ix_cust_channel_time ON SALES (CUST_ID, CHANNEL_ID, TIME_ID) ;

CREATE INDEX ix_cust_time_channel ON SALES (CUST_ID, TIME_ID, CHANNEL_ID) ;
CREATE INDEX ix_time_cust_channel ON SALES (TIME_ID, CUST_ID, CHANNEL_ID) ;

인덱스와 where 조건이 완벽할 때

SELECT /*+ gather_plan_statistics INDEX(s ix_cust_channel_time) */

MAX (time_id)

FROM sales s

WHERE cust_id = :v_cust --30777 대입

AND channel_id = 2;

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.01 | 3 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.01 | 3 |

| 2 | FIRST ROW | | 1 | 1 |00:00:00.01 | 3 |

|* 3 | INDEX RANGE SCAN (MIN/MAX)| IX_CUST_CHANNEL_TIME | 1 | 1 |00:00:00.01 | 3 |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2)

인덱스가 CUST_ID + CHANNEL_ID + TIME_ID로 되어 있는 경우는 문제가 없다. first_row(min/max) operation을 사용할 수 있고 비효율이 없기 때문에 값이 틀려질 수 있는 index_desc + rownum을 사용해선 안 된다.

where 조건에 인덱스의 중간 컬럼이 빠졌을 때

SELECT /*+ gather_plan_statistics INDEX(S IX_CUST_TIME_CHANNEL) */

MAX (time_id)

FROM sales s

WHERE cust_id = :v_cust --30777 대입

AND channel_id = 2;

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.01 | 3 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.01 | 3 |

| 2 | FIRST ROW | | 1 | 1 |00:00:00.01 | 3 |

|* 3 | INDEX RANGE SCAN (MIN/MAX)| IX_CUST_TIME_CHANNEL | 1 | 1 |00:00:00.01 | 3 |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - access("CUST_ID"=:V_CUST)

filter("CHANNEL_ID"=2)

인덱스가 CUST_ID + TIME_ID + CHANNEL_ID 로 되어 있는 경우를 보자. 인덱스의 중간컬럼이 where절에 빠져있지만 CUST_ID의 선택도가 워낙 좋으므로 문제가 되지 않는다. first_row(min/max) operation을 그대로 사용하면 된다.

인덱스의 선두 컬럼이 where 조건에서 빠지는 경우

SELECT /*+ gather_plan_statistics INDEX(S IX_TIME_CUST_CHANNEL) */

MAX (time_id)

FROM sales s

WHERE cust_id = :v_cust --30777 대입

AND channel_id = 2;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.02 | 755 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.02 | 755 |

| 2 | FIRST ROW | | 1 | 1 |00:00:00.02 | 755 |

|* 3 | INDEX FULL SCAN (MIN/MAX)| IX_TIME_CUST_CHANNEL | 1 | 1 |00:00:00.02 | 755 |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter(("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2))

인덱스가 TIME_ID + CUST_ID + CHANNEL_ID로 구성되어 있을때 인덱스의 선두 컬럼이 where 조건에서 빠졌다. 그로 인해 Index full scan이 발생하여 쓸모 없는 752블록을 Scan하였다. 즉 인덱스를 끝부분부터 계속 scan하다가 운 좋게 755 블록을 scan해보니 cust_id = 30777 와 channel_id = 2을 만족하는 값을 모두 처리한 것이다. 운이 나쁘면 인덱스를 모조리 읽어야 할 수도 있다.

서브쿼리나 인라인뷰를 이용하여 집합을 추가하자는 의견에 대해

인덱스의 선두 컬럼이 where 조건에서 빠지는 경우는 강제로 집합을 추가하자는 의견이 있다. 아래의 SQL이 그것이다.

SELECT TIME_ID

FROM ( SELECT /*+ LEADING(C) INDEX_DESC(S IX_TIME_CUST_CHANNEL) */ S.time_id

FROM sales S,

(SELECT TRUNC(SYSDATE) - LEVEL + 1 AS time_id

FROM DUAL

CONNECT BY LEVEL <= 7300 ) C

WHERE S.cust_id = :v_cust --30777

AND S.channel_id = 2

AND S.time_id = C.time_id )

WHERE ROWNUM = 1;

---------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.02 | 512 |

|* 1 | COUNT STOPKEY | | 1 | 1 |00:00:00.02 | 512 |

| 2 | NESTED LOOPS | | 1 | 1 |00:00:00.02 | 512 |

| 3 | VIEW | | 1 | 3484 |00:00:00.02 | 0 |

| 4 | CONNECT BY WITHOUT FILTERING| | 1 | 3484 |00:00:00.01 | 0 |

| 5 | FAST DUAL | | 1 | 1 |00:00:00.01 | 0 |

|* 6 | INDEX RANGE SCAN DESCENDING | IX_TIME_CUST_CHANNEL | 3484 | 1 |00:00:00.01 | 512 |

---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM=1)

6 - access("S"."TIME_ID"=INTERNAL_FUNCTION("C"."TIME_ID") AND "S"."CUST_ID"=:V_CUST AND

"S"."CHANNEL_ID"=2)

이렇게 하니 Scan한 블럭수가 1/3 정도 줄어들었다. 하지만 불필요한 조인이 3484번이나 발생하였다. 이것이 최적은 아니다. 또한 명시적으로 max값을 보장하게 작성된 SQL도 아니다.

Index_ss 힌트를 사용했다. 하지만……

위의 예에서 보듯이 인덱스의 선두 컬럼이 조건절에 없을때 이빨이 빠진 집합을 추가하는 것과 first_row(min/max)를 사용하는 것은 둘다 비효율적이다. 그러므로 index_desc + rownum을 사용하되 값이 바뀌지 않도록 해야 한다. 그런데 인덱스의 첫 번째 컬럼이 조건 절에서 빠졌으므로 index_ss_desc + rownum을 사용해야 한다. 이것이 가능할까? SQL을 바꾸지 않으면 불가능하다. 아래의 SQL을 보자.

SELECT /*+ gather_plan_statistics INDEX_SS(s ix_time_cust_channel) */

MAX (time_id)

FROM sales s

WHERE cust_id = :v_cust --30777

AND channel_id = 2;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.02 | 755 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.02 | 755 |

| 2 | FIRST ROW | | 1 | 1 |00:00:00.02 | 755 |

|* 3 | INDEX FULL SCAN (MIN/MAX)| IX_TIME_CUST_CHANNEL | 1 | 1 |00:00:00.02 | 755 |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter(("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2))

Min/Max와 Index Skip Scan을 동시에 사용할 수 없다

min 혹은 max 함수를 사용했을 때 Oracle9i 버전과는 달리 10g와 11g에서는 index skip scan을 사용할 수 없다. 힌트를 추가해도 마찬가지이다. 아래의 10053 trace를 보자.

***************************************

SINGLE TABLE ACCESS PATH

Single Table Cardinality Estimation for SALES[S]

ColGroup (#1, Index) IX_TIME_CUST_CHANNEL

Col#: 2 3 4 CorStregth: 185.95

ColGroup Usage:: PredCnt: 2 Matches Full: Partial:

Table: SALES Alias: S

Card: Original: 918843.000000 Rounded: 33 Computed: 32.54 Non Adjusted: 32.54

kkofmx: index filter:"S"."CUST_ID"=:B1

kkofmx: index filter:"S"."CHANNEL_ID"=2

Access Path: index (Min/Max)

Index: IX_TIME_CUST_CHANNEL

resc_io: 3.00 resc_cpu: 21564

ix_sel: 1.000000 ix_sel_with_filters: 0.000035

***** Logdef predicate Adjustment ******

Final IO cst 0.00 , CPU cst 50.00

***** End Logdef Adjustment ******

***** Logdef predicate Adjustment ******

Final IO cst 0.00 , CPU cst 50.01

***** End Logdef Adjustment ******

Cost: 5.28 Resp: 5.28 Degree: 1

Best:: AccessPath: IndexRange

Index: IX_TIME_CUST_CHANNEL

Cost: 5.28 Degree: 1 Resp: 5.28 Card: 1.00 Bytes: 0

***************************************

힌트를 사용했지만 Index Skip Scan은 고려조차 되지 않는다. 위의 Trace를 보면 "first row(Min/Max)가 가능하다면 Index Skip Scan을 고려하지 않는 로직이 10g와 11g의 옵티마이져에 존재한다” 라고 추론할 수 있다. 인덱스와 where 절이 일치하지 않는 상태라 하더라도 비효율적인 index full scan (Min/Max)에 만족할 수는 없다. 바로 이럴 때 index_desc 와 rownum 조합을 답이 틀려질 수 없도록 사용하면 된다.

아래처럼 max 함수를 제거하면 Index Skip Scan을 사용할 수는 있다.

SELECT /*+ INDEX_SS_DESC(S IX_TIME_CUST_CHANNEL) */

time_id

FROM sales s

WHERE cust_id = :v_cust --30777

AND channel_id = 2

AND ROWNUM = 1;

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.01 | 264 |

|* 1 | COUNT STOPKEY | | 1 | 1 |00:00:00.01 | 264 |

|* 2 | INDEX SKIP SCAN DESCENDING| IX_TIME_CUST_CHANNEL | 1 | 1 |00:00:00.01 | 264 |

-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM=1)

2 - access("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2)

filter(("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2))

Max를 없애면 index skip scan을 사용할 수 있다. 하지만.....
블록수가 755에서 264로 1/3으로 줄어들었다. 하지만 인덱스가 수정 및 삭제되면 답이 틀릴 수 있으므로 위험하긴 마찬가지 이다. 따라서 다음의 SQL처럼 사용해야 한다.

안정적이고 성능을 고려한 SQL

SELECT MAX(time_id)

FROM ( SELECT /*+ INDEX_SS_DESC(S IX_TIME_CUST_CHANNEL) */ time_id

FROM sales S

WHERE cust_id = :v_cust --30777

AND channel_id = 2

ORDER BY time_id DESC)

WHERE ROWNUM = 1;

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 1 |00:00:00.01 | 264 |

| 1 | SORT AGGREGATE | | 1 | 1 |00:00:00.01 | 264 |

|* 2 | COUNT STOPKEY | | 1 | 1 |00:00:00.01 | 264 |

| 3 | VIEW | | 1 | 1 |00:00:00.01 | 264 |

|* 4 | INDEX SKIP SCAN DESCENDING| IX_TIME_CUST_CHANNEL | 1 | 1 |00:00:00.01 | 264 |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter(ROWNUM=1)

4 - access("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2)

filter(("CUST_ID"=:V_CUST AND "CHANNEL_ID"=2))

ORDER BY를 사용했지만 인덱스의 영향으로 SORT를 하지 않으므로 성능저하도 없다. 또한 인라인뷰 내에서 ORDER BY를 사용하고 외부에서 ROWNUM을 사용했기 때문에 인덱스가 수정 및 삭제되더라도 성능이 느려질 뿐 값이 틀려질 수는 없다. 위의 SQL에서 마지막에 max 함수를 사용한 이유는 where조건에 만족하는 건수가 없더라도 null을 출력해야하기 때문이다. 앞으로 index_desc + rownum 조합을 사용할 것이라면 위의 방법을 사용하길 바란다.

결론

1. Index_desc + rownum을 사용하지 말고 first_row(min/max)를 사용하라

2. 1번이 비효율적인 경우에만 index_desc(혹은 index_ss_desc) + order by를 사용하고 뷰로 감싸라.
그리고 뷰 외부에서 rownum을 사용하라.

3. first_row(min/max)를 사용할 수 있는 환경에서는 index skip scan을 사용할 수 없다. 꼭 사용하려면 집계 함수를 제거하라.

이렇게 하면 성능과 안정성을 동시에 고려할 수 있다.

글의 배경
이런 이야기를 하는 이유는 비판적 사고의 필요성 때문이다. 개발자에게 인라인뷰와 Order by가 없는 Index_desc + Rownum의 위험성을 설명해주었더니 나에게 책을 가져온다. 나는 본적이 없지만 아주 좋은 SQL 튜닝 책이라고 한다. 그것도 어려운 영문 책이다. 열심히 공부하는 사람임에 틀림없다. 하지만 개발자의 한마디 때문에 그사람의 인상이 바뀌어 버렸다. 그 한마디는 “이 책에 Index_desc + Rownum을 사용하라고 되어있습니다.” 였다. 그것이 얼마나 위험한 것인지 여러번 증명하고 설득해 보았으나 맘을 바꾸기는 불가능 하였다. 이래서는 곤란하다. 책을 성경이나 불경처럼 여기고, 저자를 종교의 교주로 여겨서는 안 된다. 이론은 반론이 증명되면 폐기될 수 있다. 하지만 가치관이 개입된 믿음이나 신념은 좀처럼 바뀌지 않는다. 어떠한 증거를 내놓아도 그렇다. 신념은 종교생활에 사용했으면 한다.

책의 내용 중에 잘못된 것이 있으니 나쁜 책이라고 말하는게 아니다. 필자의 서적을 포함해서 모든 책의 내용은 틀릴 수 있다. 정작 나쁜 것은 책이나 저자가 종교화될 때이다. 그런 무 비판적 종교는 이공계 사람에게 치명적이다. 비판적 사고는 엔지니어와 과학자의 버팀목이자 과학기술을 발전시키는 핵심이기 때문이다. 널리 알려진 과학 논쟁인 쿤과 포퍼의 대결에서도 이러한 언급은 드러난다. 두명 모두 비판적 사고는 반드시 필요하다고 하였다. 다만 시기의 문제일 뿐이다.

답답한 마음에 글을 올려보았다. 앞으로 이런 글을 다시 쓰고 싶지 않다.

"신앙은 믿음으로 이루져야한다. 하지만 과학은 비판과 증명으로 이루어져야 한다."

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 실행계획 - 2부 (12)	2011.02.10
분석함수의 실행계획 - 1부 (12)	2011.02.07
Bloom Filter와 Group By의 관계 (10)	2010.09.09
Inlist Iterator를 사용하지 말아야 할 때 (13)	2010.06.23
오렌지나 TOAD에서 Predicate Information을 참조하는 방법 (7)	2010.01.12

Posted by extremedb

,

Cardinality Feedback이 위험할 때

Oracle/Optimizer 2010. 10. 25. 00:01

부제: Cardinality Feed Back의 개념과 사용예제

이번 글은 난이도가 높으므로 익숙하지 않은 사람은 Cardinality Feedback의 개념 정도만 이해하기 바란다. 물론 이 블로그를 꾸준히 구독한 독자라면 어려움 없이 볼 수 있다.

현재 많은 시스템이 Oracle11g로 옮겨가고 있다. 11g는 새로운 기능이 많이 추가되었다. 하지만 새롭고 좋은 기능이라도 완벽하지 못하면 문제가 될 수 있다. 오늘은 11g의 새 기능 때문에 성능문제가 발생하는 경우를 소개한다.

시스템이 운영 중에 있을 때 가장 곤욕스러운 경우 중 하나는 SQL의 실행계획이 갑자기 바뀌어 성능이 나빠지는 것이다. SQL과 인덱스 그리고 통계정보가 모두 바뀌지 않아도 실행계획은 바뀔 수 있다. 예를 들면 Oracle11g의 기능인 Cardinality Feedback을 사용함으로 해서 얼마든지 실행계획이 바뀔 수 있는 것이다. 이번 시간에는 실행계획이 변경되는 원인 중 하나인 Cardinality Feedback 의 개념과 작동방식에 대해 알아보고 이것이 언제 문제가 되는지 분석해 보자. 이번에 소개할 예제는 종합적이다. Cardinality Feedback + Cost Based Query Transformation + Bloom Filter가 결합된 것이다. 이를 놓친다면 이들이 어떻게 결합되는지 알 수 없을 뿐만 아니라 성능이 악화된 원인을 파악할 수 없다.

예측, 실행, 비교, 그리고 전달

소 잃고 외양간 고친다는 말이 있다. 이미 늦었다는 이야기 이지만 좋은 말로 바꾸면 실수를 다시 하지 않겠다는 의지이다. cardinality feedback(이후 CF)도 이와 비슷한 개념이다. 예를 들어 col1 = ‘1’ 이라는 조건으로 filter되면 백만 건이 return된다고 옵티마이져가 예측해서 full table scan을 했다. 하지만 예측과 달리 실행결과가 100건이 나왔다면? 해당 SQL을 다시 실행할 때는 full table scan보다는 index scan이 유리할 것이다. 그런데 같은 SQL을 두 번째 실행할 때 "실제로는 백만 건이 아니라 100건 뿐이야"라는 정보를 옵티마이져에게 알려주는 전달자가 필요하다. 그 전달자가 바로 CF이다. CF가 없으면 결과가 100건 임에도 SQL을 실행 할 때마다 full table scan을 반복할 것이다. 결국 CF는 악성 실행계획을 올바로 수정하는 것이 목적이며 매우 유용한 기능임을 알 수 있다. CF의 단점은 최초에 한번은 full table scan이 필요하다는 것이다. 왜냐하면 실행해서 결과가 나와야만 실제 분포도(건수)를 알 수 있기 때문이다.

CF는 어떻게 실행되나?

CF는 같은 SQL을 두 번 이상 실행했을 때 적용된다. 그 이유는 아래의 CF 적용순서를 보면 알 수 있다.

1. 최초의 실행계획을 작성할 때(Hard Parsing 시에) 예측 분포도가 계산된다.

2. SQL이 실행된다. 한번은 실행 해봐야 예측 분포도와 실제 분포도를 비교할 수 있다.

3. 예측 분포도와 실제 분포도의 값이 차이가 크다면 실제 분포도를 저장한다.

4. 두 번째 실행될 때 CF에 의해 힌트의 형태로 옵티마이져에게 전달되어 실제 분포도가 적용된다. 이때 분포도뿐만 아니라 실행계획이 바뀔 수 있다. 두 번째 이후로 실행될 때는 CF가 계속 적용된다.

CF를 발생시켜보자

실행환경 :Oracle 11.2.0.1

ALTER SYSTEM FLUSH SHARED_POOL;

ALTER SESSION SET "_OPTIMIZER_USE_FEEDBACK" = TRUE; -- CF를 활성화 한다. default로 true이다.

SELECT /*+ GATHER_PLAN_STATISTICS LEADING(c) */

c.cust_id, c.cust_first_name, c.cust_last_name,

s.prod_cnt, s.channel_cnt, s.tot_amt

FROM customers c,

(SELECT s.cust_id,

COUNT (DISTINCT s.prod_id) AS prod_cnt,

COUNT (DISTINCT s.channel_id) AS channel_cnt,

SUM (s.amount_sold) AS tot_amt

FROM sales s

GROUP BY s.cust_id) s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id ;

----------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | | 23 |00:00:00.15 | 5075 | |

|* 1 | HASH JOIN | | 162 | 23 |00:00:00.15 | 5075 | 1215K (0)|

| 2 | JOIN FILTER CREATE | :BF0000 | 162 | 151 |00:00:00.01 | 148 | |

| 3 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 162 | 151 |00:00:00.01 | 148 | |

| 4 | BITMAP CONVERSION TO ROWIDS| | | 151 |00:00:00.01 | 2 | |

|* 5 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | | 1 |00:00:00.01 | 2 | |

| 6 | VIEW | | 7059 | 55 |00:00:00.15 | 4927 | |

| 7 | SORT GROUP BY | | 7059 | 55 |00:00:00.15 | 4927 |88064 (0)|

| 8 | JOIN FILTER USE | :BF0000 | 918K| 7979 |00:00:00.12 | 4927 | |

| 9 | PARTITION RANGE ALL | | 918K| 7979 |00:00:00.11 | 4927 | |

|* 10 | TABLE ACCESS FULL | SALES | 918K| 7979 |00:00:00.09 | 4927 | |

----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("S"."CUST_ID"="C"."CUST_ID")

5 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

10 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"S"."CUST_ID")) --> Bloom Filter 적용

SQL 실행결과 sales 테이블의 예측 분포도는 918K건이며 실제 분포도는 Bloom Filter가 적용되어 7979건이다. 그리고 group by된 operation(ID 7번)의 예측 분포도는 7059건이며 실제 분포도는 55건이다. 예측과 실제의 분포도 차이는 두 경우 모두 100배 이상이다. 따라서 CF가 적용될 것이다. 이와는 반대로 customers 테이블의 예측 분포도와 실제 분포도는 162와 152로 크게 다르지 않으므로 CF가 적용되지 않을 것이다. 이제 위의 SQL을 재 실행한다면 CF가 적용되어 실제 분포도가 적용될 것이다.

--> CF를 발생시키기 위해 위의 SQL 다시 실행

----------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | | 23 |00:00:05.61 | 5075 | |

| 1 | SORT GROUP BY | | 55 | 23 |00:00:05.61 | 5075 |75776 (0)|

|* 2 | HASH JOIN | | 270 | 3230 |00:00:05.60 | 5075 | 1201K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 162 | 151 |00:00:00.01 | 148 | |

| 4 | BITMAP CONVERSION TO ROWIDS| | | 151 |00:00:00.01 | 2 | |

|* 5 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | | 1 |00:00:00.01 | 2 | |

| 6 | PARTITION RANGE ALL | | 7979 | 918K|00:00:02.82 | 4927 | |

| 7 | TABLE ACCESS FULL | SALES | 7979 | 918K|00:00:00.98 | 4927 | |

----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("S"."CUST_ID"="C"."CUST_ID")

5 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

Note

-----

- cardinality feedback used for this statement --> CF가 발생되었음을 나타냄.

두 번째 실행 할 때 CF가 적용되어 예측 분포도가 7979로 바뀌었고 group by 분포도는 55건으로 바뀌었다. 이에 따라 실행계획도 바뀌었다. 즉 CF에 의해서 쿼리변환(Complex View Merging)이 발생된 것이다. 그리고 note에 CF가 적용되었다고 친절히 설명된다.

이제 더 자세한 분석을 위하여 10053 Trace의 내용을 보자. 두 번째 실행된 SQL의 10053 Trace에 따르면 쿼리변환전의 SQL은 다음과 같다.

SELECT /*+ LEADING (C) */

c.cust_id, c.cust_first_name, c.cust_last_name,

s.prod_cnt, s.channel_cnt, s.tot_amt tot_amt

FROM tlo.customers c,

(SELECT /*+ OPT_ESTIMATE (GROUP_BY ROWS=55.000000 ) OPT_ESTIMATE (TABLE S ROWS=7979.000000 ) */

s.cust_id cust_id, COUNT (DISTINCT s.prod_id) prod_cnt,

COUNT (DISTINCT s.channel_id) channel_cnt, SUM (s.amount_sold) tot_amt

FROM tlo.sales s

GROUP BY s.cust_id) s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id ;

CF에 의해서 OPT_ESTIMATE 힌트가 적용되었다. 실제 건수로 적용하는 것이므로 일견 문제가 없어 보인다. 하지만 쿼리변환과정(Complex View Merging)을 거치면 문제가 생긴다. 10053 Trace에서 나타난 쿼리변환 후의 SQL은 다음과 같다.

SELECT /*+ OPT_ESTIMATE (GROUP_BY ROWS=55.000000 ) LEADING (C) OPT_ESTIMATE (TABLE S ROWS=7979.000000 ) */

c.cust_id cust_id, c.cust_first_name cust_first_name,

c.cust_last_name cust_last_name, COUNT (DISTINCT s.prod_id) prod_cnt,

COUNT (DISTINCT s.channel_id) channel_cnt, SUM (s.amount_sold) tot_amt

FROM tlo.customers c, tlo.sales s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id

GROUP BY s.cust_id, c.ROWID, c.cust_last_name, c.cust_first_name, c.cust_id ;

CF의 문제점은?

위의 SQL은 두 가지 문제점이 있다. 두 문제 모두 쿼리변환에 의해 발생된다. 첫 번째 문제는 Bloom Filter와 관련된 것이다. CF의 영향으로 원본 SQL에 존재했던 Group By 뷰(Complex View)가 사라졌다. 뷰가 없어짐으로써 Bloom Filter가 적용되지 않는다. Filter가 사라졌음에도 불구하고 Filter가 존재했던 Cardinality 7979를 적용해 버렸다. 이에 따라 CF를 적용했음에도 7979건과 실제건수인 91만 8천 건과는 엄청난 차이가 나고 말았다. 즉 Bloom Filter가 사라질 때는 CF를 적용하면 안 된다는 이야기이다. 비유하자면 Filter가 없는데도 불구하고 Filter가 존재할 때의 건수를 적용시킨 것이다.

두 번째 문제는 쿼리변환 후 힌트의 상속과 관련된다. 쿼리변환전의 CF의 의한 힌트를 보면 Group By된 뷰의 건수는 55건이다. 그런데 이 힌트는 오직 sales 테이블에 대한 것이다. 그런데 쿼리변환후의 힌트를 보면 그대로 55건이 적용되어 되어버렸다. Group by가 외부로 빠져 나옴으로 해서 GROUP_BY ROWS는 전체건수와 마찬가지가 되어버렸다. sales 테이블의 Group By건수는 55건이 맞다. 하지만 쿼리변환 때문에 조인 후에 Group By 하게 된다면 cardinality를 다시 계산해야 한다. 조인이 없는 테이블의 Group By건수와 조인후의 Group By건수가 어떻게 같을 수 있나?

두 가지의 문제점은 Cost를 계산할 때 그대로 적용되어 버린다. 10053 trace를 보자.

Access path analysis for SALES

***************************************

SINGLE TABLE ACCESS PATH

Single Table Cardinality Estimation for SALES[S]

Table: SALES Alias: S

Card: Original: 918843.000000 >> Single Tab Card adjusted from:918843.000000 to:7979.000000

Rounded: 7979 Computed: 7979.00 Non Adjusted: 918843.00

Access Path: TableScan

Cost: 1328.68 Resp: 1328.68 Degree: 0

Cost_io: 1321.00 Cost_cpu: 155262306

Resp_io: 1321.00 Resp_cpu: 155262306

Bloom Filter가 없음에도 불구하고 Sales 테이블의 건수(Cardinality)가 7979로 적용되어 버렸다. 이제 Group By가 적용된 건수를 보자.

GROUP BY cardinality: 270.000000, TABLE cardinality: 270.000000

>> Query Blk Card adjusted from 270.000000 to: 55.000000

SORT ressource Sort statistics

Sort width: 583 Area size: 510976 Max Area size: 102340608

Degree: 1

Blocks to Sort: 3 Row size: 69 Total Rows: 270

Initial runs: 1 Merge passes: 0 IO Cost / pass: 0

Total IO sort cost: 0 Total CPU sort cost: 20302068

Total Temp space used: 0

Group By Cardinality와 관련된 Trace 내용이다. 여기서도 잘못된 Group By건수인 55를 적용시키고 있다. 조인 후에 Group By할 때는 Cardinality를 다시 계산해야 옳다. 이래서는 제대로 된 Cost가 나올 수 없다. 여기에 밝혀진 문제점은 SQL 하나에서 나온 것이므로 실전에서는 두 가지 문제뿐만 아니라 더 많을 것이다. 물론 옵티마이져가 모든 경우에 완벽할 수는 없다.

해결책
CF 문제의 해결방법을 생각해보자. 갑자기 실행계획이 바뀌어 성능문제가 발생했을 때 dbms_xplan.display_cursor의 note나 10053 Trace의 실행계획 부분을 보면 CF가 적용되었는지 아닌지 알 수 있다. 만약 CF가 적용되었다면 일단 의심해보아야 한다. 아래는 10053 trace의 실행계획 부분이다.

-----------------------------------------------------------+------------------------

-----------------------------------------------------------+------------------------

| 0 | SELECT STATEMENT | | | | 1368 |

| 1 | SORT GROUP BY | | 55 | 2915 | 1368 |

| 2 | HASH JOIN | | 270 | 14K | 1367 |

| 3 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 162 | 5832 | 38 |

| 4 | BITMAP CONVERSION TO ROWIDS | | | | |

| 6 | PARTITION RANGE ALL | | 7979 | 132K | 1329 |

| 7 | TABLE ACCESS FULL | SALES | 7979 | 132K | 1329 |

-----------------------------------------------------------+------------------------

Predicate Information:

----------------------

2 - access("S"."CUST_ID"="C"."CUST_ID")

5 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

Content of other_xml column

===========================

nodeid/pflags: 7 17nodeid/pflags: 6 17 cardinality_feedback: yes --> CF가 적용됨

...이후 생략

만약 CF가 문제가 된다면 해당 SQL을 시작하기 전에 세션단위로 _optimizer_use_feedback = false를 적용하거나 opt_param 힌트를 사용하면 된다. 이렇게 하면 CF가 방지되어 쿼리변환의 원인이 제거된다. 따라서 Bloom Filter도 보존할 수 있다. 또 다른 방법은 인라인뷰에 no_merge 힌트를 적용하여 쿼리변환을 방지하면 문제는 해결된다. 이 두 가지 방법은 결국 쿼리변환을 방지하는 것이다.

결론

CF란 건수를 예측하고, 실행해서 실제건수와 예측건수를 비교하여 차이가 많다면 다음 번에 실행할 때 옵티마이져에게 실제건수를 전달해주는 역할을 한다. CF의 개념을 정리 했으므로 이제 큰 그림을 그려보자. 위의 예제에서 성능이 악화된 직접적인 이유는 Bloom Filter가 사라졌기 때문이다. 하지만 그렇게 된 이유는 쿼리변환 때문이며 쿼리변환의 이유는 CF 때문이다. 직접적인 원인을 찾았다고 해도 포기해선 안 된다. 꼬리에 꼬리를 무는 원인이 있을 수 있기 때문이다. 이를 도식화 하면 다음과 같다.

옵티마이져의 설계관점에서 개선해야 될 사항을 논의 해보자. 옵티마이져가 CBQT를 고려할 때는 두 가지의 경우로 판단한다. 쿼리변환을 적용하기 전(Iteration 1)의 Cost와 적용 후(Iteration 2)의 Cost를 비교해야 되기 때문이다. 쿼리변환전의 Cost를 구할 때는 CF를 적용시키고 반대로 쿼리변환 후에는 CF를 적용하지 않는 것이 더 좋은 Cost를 구할 수 있다. 왜냐하면 비록 답이 같다고 하더라도 형태가 전혀 다른 SQL에 대해 CF를 적용시킬 이유는 없기 때문이다. 물론 이렇게 해도 여전히 문제가 될 수는 있다. 하지만 문제의 발생확률은 많이 줄어들지 않겠는가?

'Oracle > Optimizer' 카테고리의 다른 글

COUNT(Distinct 컬럼)의 성능 (9)	2013.05.06
공지 - Cardinality Feed Back이 위험할 때 (1)	2010.10.22
union과 union all의 숨겨진 차이점 (6)	2010.10.18
메트릭스나 터미네이터는 먼 미래의 이야기 인가? (2)	2010.04.28
해결사 되기 (15)	2010.02.04

Posted by extremedb

,

공지 - Cardinality Feed Back이 위험할 때

Oracle/Optimizer 2010. 10. 22. 17:11

블로그가 일주일에 한번만 업데이트 되기 때문에 많은 분들이 어떤 내용이 블로그에 올라올지 궁금해 하시는것 같습니다. 그래서 시간이 허락한다면 블로그에 올라갈 내용을 미리 공지 하겠습니다.

제목: Cardinality Feed Back이 위험할 때

부제목: Cardinality Feed Back의 개념과 사용예제

문서의 목적
1. Oracle11의 새 기능인 Cardinality Feedback의 개념을 알아보고 실행예제를 분석해본다.
2. Cardinality Feedback이 문제가 되는 경우를 살펴보고 해결방법을 제시한다.

목차
1. 서론
2. Cardinality Feedback의 개념: 소제목 예측, 실행, 비교, 그리고 전달 부분
3. Cardinality Feedback의 작동방법: 소제목 CF는 어떻게 실행되나? 부분
4. Cardinality Feedback의 실행예제: 소제목 CF를 발생시켜보자 부분
5. Cardinality Feedback의 문제점: 소제목 CF의 문제점은? 부분
6. 문제의 해결방법: 소제목 해결책 부분
7. 결론

분석도구
1. 10053 Trace
2. DBMS_XPLAN.display_cursor

참조문서
Closing the Query Processing Loop in Oracle 11g - Allison Lee, Mohamed Zait

예상발행일자
2010.10.25 일

주의사항: 블로그 내용은 예고없이 변경될 수 있습니다.

많이 기대해주세요.

'Oracle > Optimizer' 카테고리의 다른 글

COUNT(Distinct 컬럼)의 성능 (9)	2013.05.06
Cardinality Feedback이 위험할 때 (10)	2010.10.25
union과 union all의 숨겨진 차이점 (6)	2010.10.18
메트릭스나 터미네이터는 먼 미래의 이야기 인가? (2)	2010.04.28
해결사 되기 (15)	2010.02.04

Posted by extremedb

,

union과 union all의 숨겨진 차이점

Oracle/Optimizer 2010. 10. 18. 00:01

부제목: view에서 union, minus, intersect를 제거하라

많은 사람들이 union과 union all의 차이점에 대해 알고 있다. 즉 union은 Sort와 중복제거라는 기능으로 인해 UNION ALL에 비하여 성능이 떨어진다는 것이다. 옳은 말이다. 하지만 union대신에 union all을 써야 하는 또 다른 이유가 있다는 것을 아는 사람은 얼마나 될까? 이 사실을 알지 못하면 불필요한 엑세스가 추가될 수 있으므로 성능이 저하된다.

먼저 고객테이블을 이용하여 뷰를 하나 만들고 그것을 이용한 SQL문을 만들어 보자.
환경 : Oracle 11.2.0.1

create or replace view vw_cust5 as
select *
from customers
union --> union을 사용함
select *
from customers;

select a.cust_id,
   b.prod_id,
   b.time_id,
   b.channel_id,
   b.quantity_sold
from vw_cust5 a,
   sales b
where a.cust_id = b.cust_id
   and a.cust_id = 14865 ;

뷰에서 사용하는 컬럼은 a.cust_id 하나 뿐이다. 따라서 고객 테이블에 PK인덱스를 사용한다면 customers 테이블로 엑세스 하지 않아도 된다. 하지만 아래의 실행계획을 본다면 문제를 발견할 수 있다.

-------------------------------------------------------------+----------------
| Id | Operation    | Name    | Rows | Cost |
-------------------------------------------------------------+----------------
| 0 | SELECT STATEMENT | | |    62 |
| 1 | HASH JOIN | | 260 |    62 |
| 2 | VIEW | VW_CUST5    | 2 | 6 |
| 3 |    SORT UNIQUE | | 2 | 6 |
| 4 | UNION-ALL    | | | |
| 5 |    TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 1 | 2 |
| 6 | INDEX UNIQUE SCAN    | CUSTOMERS_PK | 1 | 1 |
| 7 |    TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 1 | 2 |
| 8 | INDEX UNIQUE SCAN    | CUSTOMERS_PK | 1 | 1 |
| 9 | PARTITION RANGE ALL    | | 130 |    56 |
| 10 |    TABLE ACCESS BY LOCAL INDEX ROWID | SALES | 130 |    56 |
| 11 | BITMAP CONVERSION TO ROWIDS    | | | |
| 12 |    BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX| | |
-------------------------------------------------------------+----------------

PK 인덱스를 사용하였지만 customers 테이블로 불필요한 엑세스를 하였다. 이유가 무엇일까? 10053 trace를 보자.

Final query after transformations:******* UNPARSED QUERY IS *******

SELECT "A"."CUST_ID" "CUST_ID","B"."PROD_ID" "PROD_ID","B"."TIME_ID" "TIME_ID","B"."CHANNEL_ID" "CHANNEL_ID","B"."QUANTITY_SOLD" "QUANTITY_SOLD" FROM ( (SELECT "CUSTOMERS"."CUST_ID" "CUST_ID","CUSTOMERS"."CUST_FIRST_NAME" "CUST_FIRST_NAME","CUSTOMERS"."CUST_LAST_NAME"
…중간생략
"CUST_TOTAL_ID","CUSTOMERS"."CUST_SRC_ID" "CUST_SRC_ID","CUSTOMERS"."CUST_EFF_FROM" "CUST_EFF_FROM","CUSTOMERS"."CUST_EFF_TO" "CUST_EFF_TO" FROM "TLO"."CUSTOMERS" "CUSTOMERS" WHERE "CUSTOMERS"."CUST_ID"=14865 AND "CUSTOMERS"."CUST_ID"=14865)UNION (SELECT "CUSTOMERS"."CUST_ID" "CUST_ID","CUSTOMERS"."CUST_FIRST_NAME" "CUST_FIRST_NAME","CUSTOMERS"."CUST_LAST_NAME"
…중간생략
"CUST_TOTAL_ID","CUSTOMERS"."CUST_SRC_ID" "CUST_SRC_ID","CUSTOMERS"."CUST_EFF_FROM" "CUST_EFF_FROM","CUSTOMERS"."CUST_EFF_TO" "CUST_EFF_TO" FROM "TLO"."CUSTOMERS" "CUSTOMERS" WHERE "CUSTOMERS"."CUST_ID"=14865 AND "CUSTOMERS"."CUST_ID"=14865)) "A","TLO"."SALES" "B" WHERE "A"."CUST_ID"="B"."CUST_ID" AND "B"."CUST_ID"=14865

위의 trace는 쿼리변환을 끝낸 상태의 SQL이다. 그런데 SQL을 자세히 보면 뷰 내부의 모든 컬럼을 select 하고 있다. 다시 말해 뷰 내부의 컬럼중에 cust_id만 존재하면 되는데, 나머지 컬럼이 삭제되지 않고 남아있다. 이것 때문에 불필요한 테이블 엑세스가 나타난 것이다.

union 대신에 union all을 사용해보자

테스트를 위하여 100건 짜리 고객테이블을 만들고 unique 인덱스를 만들어 보자.

create table customers_100 as
select *
from customers
where rownum < 101;

create unique index PK_CUSTOMERS_100 on customers_100 (cust_id);

이제 union 대신에 union all로 뷰를 생성하여 테스트한다.

create or replace view vw_cust2 as
select *
from customers
UNION ALL
select *
from customers_100 ;

SELECT a.cust_id,
   b.prod_id,
   b.time_id,
   b.channel_id,
   b.quantity_sold
FROM vw_cust2 a,
   sales b
WHERE a.cust_id = b.cust_id
   AND a.cust_id = 14865 ;

---------------------------------------------------------------+----------------
| Id | Operation    | Name    | Rows | Cost |
---------------------------------------------------------------+----------------
| 0 | SELECT STATEMENT | | |    57 |
| 1 | HASH JOIN | | 260 |    57 |
| 2 | VIEW | VW_CUST2    | 2 | 1 |
| 3 |    UNION-ALL | | | |
| 4 | INDEX UNIQUE SCAN    | CUSTOMERS_PK    | 1 | 1 |
| 5 | INDEX UNIQUE SCAN    | PK_CUSTOMERS_100| 1 | 0 |
| 6 | PARTITION RANGE ALL    | | 130 |    56 |
| 7 |    TABLE ACCESS BY LOCAL INDEX ROWID | SALES | 130 |    56 |
| 8 | BITMAP CONVERSION TO ROWIDS    | | | |
| 9 |    BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX | | |
---------------------------------------------------------------+----------------

SLP란 무엇인가?

실행계획에서 보듯이 union all 을 사용하니 테이블 엑세스가 사라졌다. 이것은 SLP(Select List Pruning)라는 쿼리변환의 기능 때문에 가능한 것이다. SLP는 union all이 들어있는 뷰를 사용할 때 발생하며 뷰의 컬럼중에 사용하지 않는 것을 제거한다. 이제 10053 trace 내용 중에서 SLP에 대해 분석해보자. 특히 SLP 변환 전 SQL과 SLP 변환 후 SQL을 비교해보라. 아래의 10053 trace 내용이 복잡해 보이지만 구조는 단순하며 다음과 같다.

1) 쿼리변환 전 SQL
2) 쿼리변환(SLP)
3) 쿼리변환 후 SQL

SQL:******* UNPARSED QUERY IS *******
SELECT "A"."CUST_ID" "CUST_ID","B"."PROD_ID" "PROD_ID","B"."TIME_ID" "TIME_ID","B"."CHANNEL_ID" "CHANNEL_ID","B"."QUANTITY_SOLD" "QUANTITY_SOLD" FROM ( (SELECT "CUSTOMERS"."CUST_ID" "CUST_ID","CUSTOMERS"."CUST_FIRST_NAME" "CUST_FIRST_NAME","CUSTOMERS"."CUST_LAST_NAME" "CUST_LAST_NAME","CUSTOMERS"."CUST_GENDER"
…중간생략
"CUST_SRC_ID","CUSTOMERS"."CUST_EFF_FROM" "CUST_EFF_FROM","CUSTOMERS"."CUST_EFF_TO" "CUST_EFF_TO" FROM "TLO"."CUSTOMERS" "CUSTOMERS") UNION ALL (SELECT "CUSTOMERS_100"."CUST_ID" "CUST_ID","CUSTOMERS_100"."CUST_FIRST_NAME""CUST_FIRST_NAME",
"CUSTOMERS_100"."CUST_LAST_NAME" "CUST_LAST_NAME","CUSTOMERS_100"."CUST_GENDER"
…중간생략
"CUST_SRC_ID","CUSTOMERS_100"."CUST_EFF_FROM""CUST_EFF_FROM","CUSTOMERS_100"."CUST_EFF_TO"
"CUST_EFF_TO" FROM "TLO"."CUSTOMERS_100" "CUSTOMERS_100")) "A","TLO"."SALES" "B" WHERE "A"."CUST_ID"="B"."CUST_ID" AND "A"."CUST_ID"=14865
Query block SEL$1 (#0) unchanged
SLP: Removed select list item CUST_FIRST_NAME from query block SEL$3
SLP: Removed select list item CUST_FIRST_NAME from query block SEL$2
SLP: Removed select list item CUST_FIRST_NAME from query block SET$1
...중간생략
SLP: Removed select list item CUST_EFF_TO from query block SEL$3
SLP: Removed select list item CUST_EFF_TO from query block SEL$2
SLP: Removed select list item CUST_EFF_TO from query block SET$1
JE: Considering Join Elimination on query block SEL$1 (#0)
*************************
Join Elimination (JE)
*************************
SQL:******* UNPARSED QUERY IS *******
SELECT "A"."CUST_ID" "CUST_ID","B"."PROD_ID" "PROD_ID","B"."TIME_ID" "TIME_ID","B"."CHANNEL_ID" "CHANNEL_ID","B"."QUANTITY_SOLD" "QUANTITY_SOLD" FROM ( (SELECT "CUSTOMERS"."CUST_ID" "CUST_ID" FROM "TLO"."CUSTOMERS" "CUSTOMERS") UNION ALL (SELECT "CUSTOMERS_100"."CUST_ID" "CUST_ID" FROM "TLO"."CUSTOMERS_100" "CUSTOMERS_100")) "A","TLO"."SALES" "B" WHERE "A"."CUST_ID"="B"."CUST_ID" AND "A"."CUST_ID"=14865

필요한 컬럼만 살아남다
SLP(Select List Pruning)가 발생하여 사용하지 않는 모든 컬럼을 삭제하였다. 쿼리변환 후의 SQL을 보면 뷰 내부의 컬럼은 모두 제거되고 cust_id만 남아있다. SLP 기능에 의해 테이블 엑세스가 없어진 것이다. 뷰 내부에는 union뿐만 아니라 minus,intersect 등의 집합 연산의 사용을 자제해야 한다. SLP가 발생하지 않기 때문이다.

그렇다면 뷰내부에 union all과 minus를 동시에 사용하면 어떻게 될까? 이제 union all과 minus를 동시에 사용한 뷰를 생성하고 SLP가 발생하는지 테스트 해보자.

CREATE OR REPLACE VIEW vw_cust33 AS
SELECT *
FROM customers
UNION ALL
SELECT *
FROM customers
MINUS
SELECT *
FROM customers_100;

이제 위의 뷰를 사용하여 select문을 실행해보자.

SELECT a.cust_id,
   b.prod_id,
   b.time_id,
   b.channel_id,
   b.quantity_sold
FROM vw_cust33 a, sales b
WHERE a.cust_id = b.cust_id
   AND a.cust_id = 14865 ;

---------------------------------------------------------------+----------------
| Id | Operation    | Name    | Rows | Cost |
---------------------------------------------------------------+----------------
| 0 | SELECT STATEMENT | | |    63 |
| 1 | HASH JOIN | | 260 |    63 |
| 2 | VIEW | VW_CUST33 | 2 | 7 |
| 3 |    MINUS | | | |
| 4 | SORT UNIQUE    | | 2 | |
| 5 |    VIEW    | | 2 | 4 |
| 6 | UNION-ALL    | | | |
| 7 |    TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 1 | 2 |
| 8 | INDEX UNIQUE SCAN    | CUSTOMERS_PK    | 1 | 1 |
| 9 |    TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 1 | 2 |
| 10 | INDEX UNIQUE SCAN    | CUSTOMERS_PK    | 1 | 1 |
| 11 | TABLE ACCESS BY INDEX ROWID    | CUSTOMERS_100 | 1 | 1 |
| 12 |    INDEX UNIQUE SCAN | PK_CUSTOMERS_100| 1 | 0 |
| 13 | PARTITION RANGE ALL    | | 130 |    56 |
| 14 |    TABLE ACCESS BY LOCAL INDEX ROWID | SALES | 130 |    56 |
| 15 | BITMAP CONVERSION TO ROWIDS    | | | |
| 16 |    BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX | | |
---------------------------------------------------------------+----------------

minus가 존재하여 SLP가 발생되지 않았다. Minus 때문에 불필요한 테이블 엑세스가 세 번이나 발생되었다. 어떻게 하면 이 문제를 해결할 수 있을까? 물론 부정형 서브쿼리(not exists)를 사용하면 minus 를 대신할 수 있으므로 불필요한 테이블 엑세스는 없어질 것이다.

minus를 사용하면서 SLP가 가능한가?

문제는 minus를 사용하면서 불필요한 엑세스를 방지할 수 있는 방법이 있냐는 것이다. 가장 쉬운 방법은 뷰에서 minus 부분을 제거하는 것이다. 즉 아래의 SQL처럼 minus 대신에 테이블을 직접 사용하면 된다.

create or replace view vw_cust as
select * from customers
UNION ALL
select * from customers ;

SELECT a.cust_id,
   b.prod_id,
   b.time_id,
   b.channel_id,
   b.quantity_sold
FROM VW_CUST a, --minus가 빠진 뷰를 사용함
   sales b
WHERE a.cust_id = b.cust_id
   AND a.cust_id = 14865
MINUS
SELECT a.cust_id,
   b.prod_id,
   b.time_id,
   b.channel_id,
   b.quantity_sold
FROM CUSTOMERS_100 a, --테이블을 직접 사용함
   sales b
WHERE a.cust_id = b.cust_id
   AND a.cust_id = 14865 ;

-----------------------------------------------------------------+----------------
| Id | Operation    | Name    | Rows | Cost |
-----------------------------------------------------------------+----------------
| 0 | SELECT STATEMENT | | | 115 |
| 1 | MINUS | | | |
| 2 | SORT UNIQUE    | | 260 |    59 |
| 3 |    HASH JOIN | | 260 |    58 |
| 4 | VIEW | VW_CUST | 2 | 2 |
| 5 |    UNION-ALL | | | |
| 6 | INDEX UNIQUE SCAN    | CUSTOMERS_PK    | 1 | 1 |
| 7 | INDEX UNIQUE SCAN    | CUSTOMERS_PK    | 1 | 1 |
| 8 | PARTITION RANGE ALL    | | 130 |    56 |
| 9 |    TABLE ACCESS BY LOCAL INDEX ROWID | SALES | 130 |    56 |
| 10 | BITMAP CONVERSION TO ROWIDS    | | | |
| 11 |    BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX | | |
| 12 | SORT UNIQUE    | | 130 |    56 |
| 13 |    NESTED LOOPS    | | 130 |    55 |
| 14 | INDEX UNIQUE SCAN    | PK_CUSTOMERS_100| 1 | 0 |
| 15 | PARTITION RANGE ALL    | | 130 |    55 |
| 16 |    TABLE ACCESS BY LOCAL INDEX ROWID | SALES | 130 |    55 |
| 17 | BITMAP CONVERSION TO ROWIDS    | | | |
| 18 |    BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX | | |
-----------------------------------------------------------------+----------------
예상대로 뷰에서 minus를 삭제하니 성공적으로 SLP가 발생되었고 테이블 엑세스가 모두 사라졌다.
결론
이번 시간에는 union과 union all의 또 다른 차이점에 대해 알아보았다. union all을 사용하면 SLP가 발생되어 뷰에서 사용되지 않는 컬럼을 제거한다. 이때 인덱스만으로 scan을 끝낼수 있는 경우 불필요한 테이블스캔이 방지된다. 따라서 뷰 내부에서는 union, minus, intersect를 빼는 것이 유리하다. 뷰 내부의 minus는 not exists로 바꾸면 된다. 대부분의 경우 뷰 내부에 Intersect도 필요치 않다. Intersect란 교집합이며 이것은 조인으로 해결할 수 있다. 왜냐하면 조인이란 두 집합에서 조인된 컬럼을 기준으로 값이 같은 것만 추출하는 기능이기 때문이다. 그렇지 않은가?

'Oracle > Optimizer' 카테고리의 다른 글

Cardinality Feedback이 위험할 때 (10)	2010.10.25
공지 - Cardinality Feed Back이 위험할 때 (1)	2010.10.22
메트릭스나 터미네이터는 먼 미래의 이야기 인가? (2)	2010.04.28
해결사 되기 (15)	2010.02.04
Distinct Elimination : 불필요한 Distinct를 제거하라 (6)	2010.01.25

Posted by extremedb

,

Bloom Filter와 Group By의 관계

Oracle/Data Access Pattern 2010. 9. 9. 00:30

이전에 Parallel Query 의 조인시 또다른 튜닝방법(Parallel Join Filter)과 Partition Access Pattern 이라는 글에서 Bloom Filter의 개념을 설명한적 있다. 이전 글들 때문인지 모르겠으나 많은 사람들이 Parallel Query를 사용하거나 Partition을 엑세스 할때 Bloom Filter로 후행 테이블의 건수를 줄여 조인 건수를 최소화하는 것으로만 생각한다. 맞는 말이지만 그것이 전부가 아니다.
그래서 이번에는 Parallel과 Partition에 상관없이 Bloom Filter가 발생하는 경우를 살펴보고자 한다. 이 글을 통하여 풀고자 하는 오해는 Bloom Filter가 Join 최적화를 위한 후행 테이블의 Filter 알고리즘일 뿐만 아니라 Group By를 최적화하는 도구이기도 하다는 것이다.

실행환경: Oracle11gR2, Windows 32bit

Bloom Filter를 사용하지 않는 경우

먼저 Bloom Filter가 발생하지 않게 힌트를 주고 실행한다. 뒤에서 Bloom Filter를 적용한 경우와 성능을 비교하기 위함이다.

SELECT /*+ LEADING(c) NO_MERGE(S) NO_PX_JOIN_FILTER(S) */

c.cust_id, c.cust_first_name, c.cust_last_name,

s.prod_cnt, s.channel_cnt, s.tot_amt

FROM customers c,

(SELECT s.cust_id,

COUNT (DISTINCT s.prod_id) AS prod_cnt,

COUNT (DISTINCT s.channel_id) AS channel_cnt,

SUM (s.amount_sold) AS tot_amt

FROM sales s

GROUP BY s.cust_id) s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id ;

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 23 |00:00:06.58 | 5075 | |

|* 1 | HASH JOIN | | 23 |00:00:06.58 | 5075 | 1194K (0)|

| 2 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 151 |00:00:00.01 | 148 | |

| 3 | BITMAP CONVERSION TO ROWIDS| | 151 |00:00:00.01 | 2 | |

|* 4 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | 1 |00:00:00.01 | 2 | |

| 5 | VIEW | | 7059 |00:00:06.56 | 4927 | |

| 6 | SORT GROUP BY | | 7059 |00:00:06.54 | 4927 | 9496K (0)|

| 7 | PARTITION RANGE ALL | | 918K|00:00:02.80 | 4927 | |

| 8 | TABLE ACCESS FULL | SALES | 918K|00:00:00.95 | 4927 | |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("S"."CUST_ID"="C"."CUST_ID")

4 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

Id 기준으로 8번에서 Buffers 항목을 보면 전체건(4927 블록)을 Scan 하였다. 그리고 A-Rows 항목을 보면 Sales 테이블에 대해 약 92만건(918K)을 읽었다. 이제 Id 6번을 보자. 전체 건수인 92만건에 대하여 Sort Group By를 적용하는데 부하가 집중되는 것을 알 수 있다. 시간상으로도 Group By를 하는데 3.7초 정도 걸렸으며 PGA를 9496K나 사용하였다. 즉 대부분의 시간을 Sort Group By Operation 에서 소비한 것이다.

이제 위의 SQL에 Bloom Filter를 적용해 보자. Sales 테이블에 파티션이 적용되어 있으나 파티션과 상관없이 Bloom Filter가 적용된다.

SELECT /*+ LEADING(c) NO_MERGE(S) PX_JOIN_FILTER(S) */

c.cust_id, c.cust_first_name, c.cust_last_name,

s.prod_cnt, s.channel_cnt, s.tot_amt

FROM customers c,

(SELECT s.cust_id,

COUNT (DISTINCT s.prod_id) AS prod_cnt,

COUNT (DISTINCT s.channel_id) AS channel_cnt,

SUM (s.amount_sold) AS tot_amt

FROM sales s

GROUP BY s.cust_id) s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id ;

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 23 |00:00:00.15 | 5075 | |

|* 1 | HASH JOIN | | 23 |00:00:00.15 | 5075 | 1197K (0)|

| 2 | JOIN FILTER CREATE | :BF0000 | 151 |00:00:00.01 | 148 | |

| 3 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 151 |00:00:00.01 | 148 | |

| 4 | BITMAP CONVERSION TO ROWIDS| | 151 |00:00:00.01 | 2 | |

|* 5 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | 1 |00:00:00.01 | 2 | |

| 6 | VIEW | | 55 |00:00:00.14 | 4927 | |

| 7 | SORT GROUP BY | | 55 |00:00:00.14 | 4927 |88064 (0)|

| 8 | JOIN FILTER USE | :BF0000 | 7979 |00:00:00.12 | 4927 | |

| 9 | PARTITION RANGE ALL | | 7979 |00:00:00.10 | 4927 | |

|* 10 | TABLE ACCESS FULL | SALES | 7979 |00:00:00.09 | 4927 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("S"."CUST_ID"="C"."CUST_ID")

5 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

10 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"S"."CUST_ID"))

Bloom Filter를 사용해보니

위의 실행계획에서 Id 기준으로 8번을 보면 Name 항목에 Bloom Filter가 사용되었다. Bloom Filter의 위력이 얼마나 대단한지 살펴보자. 먼저 Sales 테이블을 Full Table Scan 하였으므로 Buffers는 4927로 Bloom Filter를 사용하지 않는 경우와 똑같다. 하지만 Bloom Filter가 적용되어 92만건이 아닌 7979건(A-Rows 참조)만 살아남았다. 이처럼 Bloom Filter는 Hash Join시 Probe(후행) 집합에서 조인에 참여하는 건수를 줄임으로써 Join 시간을 단축시킨다. Bloom Filter의 효과는 이것이 끝이 아니다. 건수가 줄어듦으로 해서 Sort Group By 작업 또한 92만 건이 아니라 7979건만 하면 된다. Group By에 의한 PGA 사용량을 Bloom Filter가 적용된 실행계획과 비교해보면 100배 이상 차이가 나는 이유도 Bloom Filter의 효과 때문이다.

제약사항

이번에 test한 케이스는 Parallel Query도 아니며 Partition Pruning과도 관련이 없다. 하지만 항상 발생하지는 않는다. 이유는 세 가지 제약사항이 있기 때문이다.

첫 번째, Hash Join을 사용해야 한다. Sort Merge Join이나 Nested Loop Join에서는 발생하지 않는다.
두 번째, Build Input(Driving) 집합에 Filter 조건이 존재해야 한다. 위의 SQL에서는 cust_year_of_birth = 1987가 Filter 조건으로 사용되었다. Filter가 필요한 이유는 선행집합의 Filter조건을 후행집합에서 Bloom Filter로 사용해야 하기 때문이다.
세 번째, Probe(후행) 집합에서 Group By를 사용해야 한다. 위의 SQL에서도 cust_id로 Group By를 하고 있다. 물론 후행집합에 Group By가 적용되려면 뷰나 인라인뷰가 필요하다.

만약 Bloom Filter가 사라져 전체 건이 조인에 참여한다면?

상상하기 싫은 경우지만 Probe(후행) 집합에 Bloom Filter가 사라지는 경우를 살펴보자. 이 경우는 Sales 테이블 전체건수(약 92만건)가 모두 Hash Join에 참여하게 되므로 성능이 저하될 것이다. 아래의 SQL이 그것인데 위의 SQL에서 NO_MERGE(S) 힌트와 PX_JOIN_FILTER(S)만 뺀 것이다.

SELECT /*+ LEADING(c) */

c.cust_id, c.cust_first_name, c.cust_last_name,

s.prod_cnt, s.channel_cnt, s.tot_amt

FROM customers c,

(SELECT s.cust_id,

COUNT (DISTINCT s.prod_id) AS prod_cnt,

COUNT (DISTINCT s.channel_id) AS channel_cnt,

SUM (s.amount_sold) AS tot_amt

FROM sales s

GROUP BY s.cust_id) s

WHERE c.cust_year_of_birth = 1987

AND s.cust_id = c.cust_id ;

-------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 23 |00:00:05.39 | 5075 | |

| 1 | SORT GROUP BY | | 23 |00:00:05.39 | 5075 |75776 (0)|

|* 2 | HASH JOIN | | 3230 |00:00:05.37 | 5075 | 1185K (0)|

| 3 | TABLE ACCESS BY INDEX ROWID | CUSTOMERS | 151 |00:00:00.01 | 148 | |

| 4 | BITMAP CONVERSION TO ROWIDS| | 151 |00:00:00.01 | 2 | |

|* 5 | BITMAP INDEX SINGLE VALUE | CUSTOMERS_YOB_BIX | 1 |00:00:00.01 | 2 | |

| 6 | PARTITION RANGE ALL | | 918K|00:00:02.70 | 4927 | |

| 7 | TABLE ACCESS FULL | SALES | 918K|00:00:00.94 | 4927 | |

-------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("S"."CUST_ID"="C"."CUST_ID")

5 - access("C"."CUST_YEAR_OF_BIRTH"=1987)

악성 쿼리변환

힌트를 제거하자 View Merging(뷰 해체)이 발생하여 인라인뷰가 제거되었다. (View Merging이 발생하지 않는 독자는 MERGE(S) 힌트를 추가하기 바란다) 뷰가 없어짐에 따라 후행집합에서 Group By가 없어지고 조인이 끝난 후에 Group By가 발생한다. 후행집합의 Group By가 사라졌으므로 Bloom Filter가 적용되지 않는다. 따라서 Sales 테이블의 전체건 (약 92만건)이 조인에 참여하게 된다. Bloom Filter가 적용된 경우는 단 55건만 조인에 참여하므로 이 차이는 어마 어마한 것이다. 그 결과 전체 수행시간중에서 Hash Join에서만 절반의 시간을 소모하였다. 즉 잘못된 쿼리변환이 발생하여 Bloom Filter를 죽여버린 것이다. View Merging이 발생할 때 Bloom Filter를 적용할 수 없게되어 비효율이 발생되는지 주의깊게 관찰해야 한다.

결론

이번 Test 케이스에서 Bloom Filter의 특징을 두 가지로 압축할 수 있다. Group By 작업량을 최소화 시켜주고 Hash Join 건수를 줄여준다. 이 두 가지 효과가 맞물려 Bloom Filter를 적용한 SQL이 0.15초 만에 끝날 수 있는 것이다. 후행 테이블에서 Bloom Filter로 걸러지는 건수가 많을 때 두 가지 작업(Group By, Hash Join) 모두 최대의 효율을 발휘한다. 바꿔 말하면 Bloom Filter로 제거되는 건수가 미미 하다면 사용해선 안된다.

CVM(Complex View Merging)이 발생하면 여지없이 Bloom Filter가 사라진다. CVM 때문에 성능이 저하된다면 NO_MERGE 힌트를 사용하여 뷰를 유지시켜야 한다. Bloom Filter가 사라지는 경우는 이 경우 뿐만 아니다. 11gR2에서 새로 적용된 Cardinality Feedback 때문에 Bloom Filter가 사라지는 경우가 보고되고 있다. 마지막(세번째) SQL을 최초로 실행시켰을 때와 두번째로 실행시켰을 때 DBMS_XPLAN.DISPLAY_CURSOR의 실행계획이 달라진다면 Cardinality Feedback이 Bloom Filter를 제거시킨것이다. Shared Pool을 Flush하고 두번 연달아 테스트 해보기 바란다. 이런 현상들 때문에 옵티마이져에 새로운 기능이 추가될 때마다 긴장을 늦출 수 없다. 버전이 올라갈수록 튜닝하기가 쉬워지는것인가? 아니면 그 반대인가?

'Oracle > Data Access Pattern' 카테고리의 다른 글

분석함수의 실행계획 - 1부 (12)	2011.02.07
Index_desc 힌트와 rownum = 1 조합은 안전한가? (12)	2010.11.09
Inlist Iterator를 사용하지 말아야 할 때 (13)	2010.06.23
오렌지나 TOAD에서 Predicate Information을 참조하는 방법 (7)	2010.01.12
Partition Access Pattern (13)	2009.12.24

Posted by extremedb

,


	오동규 블로그 odong91@naver.com by extremedb

'Oracle'에 해당되는 글 120건

'Oracle > Data Join Method' 카테고리의 다른 글

'Oracle > Optimizer' 카테고리의 다른 글

'Oracle > Performance Analysis' 카테고리의 다른 글

'Oracle > Data Join Method' 카테고리의 다른 글

'Oracle > SQL Tuning' 카테고리의 다른 글

'Oracle > SQL Tuning' 카테고리의 다른 글

'Oracle > Partition' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

'Oracle > SQL Tuning' 카테고리의 다른 글

'Oracle > Data Join Method' 카테고리의 다른 글

'Oracle > SQL Tuning' 카테고리의 다른 글

'Oracle > SQL Pattern' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

'Oracle > Optimizer' 카테고리의 다른 글

'Oracle > Optimizer' 카테고리의 다른 글

'Oracle > Optimizer' 카테고리의 다른 글

'Oracle > Data Access Pattern' 카테고리의 다른 글

카테고리

최근에 올라온 글

최근에 달린 댓글

글 보관함

링크

태그목록

최근에 받은 트랙백

티스토리툴바