병렬 실행 구조: QC·PX Server Set·Table Queue·Granule

핵심 요약

병렬 실행(Parallel Execution)은 하나의 SQL을 여러 번 복제하는 기능이 아니라, 병렬 가능한 실행계획을 Data Flow Operation(DFO)과 Granule로 나누고 여러 PX Server가 동시에 처리하도록 만드는 실행 방식입니다. QC는 병렬 실행을 조직하고, PX Server Set은 같은 병렬 Operation을 수행하며, Set 사이의 Row는 Table Queue로 이동합니다.

직렬 실행
→ 한 Process가 Scan·Join·Sort·Aggregate를 순서대로 처리

병렬 실행
→ QC가 작업을 조정
→ 여러 PX Server가 작업 단위를 나누어 처리
→ 필요한 지점에서 Row를 재분배
→ QC가 최종 결과를 Client에 반환

병렬 실행의 핵심 목적은 한 SQL의 경과시간을 줄이는 것입니다. 총 작업량이 자동으로 줄어드는 것은 아니며, PX Server 확보·Process 간 통신·Memory·TEMP·CPU·I/O 사용량이 추가될 수 있습니다. 따라서 실행계획에 PX가 보이는지만 확인하지 말고 QC, PX Server Set, DOP, Table Queue, Granule, 실제 PX별 작업량을 연결해서 읽어야 합니다.

학습 목표

이 이론을 학습한 뒤에는 다음을 설명할 수 있어야 합니다.

1. 직렬 실행과 병렬 실행의 비용 구조를 구분한다.
2. QC와 PX Server의 역할을 구분한다.
3. Producer·Consumer와 PX Server Set의 관계를 설명한다.
4. DOP가 PX Server Set 하나의 Server 수라는 의미를 이해한다.
5. DOP보다 실제 사용 PX Server 수가 많거나 적을 수 있는 이유를 설명한다.
6. Table Queue와 PX SEND·PX RECEIVE의 역할을 이해한다.
7. Block Range Granule과 Partition Granule의 차이를 설명한다.
8. 실행계획의 TQ, IN-OUT, PQ Distrib Column을 읽는다.
9. V$PX_SESSION, V$PQ_TQSTAT, SQL Monitor로 실제 병렬 실행을 검증한다.
10. 병렬 실행이 한 SQL과 시스템 전체 처리량에 미치는 영향을 함께 판단한다.

1. 병렬 실행이 필요한 이유

다음 Query가 2TB 규모의 매출 Table을 Scan해 월별 합계를 계산한다고 가정합니다.

SELECT sale_month,
       SUM(amount) AS total_amount
FROM   sales
GROUP BY sale_month;

직렬 실행에서는 한 Process가 전체 Block을 읽고 집계합니다. 병렬 실행에서는 Scan 대상과 집계 작업을 여러 PX Server가 나누어 처리할 수 있습니다.

PX Server 1 → Block 범위 A Scan → 부분 집계
PX Server 2 → Block 범위 B Scan → 부분 집계
PX Server 3 → Block 범위 C Scan → 부분 집계
PX Server 4 → Block 범위 D Scan → 부분 집계
                         ↓
              월별 Key 기준 재분배
                         ↓
                  최종 집계·반환

병렬 실행은 다음 조건에서 효과를 기대하기 쉽습니다.

• 읽거나 변경할 데이터가 크다.
• Full Scan·대량 Join·Sort·Aggregate 작업이 중심이다.
• 동시 사용자가 많지 않고 한 작업의 완료시간이 중요하다.
• CPU, I/O 대역폭, Memory와 PX Server 여유가 있다.

반대로 짧은 단건 조회나 수많은 Session이 동시에 실행하는 OLTP SQL에서는 PX Server 확보와 통신 비용이 실제 SQL 작업보다 클 수 있습니다.

2. Query Coordinator와 PX Server

병렬 SQL을 시작한 사용자 Session은 Query Coordinator(QC) 역할을 맡습니다. QC는 병렬 작업을 직접 모두 수행하는 Process가 아니라, 병렬 실행을 조직하고 결과를 Client에 연결하는 중심 Session입니다.

Client
  ↓
