Parallel Query·DDL·DML 운영: DOP·활성 조건·자원·트랜잭션

핵심 요약

Oracle 병렬 실행은 하나의 SQL 작업을 여러 Parallel Execution Server(PX Server)가 나누어 수행해 경과시간을 줄이는 기능입니다. 대표 유형은 Parallel Query, Parallel DDL, Parallel DML이며, 모두 PX Server를 사용할 수 있지만 병렬화 결정 기준과 운영 영향은 서로 다릅니다.

병렬화의 목적은 DOP를 가장 높게 만드는 것이 아닙니다. 업무 완료시간을 만족하면서 CPU·I/O·PGA·TEMP·Undo·Redo·PX Server·Lock·공간·복구·동시성 비용을 감당할 수 있는 수준을 선택해야 합니다.

Parallel DML은 특히 다음 세 조건을 분리해 판단합니다.

1. PDML Mode가 활성화되었는가?
2. Target DML에 병렬 DOP를 결정할 근거가 있는가?
3. Object·기능·Transaction 제한을 통과했는가?

세 조건 중 하나라도 충족하지 못하면 Query 부분은 병렬이어도 Target 변경 부분은 직렬로 남을 수 있습니다.

학습 목표

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

1. Parallel Query·DDL·DML의 목적과 병렬화 규칙을 구분한다.
2. 짧은 OLTP SQL과 대량 Batch에서 병렬화의 손익을 판단한다.
3. Statement Hint·Object 속성·Session Force·Auto DOP의 우선순위와 실제 DOP 차이를 설명한다.
4. Parallel DDL의 DOP와 Object에 남는 PARALLEL 속성을 구분한다.
5. PDML Mode 활성화와 실제 DML 병렬화가 서로 다른 조건임을 설명한다.
6. INSERT SELECT의 Query 부분과 Target INSERT 부분을 독립적으로 분석한다.
7. Parallel DML의 PX Transaction·Undo·Redo·Lock·Rollback 영향을 설명한다.
8. APPEND·NOAPPEND, Direct-Path Insert와 Conventional Insert를 구분한다.
9. NOLOGGING과 FORCE LOGGING, Backup·Standby·Media Recovery의 관계를 판단한다.
10. V$PX_SESSION, V$PQ_SESSTAT, SQL Monitor와 Resource Manager로 실제 병렬 운영 상태를 검증한다.

1. 병렬 처리가 적합한 작업과 부적합한 작업

병렬 실행은 하나의 Statement에 여러 CPU와 I/O 자원을 집중합니다. 다음과 같은 대량 작업에서는 경과시간 단축을 기대하기 쉽습니다.

• 대형 Table 또는 Partition Full Scan
• 대량 Fact·Dimension Join
• 대규모 GROUP BY·ORDER BY·Window Sort
• Data Warehouse Summary·Materialized View 생성과 Refresh의 일부 단계
• CTAS(Create Table As Select)
• 대형 Index 생성·Rebuild
• Batch INSERT·UPDATE·DELETE·MERGE
• Partition 단위 적재·이관·재구성

반대로 다음 상황에서는 병렬화 초기화·통신·동기화 비용이 실제 작업보다 클 수 있습니다.

• 단건 PK Lookup과 짧은 OLTP SQL
• 동시 Session이 매우 많은 시간대
• CPU Run Queue가 이미 긴 시스템
• Storage I/O 대역폭이 포화된 시스템
• PGA·TEMP 여유가 부족한 시스템
• 여러 Batch가 동시에 높은 DOP를 요청하는 환경

병렬화 이득
= 직렬 작업 분할로 줄어든 시간
- PX Server 확보·초기화 비용
- Data Redistribution·동기화 비용
- 추가 PGA·TEMP·I/O 비용
- Queue·Resource 경합 비용

따라서 Serial 기준 Rows·Buffers·Reads·A-Time을 먼저 측정하고, 어느 Operation을 병렬화할지와 허용 자원 한도를 정합니다.

2. Parallel Query·DDL·DML의 차이

2.1 Parallel Query

