Oracle 19c Flashback Query ORA-01555: UNDO 보존 시간과 공간 압박을 확인하는 순서

Oracle 19c에서 AS OF TIMESTAMP로 과거 데이터를 읽다가 ORA-01555가 나면, 그 시점의 행 버전을 되살리는 데 필요한 undo가 이미 재사용된 상태입니다. 먼저 같은 Flashback Query를 반복 실행하지 말고, 요청한 과거 시점과 실제 보존 가능 시간, 해당 시간대의 undo 압박을 함께 확인해야 합니다.

이 글은 Automatic Undo Management를 쓰는 Oracle Database 19c를 대상으로 합니다. Flashback Query는 Flashback Database와 다른 기능이며, DB_FLASHBACK_RETENTION_TARGET을 바꿔도 쿼리에 필요한 undo가 돌아오지 않습니다. 이미 덮어써진 undo는 설정만 바꿔서 복구할 수 없습니다.

적용 조건과 영향 범위

ORA-01555를 Flashback 설정 오류로 단정하면 안 되는 이유

Oracle은 일관 읽기를 위해 변경 전 값을 undo에 보관합니다. Flashback Query는 그 undo를 사용해 지정한 시점의 데이터 블록을 재구성합니다. 그래서 오류의 직접 원인은 ‘과거 데이터가 오래되었다’가 아니라, 읽는 쪽이 필요로 하는 undo를 쓰는 쪽이 먼저 재사용한 것입니다.

UNDO_RETENTION은 초 단위의 낮은 보존 기준입니다. 19c의 동작은 undo tablespace 구성과 릴리스 업데이트에 따라 자동 조정의 세부가 다르며, 공간이 부족하면 미만료 undo도 재사용될 수 있습니다. 특히 LOB의 보존은 별도 제약이 있으므로 일반 테이블의 관찰 결과를 그대로 적용하지 않습니다.

안전한 최소 재현

테스트 전용 스키마에서만 아래 구조를 만듭니다. 운영 테이블에 대량 UPDATE를 넣어 오류를 재현하려 하면 실제 undo 압박과 업무 지연을 만들 수 있습니다.

CREATE TABLE lab_orders (
  order_id    NUMBER PRIMARY KEY,
  order_state VARCHAR2(20) NOT NULL,
  changed_at  TIMESTAMP    NOT NULL
);

INSERT INTO lab_orders (order_id, order_state, changed_at)
VALUES (1001, 'PAID', SYSTIMESTAMP);
COMMIT;

SELECT order_id, order_state, changed_at
  FROM lab_orders AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '5' MINUTE)
 WHERE order_id = 1001;

실행 전에는 요청 시점과 현재 보존 능력을 나란히 본다

복구 요청이 ‘오전 9시 데이터’처럼 들어오면 먼저 그 시점을 기록합니다. 그 뒤 파라미터의 희망값과 실제로 조정된 보존 시간, 긴 쿼리 길이, 공간 부족 횟수를 조회합니다. 단일 시점의 최신 행만 읽으면 야간 배치처럼 이미 지나간 피크를 놓칠 수 있습니다.

SELECT p.value AS undo_retention_seconds
  FROM v$parameter p
 WHERE p.name = 'undo_retention';

SELECT u.begin_time,
       u.end_time,
       u.tuned_undoretention,
       u.maxquerylen,
       u.nospaceerrcnt,
       u.undoblks,
       u.txncount
  FROM v$undostat u
 ORDER BY u.end_time DESC
 FETCH FIRST 24 ROWS ONLY;

작업 전 확인표

실패한 Flashback Query의 다음 단계

오류가 난 SQL의 대상 시간, 테이블, 조건을 보존한 다음 더 작은 범위로 원인을 확인합니다. 조회 조건을 좁히는 일은 필요한 과거 undo 자체를 되살리지는 않지만, 전체 테이블 Flashback Query로 불필요하게 긴 일관 읽기 창을 만들지 않게 합니다. 업무가 요구한 결과가 테이블 단위 복구인지, 단순 비교 조회인지도 여기서 결정합니다.

SELECT tablespace_name,
       retention,
       status
  FROM dba_tablespaces
 WHERE contents = 'UNDO';

SELECT tablespace_name,
       file_name,
       bytes / 1024 / 1024 AS size_mb,
       autoextensible,
       maxbytes / 1024 / 1024 AS max_mb
  FROM dba_data_files
 WHERE tablespace_name = (SELECT value
                            FROM v$parameter
                           WHERE name = 'undo_tablespace');

보존 시간을 늘릴 때의 롤백 경계

향후 Flashback Query 창을 늘리려면 업무가 요구하는 최대 과거 시점과 피크 DML을 기준으로 설계합니다. ALTER SYSTEM SET undo_retention = ...은 시스템 설정 변경이므로, 장애 중 즉흥 실행하지 않습니다. 먼저 현재 undo tablespace의 여유와 자동 확장 상한, 오래 걸리는 쿼리, LOB 사용 여부를 검토하고 변경 승인을 받습니다.

-- 변경 승인과 용량 검토가 끝난 뒤에만 실행하는 예시
ALTER SYSTEM SET undo_retention = 7200 SCOPE = BOTH;

SELECT u.end_time,
       u.tuned_undoretention,
       u.maxquerylen,
       u.nospaceerrcnt
  FROM v$undostat u
 ORDER BY u.end_time DESC
 FETCH FIRST 12 ROWS ONLY;

흔한 실수

• DB_FLASHBACK_RETENTION_TARGET만 늘린다. 이는 Flashback Database의 목표 창이며 Flashback Query의 undo를 대신하지 않습니다.
• UNDO_RETENTION 값을 성공 보증으로 본다. 공간 압박이 있으면 미만료 undo도 재사용될 수 있습니다.
• 현재 V$UNDOSTAT 한 행만 보고 과거 장애를 판단한다. 이 뷰는 10분 단위 이력이므로 요청 시간대 전후를 비교해야 합니다.
• ORA-01555 뒤에 운영 데이터의 대량 UPDATE로 재현한다. 진단을 위해 더 큰 undo 문제를 만들 수 있습니다.
• Flashback Query 실패를 곧바로 데이터 영구 손실로 단정한다. 백업, 아카이브, 감사 로그와 복구 목표를 먼저 분리합니다.

마무리

ORA-01555는 ‘보존 시간이 부족했다’는 단순 경고가 아니라, 특정 읽기가 필요한 undo를 확보하지 못했다는 신호입니다. 요청 시점을 고정하고 해당 시간대의 undo 통계를 읽으면, 재시도할 조회와 별도 복구 경로를 찾아야 할 상황을 구분할 수 있습니다. 이후 보존 창은 숫자 하나가 아니라 undo 공간과 피크 쓰기 부하를 함께 관리해야 유지됩니다.

공식 출처

• Oracle Database Error Messages: ORA-01555
• Oracle Database Development Guide: Using Oracle Flashback Technology
• Oracle Database Reference: UNDO_RETENTION
• Oracle Database Reference: V$UNDOSTAT