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

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

이 글에서 다루는 내용

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

ORA-00333 redo log read error block count 는?

ORA-00333은 Oracle 데이터베이스가 리두 로그(Redo Log) 파일을 읽는 도중 블록 수(block count) 불일치 또는 읽기 오류가 발생했을 때 나타나는 에러입니다. 주로 데이터베이스 복구(Recovery) 과정 또는 인스턴스 재시작 시 리두 로그를 적용하려 할 때 발생하며, 심각한 경우 데이터베이스가 OPEN 상태로 전환되지 못하는 상황을 초래합니다. 이 에러는 단독으로 발생하기보다 ORA-00334, ORA-00314 등 다른 리두 로그 관련 에러와 함께 나타나는 경우가 많아, alert log와 trace 파일을 함께 분석하는 것이 중요합니다.

주요 발생 원인

1. 리두 로그 파일의 물리적 손상 또는 미디어 오류

가장 빈번한 원인으로, 디스크 하드웨어 장애, 파일 시스템 오류, 또는 스토리지 레벨의 I/O 오류로 인해 리두 로그 파일 자체가 물리적으로 손상된 경우입니다. OS 레벨에서 파일 복사나 읽기 테스트를 수행했을 때 에러가 발생한다면 이 원인일 가능성이 높습니다. 이 경우 멀티플렉싱된 리두 로그 멤버가 있다면 해당 멤버로 복구를 시도할 수 있습니다.

2. 비정상적인 데이터베이스 종료(Abnormal Shutdown)로 인한 불완전한 리두 로그

정전, OS 크래시, 강제 kill 등 비정상적인 방식으로 Oracle 인스턴스가 종료되었을 때 현재 활성화된 온라인 리두 로그(Online Redo Log)가 완전하게 기록되지 못한 상태로 남을 수 있습니다. 이후 인스턴스를 재시작하면서 Oracle이 해당 리두 로그를 롤포워드(Roll Forward)하려 할 때 블록 수가 맞지 않아 ORA-00333이 발생합니다. LGWR 프로세스가 로그를 디스크에 완전히 플러시하기 전에 인스턴스가 다운된 경우가 대표적입니다.

3. 아카이브 로그 모드에서의 복구 중 아카이브 리두 로그 손상

ARCHIVELOG 모드로 운영 중인 데이터베이스에서 미디어 복구(Media Recovery)를 수행할 때, 적용해야 할 아카이브 리두 로그 파일이 손상되었거나 불완전한 경우에도 ORA-00333이 발생할 수 있습니다. 백업 미디어 오류, 네트워크 전송 중 파일 손상, 또는 아카이브 저장소의 디스크 오류 등이 원인이 될 수 있습니다. 이 경우 해당 아카이브 로그의 대체 사본이 있는지 먼저 확인해야 합니다.

해결 방법

해결책 1: 현재 리두 로그 상태 및 파일 경로 확인

먼저 alert log와 함께 아래 쿼리로 리두 로그 그룹 및 멤버 상태를 확인합니다.

-- 리두 로그 그룹 상태 확인
SELECT GROUP#, SEQUENCE#, MEMBERS, STATUS, ARCHIVED
FROM V$LOG
ORDER BY GROUP#;

-- 리두 로그 멤버(파일) 경로 및 상태 확인
SELECT l.GROUP#, l.SEQUENCE#, lm.MEMBER, lm.STATUS, l.STATUS AS LOG_STATUS
FROM V$LOG l
JOIN V$LOGFILE lm ON l.GROUP# = lm.GROUP#
ORDER BY l.GROUP#, lm.MEMBER;

이 쿼리를 통해 손상된 그룹의 GROUP# 및 SEQUENCE#를 확인하고, 물리적 파일 경로를 파악합니다.

해결책 2: 멀티플렉싱 멤버로 복구 시도

리두 로그 그룹에 멀티플렉싱된 멤버가 있다면, 손상되지 않은 멤버를 이용해 데이터베이스를 오픈할 수 있습니다.

-- 손상된 멤버 확인 후 정상 멤버 식별
SELECT GROUP#, MEMBER, STATUS FROM V$LOGFILE WHERE STATUS = 'INVALID';

-- 손상된 멤버를 그룹에서 제거 (정상 멤버가 남아있을 때)
ALTER DATABASE DROP LOGFILE MEMBER '/u01/oradata/redo01a.log';

-- 새 멤버 추가 (복구 후 멀티플렉싱 재구성)
ALTER DATABASE ADD LOGFILE MEMBER '/u01/oradata/redo01b.log'
TO GROUP 1;

해결책 3: 비정상 종료 후 RESETLOGS를 이용한 불완전 복구