SELECT 또는 DML·DDL 안의 Query 부분을 병렬로 수행합니다. 별도의 ENABLE PARALLEL QUERY Mode를 켜는 방식이 아니라 다음 중 하나 이상의 근거가 있을 때 병렬 Query 후보가 됩니다.

• Statement 또는 Object PARALLEL Hint
• 참조 Table·Index의 PARALLEL 선언
• ALTER SESSION FORCE PARALLEL QUERY
• Automatic Degree of Parallelism(Auto DOP)

SELECT /*+ GATHER_PLAN_STATISTICS MONITOR PARALLEL(8) */
       customer_id,
       SUM(amount) AS total_amount
FROM   orders
WHERE  order_date >= DATE '2026-01-01'
GROUP BY customer_id;

2.2 Parallel DDL

Object 생성·재구성 작업을 병렬화합니다.

CREATE TABLE sales_summary
PARALLEL 8
AS
SELECT region,
       SUM(amount) AS total_amount
FROM   sales
GROUP BY region;

CREATE INDEX sales_region_ix
ON sales(region)
PARALLEL 8;

DDL의 생성·재구성 부분과 내부 Query 부분은 관련되지만 동일한 판단은 아닙니다. CTAS에서 DDL 생성 부분이 병렬이면 가능한 경우 Scan 부분도 병렬화되며, DDL 부분이 직렬이어도 SELECT 부분은 Parallel Query 규칙에 따라 병렬화될 수 있습니다.

2.3 Parallel DML

Target Table의 대량 INSERT·UPDATE·DELETE·MERGE를 여러 PX Server가 나누어 수행합니다. Parallel Query와 달리 PDML Mode가 Session 또는 해당 Statement에서 명시적으로 활성화되어야 합니다.

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+ ENABLE_PARALLEL_DML PARALLEL(8) */
INTO   sales_hist
SELECT *
FROM   sales
WHERE  sale_date < DATE '2025-01-01';

ENABLE_PARALLEL_DML은 PDML Mode를 허용하고, PARALLEL(8)은 DOP 후보를 제시합니다. 두 Hint의 역할은 다릅니다.

3. 요청 DOP와 실제 DOP

병렬 DOP 후보는 다음 위치에서 제시될 수 있습니다.

Statement-level PARALLEL Hint
Object-level PARALLEL Hint
Object의 PARALLEL 선언
ALTER SESSION FORCE PARALLEL QUERY·DDL·DML
Automatic Degree of Parallelism

실제 실행에서는 다음 제한을 거쳐 실제 DOP와 총 PX Server 수가 결정됩니다.

요청 DOP
→ Operation의 병렬화 가능 여부
→ Reference Object와 DOP 결정 규칙
→ Partition·Granule 수
→ CPU·PX Server 가용량
→ Resource Manager DOP 제한
→ Parallel Statement Queue
→ RAC Instance 배치
→ 실제 DOP·실제 PX Server 수

DOP 8은 Statement 전체가 PX Server 8개만 사용한다는 뜻이 아닙니다. Producer와 Consumer 두 PX Server Set이 동시에 활성화되면 하나의 Parallelizer에서 약 2 × DOP, 즉 최대 16개 PX Server와 QC가 함께 활동할 수 있습니다. 여러 Parallelizer가 겹치면 Statement 전체 요청 수는 더 커질 수 있습니다.

요청 DOP와 실제 DOP가 다르면 Hint가 무시되었다고 즉시 단정하지 않고 Queue·Resource Manager·PX Server 가용량·Partition 수를 확인합니다.

4. Parallel Query 실행계획과 Runtime 검증

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

다음을 함께 확인합니다.

• PX COORDINATOR
• PX BLOCK ITERATOR 또는 Partition Iterator
• PX SEND·PX RECEIVE
• TQ, IN-OUT, PQ Distrib
• Starts, A-Rows, Buffers, Reads, A-Time
• Memory·TEMP Spill
• PX Server별 Row·Bytes·시간 편차
• 요청·실제 DOP와 Statement Queue 시간