QC
  ├─ 필요한 PX Server 확보
  ├─ 병렬 실행 단계 조정
  ├─ 작업 단위 배분
  ├─ PX Server Set 사이의 Data Flow 조정
  └─ 직렬로 남은 작업·최종 결과 반환

PX Server는 QC를 대신해 실제 병렬 작업을 수행합니다.

• Table·Index Scan
• Join
• Sort
• Group By
• DDL 작업
• 활성화된 Parallel DML의 일부 변경 작업

예를 들어 DOP가 4인 Full Scan에서 Block Range Granule을 사용하면, Oracle은 Object 크기와 DOP를 고려해 DOP보다 많은 Block 범위 조각을 Runtime에 만들 수 있습니다. 각 PX Server는 하나의 Granule을 처리한 뒤 다음 Granule을 가져가므로 처음부터 Table을 정확히 네 구간으로 고정 분할한다고 이해하면 안 됩니다.

QC
├─ P000: Granule A 처리 → 다음 Granule 요청
├─ P001: Granule B 처리 → 다음 Granule 요청
├─ P002: Granule C 처리 → 다음 Granule 요청
└─ P003: Granule D 처리 → 다음 Granule 요청

QC는 모든 Row를 직접 읽는 Process로 해석하지 않습니다. 실행계획에 따라 Scan과 Join은 PX Server가 수행하고, QC는 PX Server 확보·단계 조정·직렬로 남은 작업·최종 결과 반환을 담당합니다.

3. Producer·Consumer와 PX Server Set

병렬 실행은 Producer·Consumer 모델로 동작합니다.

Producer PX Server Set
→ Row 생성
→ Table Queue를 통해 전달
→ Consumer PX Server Set
→ 다음 Operation 수행

예를 들어 병렬 Scan 결과를 월별 Key로 다시 나누어 병렬 집계한다고 가정합니다.

PX Server Set 1: SALES Scan
        ↓ PX SEND HASH
Table Queue
        ↓ PX RECEIVE
PX Server Set 2: HASH GROUP BY

• Producer: 다음 단계에 전달할 Row를 생성하는 PX Server
• Consumer: 이전 단계의 Row를 받아 Join·Sort·Aggregate 등을 수행하는 PX Server
• PX Server Set: 같은 병렬 Operation을 함께 수행하는 PX Server 집합
• PX Server Group: 하나의 Parallelizer에 속한 논리 Group이며, 일반적으로 Set 1과 Set 2를 가질 수 있습니다.
• DFO(Data Flow Operation): PX Server Set이 수행하는 기본 병렬 작업 단위
• Parallelizer: 실행계획의 PX COORDINATOR에 대응하는 병렬 실행 조정 단위

하나의 Parallelizer에는 여러 DFO가 있을 수 있지만 PX Server Set은 최대 두 개이므로, 한 시점에 Producer Set과 Consumer Set 두 개가 함께 활동할 수 있습니다. 다만 하나의 SQL Statement에 Subquery Factoring·Grouping Sets·일부 비상관 Subquery 등으로 여러 Parallelizer가 존재할 수 있습니다. 여러 Parallelizer가 동시에 활성화되면 Statement 전체 PX Server 수는 2 × DOP를 넘을 수 있습니다.

4. DOP와 실제 PX Server 수는 같은 값이 아니다

DOP(Degree of Parallelism)는 PX Server Set 하나에 포함되는 PX Server 수입니다.

DOP = 4
→ 한 PX Server Set에 PX Server 4개

하나의 Parallelizer에서 Producer Set과 Consumer Set이 동시에 동작하면 다음과 같이 최대 약 8개의 PX Server가 필요할 수 있습니다.

Producer Set: P000 P001 P002 P003  → 4개
Consumer Set: P004 P005 P006 P007  → 4개
                                  합계 8개

이 2 × DOP는 하나의 Parallelizer를 기준으로 한 일반적인 상한입니다. 실행계획에 PX COORDINATOR가 여러 개라면 Parallelizer마다 PX Server를 요청할 수 있으므로 Statement 전체 동시 사용량이 더 커질 수 있습니다.

따라서 다음 네 수치를 구분해야 합니다.

실제 할당량은 다음 조건 때문에 요청보다 작아질 수 있습니다.

