본문 바로가기

02. SQLP 스터디/05. Oracle 기타

oracle append , parallel hint 사용

append hint 설명해줘, 병렬처리시 append 사용도 설명해줘
 

APPEND 힌트 설명

APPEND 힌트는 오라클 데이터베이스에서 INSERT 문과 함께 사용하여 Direct-Path Insert 방식을 강제합니다.
이 방식은 데이터를 테이블에 추가할 때 기존 데이터를 읽어 Row-by-Row로 저장하지 않고, 데이터 파일에 새로운 블록을 바로 할당하여 데이터를 빠르게 쓰는 방법입니다.

  • 문법 예시
  • sql
    INSERT /*+ APPEND */ INTO 테이블명 SELECT ...;

APPEND 힌트의 주요 특징

  • 성능 향상:
    트랜잭션 로그(Redo/Undo)의 생성을 최소화하기 때문에 대량 데이터 삽입 시 성능이 크게 향상됩니다.
  • NOLOGGING과 시너지:
    NOLOGGING 옵션과 같이 사용하면 Redo Log 기록이 줄어 성능 최적화 효과가 극대화됩니다.
  • 기존 데이터는 읽지 않고 바로 새로운 블록에 Data Append
    ⇒ 빠르지만, 기존 빈 공간 재사용은 하지 않습니다.
  • 커밋 전까지 다른 세션에서 신규 데이터 조회 불가
    Direct-Path Insert는 데이터가 메모리에 있다가 커밋 시 디스크에 반영되므로, 작업 중에는 다른 트랜잭션에서 해당 행을 조회할 수 없습니다.

병렬처리(Parallel DML)와 APPEND의 사용

병렬처리 개요

  • 오라클에서 INSERT 작업에 병렬 DML(PARALLEL DML)을 사용할 때, APPEND 힌트는 병렬 처리를 더 효과적으로 만듭니다.
  • 병렬 세션들이 각자 자신의 데이터 덩어리를 별도의 블록에 할당(Direct-Path Insert)함으로써, 최대의 I/O 처리량과 성능을 실현할 수 있습니다.

사용 예시

sql
ALTER SESSION ENABLE PARALLEL DML; INSERT /*+ APPEND PARALLEL(테이블명, 4) */ INTO 테이블명 SELECT ...;
  • APPEND: Direct-Path Insert 강제
  • PARALLEL: 병렬 실행 강제 (숫자는 병렬 degree, 예: 4는 4개 프로세스 동시에 작업)
  • 병렬+APPEND 조합일 때 각 병렬 프로세스가 자신만의 데이터 블록에 기록하여 오버헤드가 최소화됨

주의사항

  • UNDO/REDO 기록 최소화로 인해 장애 혹은 복구 시 데이터를 완전히 복구하지 못할 수 있음 (‘NOLOGGING’ 조합 시 특히!)
  • Direct-Path/병렬 작업 완료 후 테이블에 대해 ANALYZE/STATISTICS 갱신 필요
  • Direct-Path Insert는 일부 제한(트리거, 인덱스 즉시 적용 등) 존재
  • APPEND 없이 병렬로만 작업하면 기존 Row-by-Row 처리와 같은 방식 적용

요약

  • APPEND 힌트: Direct-Path Insert 강제, 대량 데이터 삽입 성능 향상
  • 병렬 DML + APPEND: 각 병렬 프로세스가 별도 블록에 데이터 기록 → 최대 속도, I/O 극대화
  • 필수 체크: NOLOGGING 병행 시 복구전략과 백업/통계 갱신 프로세스 마련

실제 운영환경에서는 데이터 영속성과 장애 대비를 위해 APPEND/NOLOGGING 무분별 사용은 지양하고, 작업 후 LOGGING 복원 및 전체 백업을 습관적으로 진행해야 합니다.

 

---------------------------------------------------------------------------------------------------------------------------------------------------

 

NOLOGGING은 오라클 데이터베이스에서 Redo 로그 생성을 최소화하여 대량 작업 시 성능을 높이기 위해 사용되는 옵션입니다. 주로 대용량 데이터 로딩, 인덱스 생성, 파티션 작업 등에서 적용되며, 작업 결과의 변경 기록이 Redo 로그에 남지 않으므로 복구(Redo/Media Recovery)가 불가능할 수 있어 매우 신중하게 사용해야 합니다.

  • 적용 예시:
    • 테이블 또는 인덱스 생성 시
    • sql
      CREATE TABLE tablename NOLOGGING AS SELECT ...; CREATE INDEX idx_name ON table(col) NOLOGGING;
    • 기존 객체에 적용
    • sql
      ALTER TABLE tablename NOLOGGING; ALTER INDEX idx_name NOLOGGING;
    • Direct Path Insert와 병렬 DML
    • sql
      INSERT /*+ APPEND */ INTO tablename SELECT * FROM ...; ALTER SESSION ENABLE PARALLEL DML; INSERT /*+ PARALLEL(tablename, 4) */ INTO tablename SELECT ...;
  • 효과:
    • 성능 개선: 대량의 데이터 입력, 인덱스 생성, 파티션 작업이 빠르게 끝남.
    • Redo Log 절감: 로그가 거의 생성되지 않거나 최소화되어 I/O 부하가 감소함.
  • 주의 사항:
    • 복구 불가: NOLOGGING 작업 내용은 Redo 로그에 기록되지 않으므로, 장애 복구나 데이터베이스 복구 시 해당 내용이 복원되지 않을 수 있음. 특히, 백업 후 NOLOGGING 작업을 하면, 복구 시 해당 데이터에 대해 block corruption 등 오류가 발생할 수 있음.
    • 백업 필수: NOLOGGING 작업 이후, 반드시 전체 백업을 수행하는 것이 권장됨. 백업 전에 장애 발생 시 데이터 손실 가능.
    • 운영 시 다시 LOGGING 적용: 대량 작업 이후에는 반드시 LOGGING 모드로 원복하고 백업을 해야 함.
    • sql
      ALTER TABLE tablename LOGGING; ALTER INDEX idx_name LOGGING;
  • 적용되는 주요 작업:
    • Direct Path Insert
    • SQL*Loader를 사용한 direct load
    • CREATE TABLE AS SELECT
    • CREATE INDEX, ALTER INDEX REBUILD 등 인덱스 관련 대량 작업
    • 파티션 테이블의 MOVE, SPLIT, REBUILD 등

결론:
NOLOGGING은 대량 데이터 작업 시 필수적인 성능 최적화 도구이지만, 데이터 손실 위험이 있으므로 꼭 목적에 맞게 사용하고, 작업 후에는 전체 백업과 LOGGING 복원을 습관적으로 실행해야 데이터베이스의 무결성을 유지할 수 있습니다