병렬 DML 운영: 활성화·실제 DOP·제약·검증

핵심 요약

Parallel DML(PDML)은 INSERT, UPDATE, DELETE, MERGE의 변경 작업을 여러 PX Server가 나누어 수행하는 기능입니다. SQL에 PARALLEL Hint가 있거나 Target Table에 Parallel 속성이 있어도 PDML Mode가 꺼져 있으면 변경 부분은 병렬화되지 않습니다. 반대로 PDML Mode를 켰더라도 DOP를 결정할 근거가 없거나 Trigger·Remote Object·Constraint 같은 제한을 위반하면 변경 부분은 직렬로 수행될 수 있습니다.

PDML 판단은 다음 세 관문으로 나눕니다.

1. PDML Mode 활성화
2. DOP를 결정할 근거 존재
3. Object·Constraint·Transaction 제한 통과

Source Query의 Scan·Join 병렬화와 Target DML의 병렬화는 독립적입니다. 따라서 실행계획에 PX Operation이 보인다는 사실만으로 Target 변경이 병렬이라고 단정하지 않습니다. 실제 수행 여부는 V$PQ_SESSTAT의 DML Parallelized, 실제 DOP와 PX Server 수, Runtime Plan, Table Queue 분배를 함께 확인합니다.

학습 목표

1. Parallel Query와 Parallel DML을 구분한다.
2. PDML Mode, DOP 근거, 제한 조건을 별도 관문으로 판단한다.
3. ENABLE PARALLEL DML, FORCE PARALLEL DML, Statement Hint의 차이를 설명한다.
4. Source Query와 Target DML의 병렬화가 독립적인 이유를 이해한다.
5. Parallel INSERT의 Direct-Path 기본 동작과 NOAPPEND를 구분한다.
6. QC·PX Server·자식 트랜잭션·2단계 Commit의 관계를 설명한다.
7. Trigger·Constraint·LOB·Remote Object·Bitmap Index 제한을 판단한다.
8. Oracle AI Database 26ai에서 완화된 동일 객체 재접근 조건을 구분한다.
9. 요청 DOP와 실제 DOP, PX Server Set과 Table Queue Skew를 실측한다.
10. Undo·Redo·Lock·공간·Rollback까지 포함해 PDML 적용 여부를 결정한다.

1. PDML의 세 관문

1.1 PDML Mode 활성화

Session 전체에 활성화하려면 다음 명령을 사용합니다.

ALTER SESSION ENABLE PARALLEL DML;

특정 Statement에만 활성화하려면 Hint를 사용합니다.

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

ENABLE_PARALLEL_DML은 PDML Mode를 켜는 Hint이며 숫자 DOP를 지정하지 않습니다. Session에서 PDML Mode가 활성화되어 있어도 특정 Statement에 DISABLE_PARALLEL_DML Hint를 사용하면 그 문장의 DML 부분은 직렬 후보가 됩니다.

1.2 DOP 결정 근거

Mode가 켜졌다는 사실만으로 DOP가 정해지는 것은 아닙니다. UPDATE, MERGE, DELETE가 병렬화되려면 다음 중 하나 이상의 근거가 필요합니다.

• Target Table의 PARALLEL 속성
• Statement 또는 Object 수준 PARALLEL Hint
• Auto DOP
• ALTER SESSION FORCE PARALLEL DML

다음처럼 역할을 구분합니다.

ENABLE_PARALLEL_DML
→ PDML Mode 활성화

PARALLEL(t 8)
→ 후보 DOP 제시

Resource Manager·PX 가용성·Granule·제한 조건
→ 실제 DOP와 실행 방식 결정

1.3 제한 조건 통과

Mode와 DOP 근거가 있어도 제한을 위반하면 병렬 변경이 수행되지 않을 수 있습니다. 많은 제한 위반은 오류를 발생시키지 않고 직렬로 Fallback합니다. 운영에서는 Hint 존재 여부보다 실제 실행 결과를 검증해야 합니다.

2. ENABLE과 FORCE의 차이

ALTER SESSION ENABLE PARALLEL DML;

ENABLE은 이후 DML Statement를 병렬 실행 후보로 만듭니다. 그러나 Statement에 PARALLEL Hint가 없고 Target에 Parallel 속성도 없으며 Auto DOP도 적용되지 않으면 직렬로 수행될 수 있습니다. ENABLE 절에는 숫자 DOP를 붙일 수 없습니다.