Client가 일부 Row만 Fetch한 채 Cursor를 오래 유지하면 결과 생산과 PX 자원 반환이 늦어질 수 있습니다. Fetch Size·전체 Fetch 여부·Cursor Close·Query Timeout도 운영 검증 대상입니다.

RAC에서는 PX_IS_CROSS_INSTANCE, PX Server가 배치된 Instance, Interconnect Bytes와 PARALLEL_FORCE_LOCAL 필요성을 함께 확인합니다.

5. Parallel DDL의 DOP와 남는 Object 속성

Parallel DDL은 CTAS·Index Build·Rebuild·Table Move 같은 대형 Object 작업을 여러 PX Server가 나누어 수행합니다.

CREATE TABLE sales_2026
PARALLEL 8
NOLOGGING
AS
SELECT *
FROM sales
WHERE sale_date >= DATE '2026-01-01';

CREATE INDEX sales_2026_ix
ON sales_2026(customer_id, sale_date)
PARALLEL 8;

CREATE TABLE, CREATE INDEX, ALTER INDEX REBUILD 등의 PARALLEL 선언은 Data Dictionary에 Object의 병렬 속성으로 저장될 수 있습니다. 이번 작업만 빠르게 끝났다고 해서 속성이 자동으로 사라진다고 가정하지 않습니다.

ALTER TABLE sales_2026 NOPARALLEL;
ALTER INDEX sales_2026_ix NOPARALLEL;

작업 후 다음을 확인합니다.

• USER_TABLES.DEGREE
• USER_INDEXES.DEGREE
• 생성·Rebuild 중 필요한 추가 Segment 공간
• TEMP 사용량
• 실패 시 정리 공간
• Tablespace Autoextend와 Free Space

Parallel DDL의 성공 기준은 작업시간뿐 아니라 이후 Query가 의도치 않게 병렬화되지 않는지까지 포함합니다.

6. PDML Mode 활성화와 실제 DML 병렬화 조건

PDML은 Session에서 기본적으로 비활성화되어 있습니다.

Session 전체 활성화

ALTER SESSION ENABLE PARALLEL DML;

특정 Statement만 활성화

UPDATE /*+ ENABLE_PARALLEL_DML PARALLEL(8) */
       orders
SET    status = 'ARCHIVED'
WHERE  order_date < DATE '2025-01-01';

PDML Mode를 켠 것만으로 Target 변경의 병렬 실행이 확정되지는 않습니다. 실제 DML Operation에는 다음이 필요합니다.

PDML Mode 활성화
+
Target DML의 DOP 근거
+
Object·기능·Transaction 제한 통과
→ Parallel DML 후보

DOP 근거의 예는 다음과 같습니다.

• Target Table의 PARALLEL 선언
• Statement·Object PARALLEL Hint
• Auto DOP
• ALTER SESSION FORCE PARALLEL DML

PDML Mode가 꺼져 있으면 PARALLEL Hint가 있어도 Target DML은 병렬화되지 않습니다. 그러나 DML 내부의 Scan·Join·Subquery는 Parallel Query 규칙을 충족하면 병렬로 실행될 수 있습니다.

7. Query 부분과 DML 변경 부분은 독립적이다

INSERT INTO sales_hist
SELECT *
FROM   sales
WHERE  sale_date < DATE '2025-01-01';

이 Statement는 두 부분으로 나눠 분석합니다.

Query 부분
→ SALES를 Scan하고 Filter·Join·Aggregate 수행

DML 부분
→ SALES_HIST에 Row를 삽입

Statement-level PARALLEL Hint 또는 Auto DOP는 Query와 DML 양쪽을 병렬화 후보로 만들 수 있습니다. 그러나 PDML Mode가 비활성화됐거나 제한 조건을 위반하면 DML 부분은 직렬로 남습니다.

실행계획에 PX Operation이 보인다는 이유만으로 Target 변경도 병렬이라고 결론 내리지 않습니다. 다음을 함께 확인합니다.

SELECT statistic,
       last_query,
       session_total
FROM   v$pq_sesstat
WHERE  statistic IN (
       'Queries Parallelized',
       'DML Parallelized',
       'DDL Parallelized',
       'DOP',
       'Servers',
       'Server Sets');

