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

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

이 글에서 다루는 내용

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

ORA-00290 operating system archival error occurred 는?

ORA-00290은 Oracle 데이터베이스가 아카이브 로그 파일을 운영체제 레벨에서 기록하거나 처리하는 과정에서 발생하는 오류입니다. 주로 ARCHIVELOG 모드로 운영 중인 데이터베이스에서 아카이빙 프로세스(ARCn)가 리두 로그를 아카이브 목적지에 복사할 때 OS 수준의 장애가 발생할 경우 나타납니다. 이 에러는 데이터베이스 운영 연속성에 직접적인 영향을 미칠 수 있으며, 방치할 경우 리두 로그 그룹이 재사용되지 못해 결국 데이터베이스가 멈추는 심각한 상황으로 이어질 수 있습니다.

주요 발생 원인

아카이브 목적지 디스크 공간 부족

가장 흔한 원인입니다. LOG_ARCHIVE_DEST_n 파라미터로 지정된 경로의 파일시스템 공간이 꽉 찬 경우, ARCn 프로세스가 아카이브 파일을 생성하지 못하면서 ORA-00290이 발생합니다. DBA가 디스크 모니터링을 소홀히 하거나 아카이브 파일 정리 정책이 없을 때 빈번하게 발생하며, 운영 환경에서는 특히 배치 작업이 몰리는 야간에 갑자기 터지는 경우가 많습니다.

아카이브 목적지 경로의 권한 문제 또는 경로 오류

Oracle 프로세스가 실행되는 OS 계정(보통 oracle)이 아카이브 목적지 디렉토리에 대한 쓰기 권한을 가지지 못하는 경우에도 이 에러가 발생합니다. 또한 파라미터에 지정된 경로 자체가 존재하지 않거나, 심볼릭 링크가 끊어졌거나, NFS 마운트가 해제된 상황에서도 동일한 현상이 나타납니다. 운영 환경 변경(서버 재부팅, 스토리지 재구성 등) 후에 특히 주의가 필요합니다.

아카이브 프로세스(ARCn) 수 부족 또는 내부 오류

리두 로그 스위치가 매우 빠르게 발생하는 고부하 환경에서 ARCn 프로세스의 수가 부족할 경우, 아카이빙 큐가 밀리면서 OS 레벨 오류로 이어질 수 있습니다. Oracle은 기본적으로 자동으로 ARCn을 늘려주지만, LOG_ARCHIVE_MAX_PROCESSES 파라미터가 낮게 설정되어 있거나 ARCn 프로세스 자체에 내부적인 이상이 생긴 경우에도 ORA-00290이 발생할 수 있습니다.

해결 방법

원인 1: 디스크 공간 부족 해결

현재 아카이브 로그 목적지와 사용 현황을 먼저 확인합니다.

-- 아카이브 로그 목적지 확인
SHOW PARAMETER log_archive_dest;

-- 아카이브 로그 현황 조회
SELECT DEST_ID, DEST_NAME, STATUS, TARGET, ARCHIVER, SCHEDULE,
       DESTINATION, FAIL_COUNT, ERROR
FROM   V$ARCHIVE_DEST
WHERE  STATUS != 'INACTIVE';

-- 아카이브 로그 파일 크기 및 생성 현황
SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24') AS ARCH_HOUR,
       COUNT(*)                               AS LOG_COUNT,
       ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024, 2) AS SIZE_MB
FROM   V$ARCHIVED_LOG
WHERE  FIRST_TIME >= SYSDATE - 1
GROUP  BY TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24')
ORDER  BY 1;

디스크 공간 확보 후 RMAN을 이용해 불필요한 아카이브 로그를 정리합니다.

-- RMAN으로 오래된 아카이브 로그 삭제 (7일 이전)
-- RMAN 접속 후 실행
-- RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';

-- 특정 시퀀스 이전 아카이브 로그 삭제
-- RMAN> DELETE ARCHIVELOG UNTIL SEQUENCE 1500 THREAD 1;

-- 백업 완료된 아카이브 로그만 삭제 (안전한 방법)
-- RMAN> DELETE BACKUP COMPLETED BEFORE 'SYSDATE-7';
-- RMAN> DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DISK;

원인 2: 권한 및 경로 문제 해결