• 사용 가능한 PX Server 부족 또는 Resource Manager 제한
• 시스템 부하와 동시 실행
• Operation 자체의 DOP 제한
• Partition Granule 수 부족
• 병렬 실행 제한 조건

PARALLEL_DEGREE_POLICY=AUTO이고 실행 시 활성 PX Server 수가 PARALLEL_SERVERS_TARGET을 넘게 되면, Statement는 낮은 DOP로 즉시 실행되는 대신 Parallel Statement Queue에서 기다릴 수 있습니다. 이때 SQL Monitor의 STATUS='QUEUED', QUEUING_TIME 또는 resmgr:pq queued Wait를 확인합니다.

V$PX_SESSION에서는 요청 DOP와 실제 DOP를 비교할 수 있습니다.

SELECT qcsid,
       qcserial#,
       qcinst_id,
       server_group,
       server_set,
       server#,
       degree,
       req_degree
FROM   v$px_session
ORDER BY qcsid,
         server_group,
         server_set,
         server#;

• REQ_DEGREE: 자원 제한이 적용되기 전 요청 DOP
• DEGREE: 해당 PX Server Set이 실제 사용하는 DOP
• SERVER_SET: Producer·Consumer 역할을 하는 논리 Set

SQL Monitor에서는 PX_MAXDOP로 Plan Operation 중 최대 실제 DOP를, PX_SERVERS_REQUESTED와 PX_SERVERS_ALLOCATED로 Statement 전체가 요청한 PX Server 총수와 실제 할당 총수를 확인할 수 있습니다. DOP와 전체 PX Server 수를 같은 값으로 해석하지 않습니다.

5. Table Queue와 PX SEND·PX RECEIVE

Table Queue는 Producer와 Consumer DFO Node 사이, PX Server Group과 QC 사이에서 Row를 전달하는 논리적 Data Channel입니다. 하나의 Table Queue는 실행계획의 PX SEND와 대응 PX RECEIVE를 연결하며, V$PQ_TQSTAT.TQ_ID는 이 연결을 식별합니다.

Producer Operation
→ PX SEND
→ :TQ10000
→ PX RECEIVE
→ Consumer Operation

PX SEND 뒤의 이름은 Row를 어떤 방식으로 전달하는지 보여 줍니다.

PX SEND HASH
PX SEND RANGE
PX SEND BROADCAST
PX SEND QC (RANDOM)

PX RECEIVE는 Consumer가 Table Queue에서 Row를 받는 Operation입니다. 실제 Plan에서는 :TQ10000, :TQ10001처럼 Queue 식별자가 표시됩니다.

병렬 SQL의 통신 비용은 다음 지점에서 증가합니다.

• Row 수가 많다.
• Row 폭이 크다.
• Producer와 Consumer 사이의 재분배가 많다.
• Data Skew로 특정 Consumer에 Row가 몰린다.
• RAC에서 다른 Instance로 Row를 보내 Interconnect를 사용한다.

병렬화의 이득을 판단할 때 Scan 시간만 보지 않고 Table Queue를 통과한 Row·Bytes와 대기시간을 함께 봅니다.

6. 실행계획에서 병렬 Data Flow 읽기

다음은 병렬 Scan 후 월별로 재분배해 집계하는 단순화된 Plan입니다.

| Id | Operation                 | TQ        | IN-OUT | PQ Distrib |
|  1 | PX COORDINATOR            |           |        |            |
|  2 |  PX SEND QC (RANDOM)      | :TQ10001  | P->S   | QC(RAND)   |
|  3 |   HASH GROUP BY           |           | PCWP   |            |
|  4 |    PX RECEIVE             |           | PCWP   |            |
|  5 |     PX SEND HASH          | :TQ10000  | P->P   | HASH       |
|  6 |      PX BLOCK ITERATOR    |           | PCWC   |            |
|  7 |       TABLE ACCESS FULL   | SALES     | PCWP   |            |

TQ

Table Queue 식별자입니다. 같은 :TQ10000을 사용하는 PX SEND와 PX RECEIVE가 하나의 Data Flow를 이룹니다.

IN-OUT

PQ Distrib

HASH, RANGE, BROADCAST, QC(RAND) 등 Row 분배 방식을 보여 줍니다. 분배 방식의 상세 원리는 다음 이론에서 학습합니다.