DML Parallelized가 증가했는지와 DML Operation 주변의 PX 구조를 확인합니다.

8. Parallel DML의 Transaction 구조와 Rollback

PDML에서는 QC와 PX Server가 별도의 Transaction 역할을 가집니다.

QC Coordinator Transaction
├─ PX Process Transaction 1
├─ PX Process Transaction 2
├─ PX Process Transaction 3
└─ PX Process Transaction 4
        ↓
전체 Statement의 성공·실패·Commit을 조정

각 PX Server가 자신의 작업 범위를 변경하므로 DOP가 커질수록 다음 자원이 증가할 수 있습니다.

• Parallel Process Transaction 수
• Undo와 Undo Segment 사용량
• Redo 생성량
• Transaction Slot
• Table·Partition·Row Lock
• PGA Workarea와 TEMP I/O
• Commit·Rollback 처리량

대량 PDML은 정상 완료시간뿐 아니라 오류 시 Rollback 시간과 Undo 여유를 반드시 시험해야 합니다. DOP 16의 작업이 10분에 끝나더라도 Rollback이 장시간 지속되면 운영 Window를 초과할 수 있습니다.

9. Direct-Path Insert·APPEND·NOAPPEND

Direct-Path Insert는 기존 Block의 Free Space를 찾아 삽입하기보다 기존 데이터 뒤쪽의 새 Block에 Row를 적재하고, Data Block 쓰기 경로에서 Buffer Cache를 우회합니다.

Conventional Insert
→ 기존 Free Space 재사용
→ Buffer Cache를 통한 변경
→ 동시성에 유리할 수 있음

Direct-Path Insert
→ 기존 데이터 뒤에 새 Block·Extent 할당
→ 기존 Free Space를 재사용하지 않음
→ 대량 적재에 유리할 수 있음
→ 공간·Lock·동시성·복구 영향 증가 가능

Serial INSERT SELECT에서는 APPEND Hint가 Direct-Path를 지시합니다.

INSERT /*+ APPEND */ INTO sales_hist
SELECT * FROM sales_stage;

Parallel Insert에서는 Direct-Path가 기본이며, Conventional Path를 시험하려면 NOAPPEND를 사용합니다.

INSERT /*+ ENABLE_PARALLEL_DML PARALLEL(8) NOAPPEND */
INTO sales_hist
SELECT * FROM sales_stage;

APPEND는 Direct-Path 선택 Hint이며 PDML Mode를 켜거나 DOP를 결정하는 Hint가 아닙니다. Parallel 여부는 PDML Mode와 PARALLEL 근거가 별도로 결정합니다.

Direct-Path 제한을 위반하면 Operation이 직렬 Conventional Insert로 전환될 수 있으므로 Hint만 보고 성공을 판단하지 않습니다. V$PQ_SESSTAT, SQL Monitor의 DIRECT_WRITES, Segment 증가량과 Lock 영향을 확인합니다.

10. Oracle AI Database 26ai의 후속 DML 제한 완화

과거에는 Direct-Path Insert 또는 PDML 이후 같은 Transaction에서 같은 Object를 다시 조회·변경하면 ORA-12838이 발생하는 패턴을 중요하게 다뤘습니다.

Oracle AI Database 26ai의 병렬 실행 가이드에서는 다음 조건을 모두 충족할 때 일부 과거 제한이 완화되어, 같은 Session에서 같은 Heap Table에 여러 DML·PDML·Query·Direct Load를 별도 Commit 없이 이어서 수행할 수 있다고 설명합니다.

1. Heap Table
2. SEGMENT SPACE MANAGEMENT AUTO인 Tablespace
3. AUTOALLOCATE Tablespace
4. COMPATIBLE >= 23.0

조건을 충족하지 않거나 Object 유형·기능 제한이 남아 있다면 전통적인 후속 접근 제한과 ORA-12838 가능성을 확인해야 합니다. 시험이나 운영에서는 다음을 분리합니다.

