태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'parallel_query'에 해당되는 글 1건

  1. 2008.04.10 gather_plan_statistics 힌트와 Parallel Query

gather_plan_statistics 힌트와 Parallel Query

오라클 2008.04.10 15:37
오라클 10g부터 gather_plan_statistics 힌트를 이용하면 SQL Trace를 수행하지 않고도 Query의 Plan 단계별 일량(Actual+Estimated Rows을 포함한)을 알 수 있다는 것은 여러 차례 논의한 바 있다.

하지만 아래에 아주 재미있는 예가 있다.

alter table t_abnormal parallel 4;

select /*+ gather_plan_statistics */ count(*)
from t_abnormal;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

----------------------------------------------------------------------------------
| Id  | Operation              | Name       | Starts | E-Rows | A-Rows | Buffers | ----------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE        |            |      1 |      1 |      1 |       3 |

|   2 |   PX COORDINATOR       |            |      1 |        |      4 |       3 |
|   3 |    PX SEND QC (RANDOM) | :TQ10000   |      0 |      1 |      0 |       0 |
|   4 |     SORT AGGREGATE     |            |      0 |      1 |      0 |       0 |
|   5 |      PX BLOCK ITERATOR |            |      0 |  50000 |      0 |       0 |
|*  6 |       TABLE ACCESS FULL| T_ABNORMAL |      0 |  50000 |      0 |       0 |
----------------------------------------------------------------------------------


위의 결과를 보면 Slave가 수행한 일량(A-Rows, Buffers) 정보는 기록되지 않고, Coordinator가 수행한 일량 정보만이 기록되는 것을 확인할 수 있다.

왜 이런 현상이 발생하는가?
기억할 것은 이런 현상은 SQL Trace에서도 동일하게 발생한다는 것이다. 아래 Report는 동일한 쿼리를 Trace하고 tkprof에 의해 출력한 결과이다.

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE (cr=3 pr=0 pw=0 time=641714 us)
      4   PX COORDINATOR  (cr=3 pr=0 pw=0 time=641660 us)
      0    PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
      0     SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)
      0      PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us)
      0       TABLE ACCESS FULL T_ABNORMAL (cr=0 pr=0 pw=0 time=0 us)

gather_plan_statistics 힌트를 사용했을 때와 동일하게 Slave가 수행한 일량은 기록되지 않는다. 비슷한 경험을 해본 사람들이라면 Slave가 수행한 일량은 Coordinator의 trace file이 아닌 Slave의 trace file에 기록된다는 것을 잘 알고 있을 것이다.

bdump directory(PQ Slave는 background session으로 인식되므로)에 Slave들의 trace file이 기록되고, tkprof 결과는 다음과 같다. 즉, 별도의 trace file을 확인해야 Slave들의 일량을 알 수 있다.

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)
      0   PX COORDINATOR  (cr=0 pr=0 pw=0 time=0 us)
      0    PX SEND QC (RANDOM) :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
      1     SORT AGGREGATE (cr=87 pr=0 pw=0 time=522343 us)
  15855      PX BLOCK ITERATOR (cr=87 pr=0 pw=0 time=431178 us)
  15855       TABLE ACCESS FULL T_ABNORMAL (cr=87 pr=0 pw=0 time=127547 us)


이것은 Oracle의 버그가 아니라 Oracle PQ 아키텍처에서 오는 기본적인 한계점이라고 할 수 있다. 이 한계점이 gather_plan_statistics 힌트에 그대로 나타난 것이라고 할 수 있다.

이것이 중요한 결함인가가 더 중요한 사실일텐데... 나의 생각은 그렇지 않다는 것이다. 개별 Slave들의 일량은 사실 중요하지 않다. Query 전체 레벨의 일량 정보만 있으면 정확한 분석이 가능하기 때문이다. 어차피 Slave들이 하는 일은 전체 일량을 나누어 가지고 수행하는 것에 불과하기 때문이다.

따라서 다음과 같이 no_parallel 힌트를 사용해서 Serial하게 수행함으로써 gather_plan_statistics 힌트의 목적을 그대로 살릴 수 있다.

select /*+ gather_plan_statistics no_parallel(t_abnormal) */ count(*)
from t_abnormal;

select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

-------------------------------------------------------------------------------
| Id  | Operation          | Name       | Starts | E-Rows | A-Rows | Buffers |
-------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE    |            |      1 |      1 |      1 |     122 |
|   2 |   TABLE ACCESS FULL| T_ABNORMAL |      1 |  50000 |  50000 |     122 |
-------------------------------------------------------------------------------

신고
Trackbacks 26 : Comment 0

Write a comment

티스토리 툴바