ALTER SESSION FORCE PARALLEL DML PARALLEL 8;

FORCE는 병렬화 가능한 이후 DML을 지정한 DOP로 강제하는 Session 설정입니다. Statement의 Parallel Hint는 강제 DOP보다 우선할 수 있습니다. FORCE도 Trigger·Remote Object 같은 PDML 제한을 우회하지 못합니다.

운영 Session에서 FORCE를 사용하면 예상보다 많은 SQL이 병렬화될 수 있으므로 적용 범위와 복구 명령을 함께 준비합니다.

ALTER SESSION DISABLE PARALLEL DML;

3. Query 부분과 DML 부분은 독립적

다음 문장은 Source를 읽는 Query 부분과 Target을 변경하는 DML 부분으로 나뉩니다.

INSERT INTO target_sales
SELECT *
FROM   source_sales;

Source SELECT
→ Scan·Join·Aggregation이 Parallel Query로 수행될 수 있음

Target INSERT
→ PDML Mode·DOP 근거·제한 조건을 모두 통과해야 병렬 변경 가능

PDML Mode가 꺼져 있어도 Source Query는 병렬일 수 있습니다. 이 경우 Plan에 PX BLOCK ITERATOR, PX SEND, PX RECEIVE가 보여도 Row가 QC 또는 단일 Process로 모인 뒤 Target이 직렬로 변경될 수 있습니다.

실제 병렬 DML 여부는 다음 값으로 확인합니다.

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

• Queries Parallelized: Query 부분의 병렬 수행 횟수
• DML Parallelized: 변경 부분의 병렬 수행 횟수
• DOP: 마지막 Statement에서 사용한 DOP
• Servers: 동시에 사용한 최대 PX Server 수
• Server Sets: 동시에 사용한 최대 PX Server Set 수

Queries Parallelized > 0이고 DML Parallelized = 0이면 Source Query만 병렬이고 Target 변경은 직렬일 가능성을 우선 검토합니다.

4. Statement별 병렬화 규칙

4.1 UPDATE·DELETE·MERGE

MERGE /*+ ENABLE_PARALLEL_DML PARALLEL(t 8) */ INTO customer t
USING (
  SELECT /*+ PARALLEL(s 8) */ *
  FROM customer_stage s
) s
ON (t.customer_id = s.customer_id)
WHEN MATCHED THEN
  UPDATE SET t.grade = s.grade;

Target Table의 Parallel 속성, Target을 지칭하는 Parallel Hint, Auto DOP 또는 Session Force가 DOP 근거가 됩니다. Source Subquery의 PARALLEL(s 8)만으로 Target MERGE 부분의 병렬화가 보장되지는 않습니다.

Partitioned Table의 같은 Partition 내부에서 UPDATE, MERGE, DELETE를 병렬화하는 Intra-Partition Parallelism은 COMPATIBLE >= 23.0이 필요합니다.

Partition Key를 변경해 Row가 다른 Partition으로 이동해야 한다면 ENABLE ROW MOVEMENT가 필요합니다. Row Movement가 없으면 Partition 이동을 수반하는 Update는 허용되지 않습니다.

4.2 INSERT SELECT

Parallel INSERT에서는 Direct-Path가 기본입니다.

INSERT /*+ ENABLE_PARALLEL_DML PARALLEL(t 8) */
INTO target_sales t
SELECT /*+ PARALLEL(s 8) */ *
FROM source_sales s;

Parallel Conventional Insert를 시험하려면 NOAPPEND를 사용합니다.

INSERT /*+ ENABLE_PARALLEL_DML NOAPPEND PARALLEL(t 8) */
INTO target_sales t
SELECT /*+ PARALLEL(s 8) */ *
FROM source_sales s;

APPEND와 NOAPPEND는 Insert 경로를 지시하며, Statement가 병렬로 실행되는지 여부와는 별개의 판단입니다.

APPEND
→ Direct-Path Insert 요청

PARALLEL + PDML Mode
→ 병렬 변경 후보

Serial Mode에서 APPEND를 사용하면 Serial Direct-Path Insert가 될 수 있습니다. Parallel Mode에서 NOAPPEND를 사용하면 Parallel Conventional Insert가 될 수 있습니다.

5. QC·PX Server와 트랜잭션 원자성

Parallel DML에서는 QC와 각 PX Server가 하나의 사용자 Transaction을 구성합니다.