-- 현재 아카이브 목적지 경로 확인
SELECT NAME, VALUE
FROM   V$PARAMETER
WHERE  NAME LIKE 'log_archive_dest%'
AND    VALUE IS NOT NULL;

-- 아카이브 목적지 경로를 유효한 경로로 재설정
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=/arch/oradata/ORCL'
    SCOPE=BOTH;

-- 복수 목적지 설정 (이중화)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'LOCATION=/arch2/oradata/ORCL MANDATORY'
    SCOPE=BOTH;

-- 아카이브 관련 상태 재확인
SELECT DEST_ID, STATUS, DESTINATION, FAIL_COUNT, ERROR
FROM   V$ARCHIVE_DEST
WHERE  DEST_ID IN (1, 2);

OS 레벨에서 권한을 확인하고 조치합니다.

-- OS 레벨 명령어 (SQL*Plus 호스트 명령 또는 터미널에서 실행)
-- $ ls -ld /arch/oradata/ORCL
-- $ chown oracle:oinstall /arch/oradata/ORCL
-- $ chmod 755 /arch/oradata/ORCL

-- 아카이빙 일시 중단 후 재개 (긴급 조치)
ALTER SYSTEM ARCHIVE LOG STOP;
ALTER SYSTEM ARCHIVE LOG START;

원인 3: ARCn 프로세스 조정

-- 현재 ARCn 프로세스 수 확인
SHOW PARAMETER log_archive_max_processes;

-- ARCn 프로세스 최대 수 증가 (최대 30)
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = 10 SCOPE=BOTH;

-- 현재 아카이브 프로세스 상태 확인
SELECT PROCESS, STATUS, LOG#, SEQUENCE#, BLOCKS, BLOCK_SIZE
FROM   V$MANAGED_STANDBY
WHERE  PROCESS LIKE 'ARC%';

-- 백그라운드 프로세스 상태 확인
SELECT PNAME, DESCRIPTION, ERROR
FROM   V$BGPROCESS
WHERE  PNAME LIKE 'ARC%'
AND    PADDR != '00';

-- 아카이브 목적지 에러 상세 확인
SELECT DEST_ID, DEST_NAME, STATUS, ERROR, FAIL_SEQUENCE, FAIL_BLOCK
FROM   V$ARCHIVE_DEST_STATUS
WHERE  STATUS != 'INACTIVE';

예방 방법

아카이브 로그 모니터링 및 자동 정리 정책 수립

아카이브 로그 디스크 사용률을 주기적으로 모니터링하는 스크립트 또는 Oracle Enterprise Manager 임계치 알람을 설정하십시오. 디스크 사용률이 70~80%를 초과하면 즉시 알림이 오도록 구성하고, RMAN 백업 스크립트에 아카이브 로그 삭제 루틴을 포함시켜 백업 완료 후 자동으로 정리되도록 합니다. Fast Recovery Area(FRA)를 활용하면 Oracle이 자동으로 공간을 관리해주므로 운영 편의성이 크게 향상됩니다.

“`sql

— Fast Recovery Area 설정 (권장)

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = ‘/fra/oradata’ SCOPE=BOTH;

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G SCOPE=BOTH;

— FRA 사용 현황 확인

SELECT SPACE_LIMIT / 1024 / 1024 / 1024 AS LIMIT_GB,

SPACE_USED / 1024 / 1024 / 1024 AS USED_GB,

SPACE_RECLAIMABLE / 1024 / 1024 / 1024 AS RECLAIMABLE_GB,

NUMBER_OF_FILES

FROM V$RECOVERY_FILE_DEST;

“`

아카이브 목적지 이중화 및 정기 점검

단일 아카이브 목적지는 단일 장애점(SPOF)이 됩니다. LOG_ARCHIVE_DEST_1과 LOG_ARCHIVE_DEST_2를 서로 다른 물리적 경로 또는 스토리지에 구성하여 하나가 실패해도 다른 하나가 아카이빙을 계속할 수 있도록 설정하십시오. 또한 월 1회 이상 아카이브 목적지 경로의 접근 권한, 마운트 상태, NFS 연결 상태 등을 점검하는 정기 점검 프로세스를 수립하면 사전에 문제를 예방할 수 있습니다.