실행계획을 읽을 때는 다음 순서를 사용합니다.

1. PX COORDINATOR 확인
2. 가장 아래 Access Operation 확인
3. PX BLOCK ITERATOR·PX PARTITION Operation 확인
4. PX SEND와 PX RECEIVE를 TQ별로 연결
5. P->P 재분배 지점 확인
6. 최종 P->S 반환 확인

7. Granule: PX Server가 가져가는 실제 작업 단위

Granule은 PX Server가 한 번에 배정받아 처리하는 작업 단위입니다.

Block Range Granule

Table의 물리 Block 범위를 여러 조각으로 나눕니다.

Table Segment
├─ Granule 1: Block 1~100
├─ Granule 2: Block 101~200
├─ Granule 3: Block 201~300
└─ Granule 4: Block 301~400

특징은 다음과 같습니다.

• 대부분의 병렬 Operation에서 기본 작업 단위이며 Partitioned Table의 병렬 Scan에서도 흔히 사용됩니다.
• Object 크기와 DOP를 고려해 Runtime에 Granule 수와 크기를 계산합니다.
• 일반적으로 DOP보다 많은 Granule을 만들어 작업을 동적으로 배정합니다.
• DOP가 Partition 수에 직접 제한되지 않습니다.
• PX Server가 작업을 끝내면 다음 Granule을 받아 Load Balancing할 수 있습니다.
• 실행계획에서 PX BLOCK ITERATOR가 대표적인 단서입니다.

Partition Granule

Partition 또는 Subpartition 전체를 하나의 작업 단위로 사용합니다.

PX Server 1 → Partition P01 전체
PX Server 2 → Partition P02 전체
PX Server 3 → Partition P03 전체
PX Server 4 → Partition P04 전체

특징은 다음과 같습니다.

• 작업 단위가 DDL 시점에 정해진 Partition·Subpartition 구조에 고정됩니다.
• 최대 DOP가 대상 Partition·Subpartition 수에 제한될 수 있습니다.
• Oracle은 Load Balancing을 위해 가능하면 대상 Partition 수를 DOP의 약 3배 이상으로 구성하도록 권고합니다.
• Partition 크기가 불균등하면 일부 PX Server만 오래 실행할 수 있습니다.
• Parallel Index Range Scan, Partition-Wise Join, 여러 Partition을 변경하는 일부 병렬 작업에서 사용될 수 있습니다.
• 실행계획의 PX PARTITION RANGE, PX PARTITION HASH 등은 단서지만, Operation 목적과 실제 작업 배분을 함께 확인합니다.

Partitioned Table이라는 이유만으로 Partition Granule을 사용한다고 판단하지 않습니다. 실행계획과 실제 작업 배분을 확인합니다.

8. 실제 병렬 실행을 확인하는 도구

8.1 실제 Cursor Plan

SELECT /*+ MONITOR PARALLEL(4) */
       sale_month,
       SUM(amount)
FROM   sales
GROUP BY sale_month;

SELECT *
FROM TABLE(
    DBMS_XPLAN.DISPLAY_CURSOR(
        NULL,
        NULL,
        'ALLSTATS LAST +PARALLEL +PREDICATE +MEMSTATS +IOSTATS +NOTE'
    )
);

확인할 항목은 다음과 같습니다.

• PX COORDINATOR
• PX SEND·PX RECEIVE
• TQ, IN-OUT, PQ Distrib
• Operation별 A-Rows, Buffers, Reads, A-Time
• Note의 DOP·Dynamic Statistics·Adaptive·Downgrade 또는 Queuing 관련 정보
• OMem·1Mem·Used-Mem, Temp와 I/O 통계로 DOP별 Workarea 부담

예상 Plan만으로 실제 PX Server 할당과 Server별 편차까지 판단하지 않습니다. 실행한 Cursor의 통계와 동적 성능 View를 함께 사용합니다.

8.2 실행 중 PX Session

V$PX_SESSION은 현재 QC와 PX Server Set, 요청·실제 DOP를 보여 줍니다.

8.3 완료 후 Table Queue 통계

SELECT dfo_number,
       tq_id,
       server_type,
       instance,
       process,
       num_rows,
       bytes,
       open_time,
       avg_latency,
       waits,
       timeouts
