Oracle ORA-00279 오류 원인과 해결 방법 완벽 가이드

ORA-00279
2026년 06월 05일 | DBMS Error 가이드

이 글에서 다루는 내용

ORA-00279 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

ORA-00279 change generated needed for thread 는?

ORA-00279는 Oracle 데이터베이스의 불완전 복구(Incomplete Recovery) 또는 Standby Database 복구 과정에서 발생하는 에러로, 특정 SCN(System Change Number) 이후의 변경 사항을 적용하기 위해 추가적인 아카이브 로그 파일이 필요하다는 것을 알려주는 메시지입니다. 이 에러는 단순한 오류라기보다는 Oracle이 복구 작업을 진행하면서 다음 로그 파일을 요청하는 정보성 메시지에 가깝습니다. 주로 RECOVER DATABASE, RECOVER TABLESPACE, 또는 RECOVER DATAFILE 명령 수행 중에 자주 마주치게 됩니다.

주요 발생 원인

아카이브 로그 파일 경로 불일치 또는 파일 누락

복구 작업 시 Oracle이 다음 순서의 아카이브 로그 파일을 찾지 못할 경우 ORA-00279가 발생합니다. 아카이브 로그가 다른 디스크나 디렉토리로 이동되었거나, 백업 후 삭제된 경우에 주로 나타납니다. 특히 여러 개의 아카이브 로그 목적지(LOG_ARCHIVE_DEST_n)가 설정된 환경에서 특정 경로의 파일이 없을 때 복구 프로세스가 중단되고 이 메시지가 출력됩니다.

불완전 복구(Point-In-Time Recovery) 수행 중 로그 파일 요청

특정 시점으로 데이터베이스를 복구할 때, Oracle은 해당 시점까지의 모든 아카이브 로그를 순차적으로 적용해야 합니다. 백업본에서 복원한 후 아카이브 로그를 하나씩 적용하는 과정에서, 다음에 필요한 로그 파일을 자동으로 찾지 못하면 ORA-00279와 함께 ORA-00280(아카이브 로그 순서 정보), ORA-00278(더 이상 필요 없는 아카이브 로그 정보) 메시지가 함께 출력됩니다.

Data Guard Standby Database 로그 적용 지연 또는 갭(Gap) 발생

Data Guard 환경에서 Primary와 Standby 간 네트워크 단절이나 FAL(Fetch Archive Log) 서버 설정 오류로 인해 아카이브 로그가 Standby 측에 전달되지 않으면, MRP(Managed Recovery Process) 프로세스가 필요한 로그를 요청하면서 ORA-00279가 발생합니다. 이 경우 V$ARCHIVE_GAP 뷰를 통해 누락된 로그 번호를 확인하고, Primary에서 수동으로 해당 로그를 전송해야 합니다.

해결 방법

원인 1: 아카이브 로그 파일 위치 수동 지정

복구 중 Oracle이 아카이브 로그 파일을 자동으로 찾지 못할 경우, RMAN 또는 SQL*Plus에서 수동으로 파일 경로를 지정할 수 있습니다.

-- SQL*Plus에서 수동 복구 시 파일 경로 직접 지정
RECOVER DATABASE;
-- Oracle이 ORA-00279 메시지와 함께 로그 파일을 요청하면:
-- ORA-00279: change 1234567 generated at 01/15/2025 10:00:00 needed for thread 1
-- ORA-00280: change 1234567 for thread 1 is in sequence #105
-- 아래와 같이 해당 아카이브 로그 파일 경로를 입력
-- Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/arch/arch_1_105_XXXXXXXX.arc

-- RMAN을 사용하는 경우 아카이브 로그 카탈로그 등록 후 복구
RMAN> CATALOG START WITH '/backup/archive/';
RMAN> RECOVER DATABASE;

원인 2: 불완전 복구 시 자동 복구 옵션 사용

AUTO 옵션을 사용하면 Oracle이 설정된 아카이브 로그 경로에서 자동으로 파일을 찾아 적용합니다.

-- SQL*Plus에서 자동 복구 수행
RECOVER AUTOMATIC DATABASE;

-- 또는 특정 시점까지만 복구 (Point-In-Time Recovery)
RECOVER DATABASE UNTIL TIME '2025-01-15:09:00:00';

-- 특정 SCN까지 복구
RECOVER DATABASE UNTIL CHANGE 1234567;

-- 특정 로그 순서까지 복구
RECOVER DATABASE UNTIL SEQUENCE 105 THREAD 1;

-- 복구 완료 후 데이터베이스 오픈 (불완전 복구 시 RESETLOGS 필수)
ALTER DATABASE OPEN RESETLOGS;

원인 3: Data Guard 환경에서 아카이브 갭 해결

-- Standby에서 갭 확인
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

-- Primary에서 누락된 아카이브 로그 확인
SELECT NAME, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
FROM V$ARCHIVED_LOG
WHERE SEQUENCE# BETWEEN 100 AND 110
AND THREAD# = 1;

-- Primary에서 특정 아카이브 로그를 Standby로 수동 전송
ALTER SYSTEM ARCHIVE LOG SEQUENCE 105 THREAD 1;

-- Standby에서 아카이브 로그 수동 등록 후 복구 재개
ALTER DATABASE REGISTER LOGFILE '/arch/arch_1_105_XXXXXXXX.arc';
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

-- RMAN을 활용한 Standby 아카이브 갭 자동 해결
RMAN> CONNECT TARGET sys@primary
RMAN> CONNECT AUXILIARY sys@standby
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK;

예방 방법

아카이브 로그 보존 정책 및 백업 자동화 설정

복구 시 필요한 아카이브 로그가 항상 접근 가능하도록 RMAN의 CONFIGURE ARCHIVELOG DELETION POLICY를 설정하고, 정기적인 아카이브 로그 백업을 자동화해야 합니다. 아카이브 로그를 삭제하기 전에 반드시 백업이 완료되었는지 확인하는 정책을 수립하세요.

“`sql

— RMAN 아카이브 로그 삭제 정책 설정 (백업 후에만 삭제 허용)

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

— 아카이브 로그 보존 기간 설정 (7일)

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

“`

Data Guard FAL 서버 및 아카이브 로그 목적지 이중화 설정

Data Guard 환경에서는 FAL_SERVER, FAL_CLIENT 파라미터를 정확하게 설정하고, LOG_ARCHIVE_DEST_n을 이중화하여 아카이브 로그 전달 실패를 최소화해야 합니다. 주기적으로 V$ARCHIVE_GAP 뷰를 모니터링하는 스크립트를 운영하여 갭 발생 즉시 알림을 받도록 구성하는 것이 Best Practice입니다.

“`sql

— Primary에서 FAL 및 아카이브 목적지 설정 확인

SHOW PARAMETER FAL_SERVER;

SHOW PARAMETER LOG_ARCHIVE_DEST;

— 아카이브 갭 모니터링 쿼리 (운영 스크립트로 활용)

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE#,

(HIGH_SEQUENCE# – LOW_SEQUENCE# + 1) AS GAP_COUNT

FROM V$ARCHIVE_GAP

ORDER BY THREAD#;

“`