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

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

이 글에서 다루는 내용

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

ORA-00354 corrupt redo log block header 는?

ORA-00354 에러는 Oracle 데이터베이스의 Redo Log 파일 블록 헤더가 손상(corrupt)되었을 때 발생하는 심각한 에러입니다. Redo Log는 데이터베이스 복구(Recovery)의 핵심 구성 요소이기 때문에, 이 에러가 발생하면 데이터베이스 정상 운영과 복구 작업 모두에 중대한 영향을 미칠 수 있습니다. 주로 디스크 I/O 오류, 하드웨어 장애, 또는 OS 레벨의 파일 시스템 문제로 인해 발생하며, 최악의 경우 데이터베이스 인스턴스가 비정상 종료(crash)되는 상황까지 이어질 수 있습니다.

주요 발생 원인

1. 디스크 또는 스토리지 하드웨어 장애

가장 빈번한 원인으로, 물리적 디스크 배드 섹터(bad sector), RAID 컨트롤러 오류, SAN/NAS 스토리지 장애 등이 Redo Log 블록 헤더를 손상시킵니다. 스토리지 레이어에서의 쓰기 오류(write error)는 Oracle이 Redo 정보를 기록하는 도중 블록의 헤더 정보를 불완전하게 남겨, 이후 읽기(read) 또는 복구(recovery) 시도 시 ORA-00354를 유발합니다. 이 경우 OS 레벨의 dmesg나 스토리지 벤더 로그를 함께 확인하는 것이 필수입니다.

2. 비정상적인 인스턴스 종료(Instance Crash)

전원 차단, OS 패닉(kernel panic), 또는 강제 프로세스 킬(kill -9) 등으로 Oracle 인스턴스가 비정상 종료된 경우, 현재 쓰기 중이던 Redo Log 블록의 헤더가 완전히 기록되지 않아 손상 상태로 남을 수 있습니다. Oracle은 정상 종료 시 체크포인트(checkpoint)를 수행하고 Redo Log를 안전하게 닫지만, 비정상 종료 시 이 과정이 생략되어 블록 헤더가 일관성을 잃게 됩니다. 이러한 상황에서 재기동 시 SMON 프로세스가 인스턴스 복구를 시도하다가 해당 에러를 만나게 됩니다.

3. OS 파일 시스템 오류 또는 볼륨 관리자 문제

ext4, XFS, NTFS 등의 파일 시스템 버그, 또는 LVM(Logical Volume Manager)/ASM 구성 오류로 인해 Redo Log 파일에 대한 I/O가 왜곡될 수 있습니다. 특히 파일 시스템 캐시 플러시(flush) 이슈나 비동기 I/O(Async I/O) 설정 오류는 Oracle이 블록을 쓰는 시점과 실제 디스크에 기록되는 시점 사이에 불일치를 만들어 헤더 손상을 야기합니다. 이 경우 fsck 또는 ASM 디스크 체크 명령어로 파일 시스템 무결성을 먼저 점검해야 합니다.

해결 방법

Step 1: 현재 Redo Log 상태 확인

먼저 어떤 Redo Log 그룹과 멤버가 문제인지 파악합니다.

-- Redo Log 그룹 및 상태 확인
SELECT GROUP#, SEQUENCE#, BYTES/1024/1024 AS SIZE_MB, MEMBERS, STATUS, ARCHIVED
FROM V$LOG
ORDER BY GROUP#;

-- Redo Log 멤버(파일) 경로 확인
SELECT GROUP#, MEMBER, STATUS, TYPE
FROM V$LOGFILE
ORDER BY GROUP#, MEMBER;

Step 2: 손상된 Redo Log가 INACTIVE 상태인 경우 (가장 안전한 시나리오)

해당 그룹이 INACTIVE(아카이브 완료) 상태라면, 해당 그룹을 삭제하고 재생성하면 됩니다.