사용자 Transaction
├─ QC의 Coordinator Transaction
├─ PX Server 1의 Parallel Process Transaction
├─ PX Server 2의 Parallel Process Transaction
└─ ...

각 PX Server는 자신에게 배정된 Row를 별도 자식 트랜잭션으로 변경합니다. QC는 사용자 수준의 원자성을 유지하기 위해 자식 트랜잭션들의 Commit을 2단계 Commit Protocol로 조정합니다.

따라서 일부 PX Server만 성공하고 사용자 Transaction이 부분 Commit되는 방식으로 동작하지 않습니다. Statement 오류나 사용자 Rollback이 발생하면 전체 사용자 Transaction의 원자성에 맞춰 변경을 취소합니다.

PDML의 Rollback은 Forward DML과 비슷한 규모의 시간이 걸릴 수 있습니다. 대량 작업 전에 다음을 정합니다.

• 취소를 허용할 시점
• Rollback 예상 시간
• 재시작 단위와 Idempotency Key
• Batch 상태 기록 위치
• Undo·Redo·Archive·Standby 처리 여유

6. 대표 제한

6.1 Trigger·Remote·Object 제한

다음 조건에서는 PDML이 제한되거나 직렬로 Fallback할 수 있습니다.

• 실행될 수 있는 Enabled Trigger가 있는 Target
• Remote Object를 Query하거나 Remote Target을 변경하는 DML
• Distributed Transaction 내부의 DML
• Clustered Table
• Replication과 관련된 Object
• 병렬 안전성이 보장되지 않은 Function
• Object Type Column을 실제로 접근하는 DML

Trigger가 존재한다는 사실만 보지 않고 Statement로 인해 실제로 실행될 수 있는 Enabled Trigger인지 확인합니다. Trigger를 Disable하면 관련 Shared Cursor가 무효화될 수 있으므로 운영 영향도 함께 검토합니다.

6.2 LOB·Temporary Table·Bitmap Index

• Partitioned Table의 LOB Column은 PDML이 가능할 수 있지만 LOB의 Intra-Partition Parallelism은 지원되지 않습니다.
• Nonpartitioned Table의 SecureFiles LOB는 Parallel INSERT는 가능할 수 있지만 Parallel UPDATE·DELETE·MERGE는 지원되지 않습니다.
• Private Temporary Table은 Parallel UPDATE·DELETE·MERGE 대상이 될 수 없습니다.
• Nonpartitioned Table에 Bitmap Index가 있으면 PDML은 지원되지 않습니다.

6.3 Constraint 제한

NOT NULL, CHECK, UNIQUE, PRIMARY KEY는 PDML에서 사용할 수 있습니다. Referential Constraint는 DML 종류와 Parent·Child 위치에 따라 판단합니다.

Constraint가 있다는 이유만으로 모두 직렬이라고 단정하지 말고 DML 종류, Parent·Child 역할, Cascade·Deferrable 여부를 구분합니다.

7. 26ai의 동일 객체 재접근 완화

과거 Version에서는 Direct-Path Insert 또는 PDML 후 같은 Transaction에서 같은 Object를 다시 Query·DML하면 ORA-12838이 발생할 수 있어 중간 Commit이 필요했습니다.

Oracle AI Database 26ai에서는 다음 조건을 모두 만족하면 Direct-Path Insert 직후에도 같은 Session에서 동일 Object를 다시 Query하거나 Conventional DML·PDML·추가 Direct Load를 수행할 수 있습니다.

Heap Table
+ ASSM Tablespace
+ AUTOALLOCATE Tablespace
+ COMPATIBLE >= 23.0

네 조건 중 하나라도 충족하지 못하면 전통적인 재접근 제한을 전제로 설계하고 실제 Version과 Tablespace 속성을 확인합니다. 시험 문제에서는 Version 전제가 없으면 전통 규칙을 묻는지 최신 26ai 규칙을 묻는지 문맥을 확인합니다.

8. Undo·Redo·Lock·공간

병렬화는 같은 업무 Row의 변경 총량을 제거하지 않습니다.

1억 행 UPDATE
→ 여러 PX Server가 분담
→ 경과 시간 단축 가능
→ Table·Index Entry 변경 총량은 유지
→ Undo·Redo 총량이 자동으로 감소하지 않음

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