현재 온라인 리두 로그가 손상된 경우, 리두 로그 없이 불완전 복구 후 RESETLOGS로 데이터베이스를 오픈하는 방법을 사용할 수 있습니다. 이 방법은 데이터 손실을 감수해야 하며 최후의 수단으로 사용해야 합니다.

-- MOUNT 상태에서 불완전 복구 수행
STARTUP MOUNT;

-- 취소 기반 복구 수행 (현재 로그 이전까지만 복구)
RECOVER DATABASE UNTIL CANCEL;
-- 프롬프트에서 CANCEL 입력

-- RESETLOGS로 데이터베이스 오픈 (새로운 리두 로그 시퀀스 시작)
ALTER DATABASE OPEN RESETLOGS;

-- RESETLOGS 후 리두 로그 상태 재확인
SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG;

해결책 4: 내부 파라미터를 이용한 강제 오픈 (최후 수단)

위 방법으로도 해결이 안 된다면, Oracle Support의 지시 하에 내부 파라미터를 사용하여 복구를 시도할 수 있습니다. 이 방법은 반드시 Oracle Support의 SR(Service Request)을 통해 진행해야 합니다.

-- init.ora 또는 spfile에 아래 파라미터 추가 (Oracle Support 지시 하에)
-- _allow_resetlogs_corruption=TRUE (Oracle 10g 이하)
-- _no_recovery_through_resetlogs=TRUE

-- spfile을 사용하는 경우 pfile로 변환 후 수정
CREATE PFILE='/tmp/init_emergency.ora' FROM SPFILE;

-- pfile 수정 후 MOUNT로 기동
STARTUP MOUNT PFILE='/tmp/init_emergency.ora';

-- 복구 완료 후 반드시 해당 파라미터 제거 및 정상화
ALTER SYSTEM RESET "_allow_resetlogs_corruption" SCOPE=SPFILE;

해결책 5: 아카이브 로그 복구 시 대체 파일 적용

아카이브 로그 손상 시 동일한 시퀀스의 아카이브 로그를 다른 경로에서 복사하여 적용합니다.

-- 현재 복구에 필요한 아카이브 로그 시퀀스 확인
SELECT NAME, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#, STATUS
FROM V$ARCHIVED_LOG
WHERE STANDBY_DEST = 'NO'
ORDER BY SEQUENCE#;

-- 아카이브 로그 위치 확인
SHOW PARAMETER LOG_ARCHIVE_DEST;

-- 수동으로 특정 아카이브 로그 파일을 지정하여 복구
RECOVER DATABASE USING BACKUP CONTROLFILE
UNTIL SEQUENCE 150 THREAD 1;
-- 프롬프트에서 대체 파일 경로 입력 또는 AUTO 입력

예방 방법

1. 리두 로그 멀티플렉싱 및 충분한 그룹/사이즈 구성

리두 로그 그룹마다 서로 다른 물리적 디스크(또는 스토리지 경로)에 최소 2개 이상의 멤버를 구성하는 멀티플렉싱을 반드시 적용해야 합니다. 또한 리두 로그 사이즈를 충분히 크게 설정하여 빈번한 로그 스위치를 방지하고, 최소 3개 이상의 리두 로그 그룹을 운영하는 것이 Best Practice입니다.

-- 리두 로그 멀티플렉싱 구성 예시
ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/oradata/redo04a.log', '/u02/oradata/redo04b.log')
SIZE 500M;

-- 기존 그룹에 멤버 추가
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oradata/redo01b.log'
TO GROUP 1;

-- 현재 리두 로그 구성 최종 확인
SELECT l.GROUP#, lm.MEMBER, l.BYTES/1024/1024 AS SIZE_MB, l.STATUS
FROM V$LOG l JOIN V$LOGFILE lm ON l.GROUP# = lm.GROUP#
ORDER BY l.GROUP#;

2. 정기적인 백업 및 Alert Log 모니터링 자동화

RMAN을 이용한 정기적인 전체 백업과 아카이브 로그 백업을 스케줄링하고, alert log에서 ORA- 에러를 자동으로 감지하는 모니터링 체계를 구축해야 합니다. 특히 데이터베이스 종료 전에는 반드시 SHUTDOWN IMMEDIATE 또는 SHUTDOWN NORMAL 명령을 사용하고, 강제 종료(SHUTDOWN ABORT)는 피하는 것이 중요합니다.

-- RMAN을 이용한 정기 백업 스크립트 예시
-- (cron 또는 스케줄러로 주기적 실행)
RMAN TARGET /
RUN {
  BACKUP DATABASE PLUS ARCHIVELOG;
  DELETE NOPROMPT OBSOLETE;
}

-- 데이터베이스 정상 종료 (권장)
SHUTDOWN IMMEDIATE;