FROM   v$pq_tqstat
ORDER BY dfo_number,
         tq_id,
         server_type,
         instance,
         process;

V$PQ_TQSTAT은 Query가 완료된 뒤 같은 Session에서만 유지되는 Table Queue 통계입니다. PX Server별 NUM_ROWS·BYTES 차이가 크면 Data Skew나 불균등한 Granule 배분을 검토하고, OPEN_TIME·WAITS·TIMEOUTS도 함께 확인합니다. Parallel DML의 경우 Commit 또는 Rollback 이후에 통계가 제공됩니다. 다른 Session에서 조회하거나 Session이 끝난 뒤에는 같은 실행의 통계를 기대할 수 없습니다.

8.4 SQL Monitor에서 전체 Server 수와 Queue 확인

SELECT status,
       px_maxdop,
       px_servers_requested,
       px_servers_allocated,
       queuing_time,
       px_is_cross_instance
FROM   v$all_sql_monitor
WHERE  sql_id = :sql_id
ORDER BY sql_exec_start DESC;

• PX_MAXDOP: Plan Operation 중 최대 DOP
• PX_SERVERS_REQUESTED: Statement 전체 요청 PX Server 수
• PX_SERVERS_ALLOCATED: 실제 할당 PX Server 수
• QUEUING_TIME: Parallel Statement Queue 대기시간
• PX_IS_CROSS_INSTANCE: RAC에서 여러 Instance에 걸쳐 실행했는지 여부

9. 병렬 실행 병목을 찾는 순서

병렬 SQL이 느릴 때 DOP부터 올리지 않고 다음 순서로 진단합니다.

1. Serial Plan의 전체 작업량 확인
2. 병렬화된 Operation과 직렬로 남은 Operation 확인
3. 요청 DOP와 실제 DOP 비교
4. Parallelizer·PX Server Group·Set 수와 전체 PX Server 사용량 확인
5. Table Queue별 Row·Bytes·Wait 확인
6. PX별 처리량·시간 편차와 Granule 종류 확인
7. CPU·I/O·PGA·TEMP·Interconnect 상태 확인
8. 동시 병렬 SQL과 Statement Queue 확인
9. DOP 변경 전후 한 SQL과 시스템 전체 처리량 비교

대표적인 병목 신호

10. 혼동하기 쉬운 판단 정리

11. 실전 적용 예시

상황

• SALES: 20억 행
• 월별 매출 집계
• DOP 요청: 8
• 실행시간: 40분
• PX Server별 처리 Row 수가 크게 다름

확인 절차

1. DISPLAY_CURSOR에서 실제 병렬 Plan 확인
2. V$PX_SESSION에서 REQ_DEGREE=8, DEGREE 확인
3. Parallelizer와 PX Server Set 수를 확인하고 전체 할당 Server 수 계산
4. V$PQ_TQSTAT에서 TQ별 Producer·Consumer NUM_ROWS·BYTES 비교
5. 한 Consumer만 과도하게 많다면 Group Key 편중 확인
6. TEMP·CPU·I/O 포화 여부 확인
7. DOP를 무조건 높이기보다 분배 Key·사전 집계·통계정보 개선 검토
8. 동일한 업무량으로 변경 전후 경과시간과 시스템 Throughput 비교

병렬 SQL 튜닝의 목표는 PX Server를 많이 사용하는 것이 아니라, 작업을 균등하게 나누고 재분배·직렬 병목을 최소화하면서 시스템이 감당할 수 있는 DOP를 선택하는 것입니다.

핵심 정리

QC
→ 병렬 SQL을 시작하고 PX Server를 조정

PX Server Set
→ 같은 병렬 Operation을 수행하는 PX Server 집합

Parallelizer
→ 최대 두 PX Server Set을 조정하는 병렬 실행 단위

DOP
→ PX Server Set 하나의 PX Server 수

Table Queue
→ Producer·Consumer DFO Node 또는 QC 사이의 Row 전달 통로

Granule
→ PX Server가 하나씩 배정받는 실제 작업 단위

검증
→ 실제 Cursor Plan + V$PX_SESSION + V$PQ_TQSTAT + SQL Monitor