개념 문제
→ 문제에 제시된 Version·COMPATIBLE·Object 조건을 우선

실제 운영
→ 사용 중인 정확한 Release의 병렬 실행·INSERT 제한 문서와 Test 확인

모든 Oracle Version에서 Commit 제약이 완전히 사라졌다고 일반화하지 않습니다.

11. NOLOGGING·FORCE LOGGING·복구

NOLOGGING은 모든 Redo와 Undo를 제거하는 Option이 아닙니다.

Conventional Insert

• Table이 NOLOGGING이어도 Data와 Metadata 변경에 Redo·Undo를 생성합니다.

Direct-Path Insert

• Metadata 변경에는 Redo·Undo가 필요합니다.
• Data 변경은 Undo를 우회합니다.
• ARCHIVELOG·Object LOGGING·Database 또는 Tablespace FORCE LOGGING 상태에 따라 Data Redo 생성 여부가 달라집니다.
• FORCE LOGGING이면 Object의 NOLOGGING 설정보다 우선해 Data Redo가 생성됩니다.

NOLOGGING 판단
→ 실제 Operation이 Direct-Path인가?
→ Database·Tablespace가 FORCE LOGGING인가?
→ Standby 반영이 필요한가?
→ Media Recovery가 필요한 Object인가?
→ 작업 직후 Backup 가능한가?
→ 실패 시 재생성 가능한 데이터인가?

NOLOGGING 작업을 수행한 뒤 장애가 발생하면 이전 Backup과 Redo만으로 해당 Data Block을 완전히 재생성하지 못할 수 있습니다. 잃을 수 없는 Object라면 작업 직후 Backup 또는 재적재 절차를 준비합니다.

12. 주요 PDML 제한과 직렬 전환

다음 조건에서는 PDML이 제한되거나 Statement 전체가 직렬로 실행될 수 있습니다.

• 실행될 수 있는 Enabled Trigger가 있는 Target Table
• Distributed Transaction 또는 Remote Object
• Clustered Table
• Nonpartitioned Table의 Bitmap Index
• 일부 LOB·Object Type 구조
• Private Temporary Table의 UPDATE·DELETE·MERGE
• 병렬 실행 불가능한 User Function
• Object·제약·Replication 기능의 Version별 제한

대표 규칙을 다음처럼 정리합니다.

제한을 위반해도 항상 오류가 발생하는 것은 아닙니다. 직렬 실행으로 전환될 수 있으므로 실제 실행 통계를 확인해야 합니다.

13. Parallel Statement Queuing과 Resource Manager

높은 DOP의 SQL이 여러 개 동시에 실행되면 PX Server·CPU·PGA·TEMP·I/O를 급격히 소비할 수 있습니다.

Session 20개 × DOP 16
→ 각 SQL이 Producer·Consumer 두 Set 요청 가능
→ 수백 개 PX Server 요청
→ CPU Run Queue·PGA·TEMP·I/O 경합

PARALLEL_DEGREE_POLICY=AUTO 환경에서는 필요한 PX Server가 부족하거나 실행 시 활성 PX Server 수가 PARALLEL_SERVERS_TARGET을 넘게 되면 Parallel Statement가 Queue에 들어갈 수 있습니다.

• PARALLEL_SERVERS_TARGET: Queue를 시작하는 목표 수준
• PARALLEL_MAX_SERVERS: Instance가 생성할 수 있는 PX Server 절대 상한

PARALLEL_SERVERS_TARGET은 최대치가 아니라 Queue를 통해 과부하를 방지하기 위한 Threshold입니다. Resource Manager에서는 Consumer Group별 DOP Limit, Parallel Server 비율, Queue Timeout과 우선순위를 설정할 수 있습니다.

Queue 중인 Statement는 resmgr:pq queued Wait로 나타날 수 있습니다. SQL Monitor의 QUEUING_TIME, 요청·할당 PX Server 수와 함께 확인합니다.

14. 실제 병렬 실행을 확인하는 View

V$PX_SESSION

현재 PX Server Set과 QC 관계, 요청·실제 DOP를 확인합니다.

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

V$PQ_SESSTAT