• PX 자식 트랜잭션별 Undo 사용
• LGWR·Redo Log·Archive 처리량
• Global·Local Index 유지비용
• Table·Partition·Row Lock과 대기
• Direct-Path Insert의 HWM 이후 공간과 새 Extent
• PX Server별 PGA와 Temporary Spill
• RAC Interconnect·Data Guard 전송량
• 실패 시 Parallel Rollback 시간

Parallel UPDATE는 Object의 기존 빈 공간을 사용할 수 있지만 Direct-Path Insert는 새 Extent를 확보합니다. 따라서 병렬화 전 Free Space와 Tablespace 증가량을 함께 검토합니다.

9. 요청 DOP와 실제 DOP

요청한 DOP와 실제 DOP는 다를 수 있습니다.

SELECT qcsid,
       sid,
       server_group,
       server_set,
       degree,
       req_degree
FROM   v$px_sesstat
ORDER BY qcsid, server_group, server_set, sid;

• REQ_DEGREE: Resource·Load Balancing 조정 전 요청 DOP
• DEGREE: 실제 PX Server Set이 사용한 DOP
• SERVER_SET: Producer·Consumer 등 논리적 PX Server Set

DOP 8은 Statement 전체에 PX Process가 항상 8개라는 뜻이 아닙니다. Producer와 Consumer 두 Set이 동시에 활동하면 약 2 × DOP가 필요할 수 있고, 여러 Parallelizer가 동시에 실행되면 Statement 전체 PX Server 수가 그보다 많을 수도 있습니다.

실제 DOP가 낮아지는 대표 원인은 다음과 같습니다.

• PX Server 부족
• Resource Manager Consumer Group 제한
• Parallel Statement Queue
• RAC Instance 가용성
• Object·Partition·Granule 수
• Auto DOP 재계산
• Statement의 일부 구간만 병렬화

10. 실행계획과 Runtime 검증

Actual Plan은 다음과 같이 확인합니다.

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

확인 항목:

1. Source Query와 Target DML Operation의 PX 구간
2. PX SEND·PX RECEIVE와 Table Queue 식별자
3. P->P, P->S, S->P, PCWP, PCWC
4. 각 Operation의 Starts, A-Rows, Buffers, Memory·Temp 사용
5. QC로 Row가 모인 뒤 직렬 DML이 발생하는 구간
6. Partition Pruning과 Target Partition 분배

Plan에 PX COORDINATOR가 있다는 사실만으로 PDML을 확정하지 않습니다. V$PQ_SESSTAT.DML Parallelized, 실제 Target Operation, 변경 Row 수를 함께 확인합니다.

11. Table Queue와 Skew

V$PQ_TQSTAT은 Table Queue를 통과한 PX Server별 Row·Bytes를 보여 줍니다. PDML은 Commit 또는 Rollback 후 같은 Session에서 조회하고, 다음 Parallel Statement가 실행되기 전에 확인하는 운영 절차를 사용합니다.

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

다음 값을 비교합니다.

• PX별 NUM_ROWS의 최소·최대·평균
• PX별 BYTES 편차
• Producer 단계부터 이미 편중되었는지
• Hash·Range·Partition 분배 이후 편중되었는지
• OPEN_TIME, WAITS, TIMEOUTS

Row 수는 비슷하지만 특정 PX의 Bytes만 크다면 Row Width Skew일 수 있습니다. Producer부터 편중되면 Partition·Predicate·Granule 문제를, 분배 이후 편중되면 Join Key·Range Boundary·Hash Key Skew를 우선 검토합니다.

12. SQL Monitor와 운영 판단

SQL Monitor에서는 다음 값을 구분합니다.

• 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를 사용했는지 여부

PX_MAXDOP=8인데 PX_SERVERS_ALLOCATED=16인 것은 Producer·Consumer 두 Set이 동시에 사용된 정상 구조일 수 있습니다. 반대로 요청 32, 할당 8이라면 자원 제한이나 Queue·Resource Manager 영향을 검토합니다.

PDML 적용 순서는 다음과 같습니다.

변경 Row 수와 Batch Window 확정
→ 직렬 DML 병목 측정
→ PDML Mode·DOP 근거 설정
→ Trigger·Constraint·Object·Version 제한 확인
→ 낮은 DOP부터 시험
→ Actual Plan·V$PQ_SESSTAT·V$PQ_TQSTAT 측정
→ Undo·Redo·Lock·공간·다른 업무 영향 확인
→ 실패·Rollback·재시작 절차 승인

혼동하기 쉬운 판단