-- 손상된 Redo Log 그룹 삭제 (예: GROUP# 2)
ALTER DATABASE DROP LOGFILE GROUP 2;

-- 새 Redo Log 그룹 추가 (멀티플렉싱 권장: 2개 멤버)
ALTER DATABASE ADD LOGFILE GROUP 2 
  ('/oradata/redo/redo02a.log', '/oradata/redo/redo02b.log') 
  SIZE 500M;

-- 정상 추가 확인
SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG WHERE GROUP# = 2;

Step 3: 손상된 Redo Log가 CURRENT 또는 ACTIVE 상태인 경우

현재 사용 중이거나 체크포인트가 완료되지 않은 경우로, 가장 위험한 시나리오입니다.

-- 로그 스위치를 강제로 수행하여 CURRENT 로그를 변경 시도
ALTER SYSTEM SWITCH LOGFILE;

-- 체크포인트 강제 수행
ALTER SYSTEM CHECKPOINT;

-- 상태 재확인
SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG;

만약 위 명령이 실패하고 DB가 마운트 상태에 머물러 있다면, 불완전 복구(Incomplete Recovery)를 시도해야 합니다.

-- RMAN을 이용한 불완전 복구 (손상된 Redo Log 이전 SCN까지)
-- 먼저 현재 SCN 확인
SELECT CURRENT_SCN FROM V$DATABASE;

-- RMAN 불완전 복구 수행
-- RMAN 접속 후:
-- RMAN> STARTUP MOUNT;
-- RMAN> RESTORE DATABASE;
-- RMAN> RECOVER DATABASE UNTIL SEQUENCE <손상된 시퀀스 번호> THREAD 1;
-- RMAN> ALTER DATABASE OPEN RESETLOGS;

-- SQL*Plus에서 RESETLOGS로 오픈 (복구 완료 후)
ALTER DATABASE OPEN RESETLOGS;

Step 4: 아카이브 로그 모드 확인 및 숨겨진 파라미터 활용

최후의 수단으로, Oracle 지원팀의 안내 하에 숨겨진 파라미터를 활용할 수 있습니다. 단, 반드시 Oracle Support와 협의 후 사용하세요.

-- 아카이브 로그 모드 확인
SELECT LOG_MODE FROM V$DATABASE;

-- 숨겨진 파라미터로 손상된 Redo Log 무시 (Oracle Support 권고 시에만 사용)
-- spfile 또는 pfile에 아래 파라미터 추가 후 재기동
-- _allow_resetlogs_corruption = TRUE  (극히 예외적 상황에서만, 데이터 손실 가능)

-- Alert log 위치 확인 (에러 분석용)
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

Step 5: Alert Log 및 trace 파일 분석

-- Alert log 경로 확인
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'background_dump_dest';

-- 또는 ADR 기반 시스템에서
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'ADR Home';

# OS에서 Alert log 실시간 모니터링
tail -f $ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/alert_<instance_name>.log | grep -E "ORA-|corrupt|error"

예방 방법

1. Redo Log 멀티플렉싱(Multiplexing) 및 충분한 그룹 수 유지

Redo Log 멀티플렉싱은 동일한 그룹에 2개 이상의 멤버(Member)를 서로 다른 디스크 경로에 배치하여, 하나의 멤버가 손상되어도 다른 멤버로 운영을 지속할 수 있게 하는 Oracle 공식 권장 방법입니다. 최소 2개의 멤버를 서로 다른 물리적 디스크 또는 ASM 디스크 그룹에 배치하고, Redo Log 그룹은 최소 3개 이상 유지하여 로그 스위치 경합과 아카이브 백로그를 방지해야 합니다.

-- 멀티플렉싱 설정 확인 및 추가
SELECT GROUP#, MEMBER FROM V$LOGFILE ORDER BY GROUP#;

-- 기존 그룹에 멤버 추가 (다른 경로에)
ALTER DATABASE ADD LOGFILE MEMBER '/oradata2/redo/redo01b.log' TO GROUP 1;
ALTER DATABASE ADD LOGFILE MEMBER '/oradata2/redo/redo02b.log' TO GROUP 2;
ALTER DATABASE ADD LOGFILE MEMBER '/oradata2/redo/redo03b.log' TO GROUP 3;

2. 정기적인 RMAN 백업 및 Redo Log 무결성 점검 자동화

RMAN을 이용한 정기 백업 스케줄을 수립하고, BACKUP VALIDATE 옵션으로 Redo Log를 포함한 모든 파일의 무결성을 주기적으로 검증해야 합니다. 또한 Oracle Enterprise Manager(OEM) 또는 커스텀 스크립트를 통해 V$LOG, V$LOGFILE 뷰를 모니터링하고, Redo Log 상태 이상 발생 시 즉시 알림을 받는 체계를 구축하는 것이 필수적입니다.

-- RMAN에서 Redo Log 포함 전체 검증
-- RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

-- 정기 모니터링 쿼리 (상태 이상 감지용)
SELECT GROUP#, STATUS, SEQUENCE#, 
       ROUND(BYTES/1024/1024,2) AS SIZE_MB,
       ARCHIVED
FROM V$LOG
WHERE STATUS NOT IN ('INACTIVE', 'CURRENT')
   OR (STATUS = 'ACTIVE' AND ARCHIVED = 'YES');