마지막 Statement와 Session 누적 병렬화 횟수를 확인합니다.

SELECT statistic,
       last_query,
       session_total
FROM   v$pq_sesstat
ORDER BY statistic;

중요 항목은 다음과 같습니다.

• Queries Parallelized
• DDL Parallelized
• DML Parallelized
• DOP
• Servers
• Server Sets
• Local·Distributed Message 수

SQL Monitor

• PX_MAXDOP
• PX_SERVERS_REQUESTED
• PX_SERVERS_ALLOCATED
• QUEUING_TIME
• PX_IS_CROSS_INSTANCE
• CPU_TIME
• IO_INTERCONNECT_BYTES
• DIRECT_WRITES

PX_MAXDOP는 개별 Plan Operation의 최대 DOP이고, PX_SERVERS_REQUESTED·ALLOCATED는 Statement 전체 PX Server 수입니다. 서로 같은 값으로 해석하지 않습니다.

15. DOP 증가의 비선형 효과

DOP를 높이면 다음 자원이 함께 증가합니다.

PX Server 수 증가
→ 동시 Scan I/O 증가
→ Hash·Sort Workarea 수 증가
→ PGA 사용량 증가
→ TEMP Spill 동시성 증가
→ Table Queue Message 증가
→ RAC Interconnect Traffic 증가 가능
→ Undo·Redo·Lock·Transaction 수 증가 가능

예를 들어 DOP 8 Hash Join이 Producer·Consumer 두 Set을 사용하고 각 PX가 256MB Workarea를 사용한다면 단순 합계만으로도 여러 GB의 PGA가 필요할 수 있습니다.

DOP 2  → 20분
DOP 4  → 11분
DOP 8  → 8분
DOP 16 → 8분

DOP 8 이후 시간이 줄지 않는다면 I/O 포화·직렬 구간·Data Skew·QC 병목·TEMP Spill·PX 할당 부족을 확인합니다. 가장 높은 DOP가 아니라 추가 자원 대비 경과시간 개선이 의미 있는 지점을 선택합니다.

16. 운영 적용 절차

1. Serial 기준 Rows·Buffers·Reads·A-Time 측정
2. 목표 완료시간과 CPU·I/O·PGA·TEMP·Undo·Redo 한도 정의
3. Query·DDL·DML 중 병렬화할 부분을 분리
4. 요청 DOP와 실제 DOP·총 PX Server 수 확인
5. DML은 PDML Mode와 DOP 근거를 별도 확인
6. PX별 Row·Bytes·시간 편차와 TEMP Spill 확인
7. APPEND·NOAPPEND와 Segment·Lock 영향을 비교
8. NOLOGGING·FORCE LOGGING·Standby·Backup 정책 검증
9. 실패·Rollback·Recovery 시나리오 시험
10. 작업 후 Object의 PARALLEL·LOGGING 속성과 통계 원복 확인
11. 동시 Batch를 포함한 시스템 Throughput 측정
12. 운영 Version·COMPATIBLE의 공식 제한 재확인

변경 전후 비교표

병렬 처리 성공은 Plan에 PX가 나타나는 것이 아니라, 업무 완료시간과 시스템 전체 안정성을 동시에 만족하는 것입니다.

17. 혼동하기 쉬운 판단

핵심 정리

Parallel Query
→ 대량 Scan·Join·Sort·Aggregate 병렬화
→ PDML Mode와 무관

Parallel DDL
→ CTAS·Index Build·Rebuild·Move 병렬화
→ 작업 후 Object PARALLEL 속성 확인

Parallel DML
→ 명시적 PDML Mode 필요
→ Target DOP 근거와 제한 통과 필요
→ Query 부분과 변경 부분은 독립적으로 판단

Direct-Path·NOLOGGING
→ APPEND는 병렬화 Hint가 아님
→ 공간·Lock·Redo·Backup·Standby 영향 확인

운영 검증
→ 요청 DOP보다 실제 DOP·총 PX Server·Queue Time 확인
→ 한 SQL 경과시간과 시스템 전체 Throughput 동시 검증