11장. 파티셔닝과 병렬 처리

10억 건짜리 테이블을 다루는 두 가지 무기 — 읽을 범위를 잘라내는 파티셔닝, 읽는 손을 늘리는 병렬 처리. 대용량 Oracle 운영의 양대 축입니다.

11.1 파티셔닝 — 하나의 테이블, 여러 개의 서랍

파티셔닝은 논리적으로는 하나인 테이블을 물리적으로 여러 조각(파티션 = 각각 독립된 세그먼트)으로 나누어 저장하는 기능입니다(Enterprise Edition 옵션). 응용 프로그램은 여전히 테이블 하나로 보고 쿼리하지만, Oracle은 내부적으로 필요한 서랍만 열 수 있게 됩니다.

-- 월별 Range 파티셔닝의 전형
CREATE TABLE sales (
  sale_id   NUMBER,
  sale_date DATE NOT NULL,
  amount    NUMBER(12,2)
)
PARTITION BY RANGE (sale_date) (
  PARTITION p2026_01 VALUES LESS THAN (DATE '2026-02-01'),
  PARTITION p2026_02 VALUES LESS THAN (DATE '2026-03-01'),
  PARTITION p2026_03 VALUES LESS THAN (DATE '2026-04-01')
  -- ... 월마다 계속
);

11.2 Partition Pruning — 안 읽는 것이 가장 빠르다

파티셔닝의 성능 효과는 대부분 pruning(가지치기)에서 나옵니다. WHERE 절에 파티션 키 조건이 있으면 옵티마이저는 대상이 아닌 파티션을 아예 접근 대상에서 제외합니다. 실행계획의 Pstart/Pstop 컬럼에서 몇 번 파티션만 읽는지 확인할 수 있습니다.

11.3 Local vs Global 인덱스

파티션 테이블의 인덱스는 두 종류입니다. 이 선택이 유지보수 편의성을 좌우합니다.

-- local: 파티션마다 하나씩, 테이블과 같은 기준으로 분할
CREATE INDEX sales_cust_ix ON sales(cust_id) LOCAL;

-- 파티션 DDL 시 global 인덱스를 살리려면 UPDATE INDEXES를 붙인다 (대신 DDL이 느려짐)
ALTER TABLE sales DROP PARTITION p2025_01 UPDATE INDEXES;

11.4 파티션 유지보수 — DROP과 EXCHANGE

파티셔닝의 진짜 매력은 조회보다 운영에 있습니다. 1억 건 삭제를 DELETE로 하면 몇 시간 + 대량 undo/redo가 들지만, DROP PARTITION은 딕셔너리 작업 수준으로 끝납니다. 대량 적재의 비밀 병기는 EXCHANGE PARTITION입니다.

11.5 Parallel Query — PX 서버와 granule

파티셔닝이 "읽을 양"을 줄인다면, 병렬 처리(Parallel Execution)는 "읽는 속도"를 늘립니다. 세션의 서버 프로세스가 QC(Query Coordinator)가 되고, PX 서버라는 일꾼 프로세스들이 작업을 나눠 맡습니다. 동시에 일하는 일꾼 수가 DOP(Degree of Parallelism)입니다.

작업 분배 단위는 granule입니다. 풀스캔이라면 테이블을 블록 범위 granule로 잘게 나누고, PX 서버들이 하나씩 가져가 처리한 뒤 끝나면 다음 것을 가져갑니다 — 먼저 끝난 일꾼이 놀지 않는 동적 분배입니다(파티션 단위 granule이 쓰이는 연산도 있습니다).

-- 문장 단위로 병렬 지시 (가장 안전한 사용법)
SELECT /*+ PARALLEL(s 8) */ SUM(amount)
FROM   sales s
WHERE  sale_date >= DATE '2026-01-01';

-- 실행계획에는 PX COORDINATOR / PX BLOCK ITERATOR 등이 나타난다

11.6 병렬의 비용 — 언제 쓰고 언제 참는가

병렬 처리는 한 쿼리가 시스템 자원을 독식하도록 허가하는 것입니다. DOP 8이면 CPU 코어 8개와 8배의 I/O 대역폭을 그 쿼리 하나가 씁니다. 야간 배치·DW 집계처럼 "이 쿼리가 지금 시스템의 주인"일 때는 훌륭하지만, 동시 사용자가 많은 OLTP 낮 시간대에 남용하면 전체 서비스가 함께 느려집니다.

• 쓰기 좋은 곳: 대용량 풀스캔 집계, CTAS(CREATE TABLE AS SELECT), 인덱스 생성/재생성, 야간 배치.
• 피할 곳: 소량 조회(병렬 준비 비용이 더 큼), 동시성 높은 OLTP 시간대, PX 서버 풀이 고갈될 만큼의 무분별한 테이블 단위 PARALLEL 설정.
• 주의: PX 서버는 인스턴스 전체가 공유하는 유한한 풀입니다. 고갈되면 뒤에 온 쿼리는 낮은 DOP로 강등되거나 직렬로 실행됩니다.

✍️ 이해도 체크