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

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

이 글에서 다루는 내용

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

ORA-00470 LGWR process terminated with error 는?

ORA-00470은 Oracle 데이터베이스의 핵심 백그라운드 프로세스 중 하나인 LGWR(Log Writer) 프로세스가 비정상적으로 종료되었을 때 발생하는 치명적인 에러입니다. LGWR 프로세스는 SGA의 Redo Log Buffer에 쌓인 변경 내용을 온라인 Redo Log 파일에 기록하는 역할을 담당하며, 이 프로세스가 중단되면 데이터베이스 전체가 즉시 다운됩니다. 일반적으로 alert.log 파일에 ORA-00470과 함께 추가적인 에러 메시지가 기록되며, 이는 데이터 손실 가능성이 있는 매우 심각한 장애 상황입니다.

주요 발생 원인

1. Redo Log 파일 손상 또는 접근 불가

온라인 Redo Log 파일이 저장된 디스크에 I/O 오류가 발생하거나, 파일 시스템 권한 문제, 디스크 공간 부족 등으로 LGWR 프로세스가 로그 파일에 쓰기를 수행하지 못할 때 가장 빈번하게 발생합니다. Redo Log 파일은 Multiplexing 구성이 없는 경우 단일 장애점(Single Point of Failure)이 되어 LGWR 프로세스를 강제 종료시킬 수 있습니다. 특히 스토리지 레이어의 갑작스러운 장애나 NFS 마운트 해제 상황에서 자주 목격됩니다.

2. 운영체제 레벨 자원 부족 (OS Resource Exhaustion)

운영체제의 파일 디스크립터(File Descriptor) 한도 초과, 메모리 부족(Out of Memory), 또는 OS 커널 파라미터 설정 오류로 인해 LGWR 프로세스가 정상적인 파일 I/O를 수행하지 못하는 경우가 있습니다. Linux/Unix 환경에서는 /proc/sys/fs/file-max 값이 너무 낮거나 ulimit 설정이 Oracle 권장값보다 낮게 설정된 경우 이 문제가 발생할 수 있습니다. OS 레벨의 OOM Killer가 LGWR 프로세스를 강제로 종료하는 사례도 실무에서 드물지 않게 관찰됩니다.

3. Oracle 내부 버그 또는 메모리 오염 (Memory Corruption)

Oracle 소프트웨어 자체의 버그, SGA 메모리 영역의 오염, 또는 잘못된 초기화 파라미터 설정으로 인해 LGWR 프로세스가 예기치 않게 종료될 수 있습니다. 특히 LOG_BUFFER, DB_BLOCK_SIZE 등의 파라미터가 잘못 설정되거나, 특정 Oracle 패치 미적용 상태에서 알려진 버그가 트리거되는 경우에 해당합니다. 이 경우 alert.log와 함께 LGWR trace 파일에 상세한 내부 오류 스택이 기록됩니다.

해결 방법

1단계: alert.log 및 Trace 파일 즉시 확인

장애 발생 직후 가장 먼저 alert.log를 확인하여 ORA-00470 이전에 기록된 연관 에러를 파악해야 합니다.

-- alert.log 위치 확인
SELECT value FROM v$parameter WHERE name = 'background_dump_dest';

-- 또는 ADR 경로 확인 (11g 이상)
SELECT value FROM v$diag_info WHERE name = 'Diag Trace';

2단계: Redo Log 파일 상태 및 경로 점검

-- 온라인 Redo Log 그룹 및 멤버 상태 확인
SELECT a.group#, a.members, a.status, b.member, b.status AS member_status
FROM v$log a
JOIN v$logfile b ON a.group# = b.group#
ORDER BY a.group#;

-- Redo Log 파일의 실제 크기 및 아카이브 상태 확인
SELECT group#, sequence#, bytes/1024/1024 AS size_mb, status, archived
FROM v$log
ORDER BY group#;

3단계: Redo Log Multiplexing 구성 (손상된 경우 복구)

-- 새 Redo Log 멤버 추가 (Multiplexing)
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oradata/redo01b.log' TO GROUP 1;
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oradata/redo02b.log' TO GROUP 2;
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oradata/redo03b.log' TO GROUP 3;

-- 손상된 Redo Log 그룹이 INACTIVE 상태인 경우 삭제 후 재생성
-- (CURRENT 또는 ACTIVE 상태인 경우 절대 삭제 불가)
ALTER DATABASE DROP LOGFILE GROUP 4;
ALTER DATABASE ADD LOGFILE GROUP 4 
  ('/u01/oradata/redo04a.log', '/u02/oradata/redo04b.log') 
  SIZE 500M;

4단계: 디스크 공간 및 파일시스템 점검 후 DB 재기동

-- 데이터베이스 재기동 절차
SHUTDOWN ABORT;  -- 이미 다운된 경우 불필요

-- OS 레벨에서 디스크 공간 확인 후
STARTUP MOUNT;

-- Redo Log 파일 접근 가능 여부 확인
SELECT * FROM v$logfile WHERE status = 'INVALID' OR status = 'STALE';

-- 정상 확인 후 OPEN
ALTER DATABASE OPEN;

5단계: LGWR Trace 파일 분석 및 Oracle SR 오픈

-- 최근 생성된 trace 파일 목록 확인 (11g 이상)
SELECT value || '/lgwr_' || (SELECT instance_name FROM v$instance) || '*.trc'
FROM v$diag_info
WHERE name = 'Diag Trace';

-- incident 정보 확인
SELECT incident_id, create_time, incident_status, problem_key
FROM v$diag_incident
ORDER BY create_time DESC
FETCH FIRST 10 ROWS ONLY;

예방 방법

1. Redo Log Multiplexing 및 정기적 모니터링 자동화

Redo Log 파일은 반드시 서로 다른 물리적 디스크에 최소 2개 이상의 멤버로 Multiplexing 구성해야 합니다. 아래 스크립트를 cron 또는 Oracle Scheduler에 등록하여 Redo Log 상태를 주기적으로 점검하고 이상 발생 시 즉시 알림을 받도록 설정하는 것이 Best Practice입니다.

-- Redo Log 상태 모니터링 쿼리 (주기적 실행 권장)
SELECT 
    l.group#,
    l.sequence#,
    l.bytes/1024/1024 AS size_mb,
    l.members,
    l.status,
    l.archived,
    f.member AS log_file_path,
    f.status AS file_status
FROM v$log l
JOIN v$logfile f ON l.group# = f.group#
WHERE f.status IS NOT NULL  -- INVALID 또는 STALE 상태 감지
   OR l.status = 'INACTIVE' AND l.archived = 'NO';

-- Redo Log 그룹별 멤버 수 확인 (2개 미만이면 경고)
SELECT group#, COUNT(*) AS member_count
FROM v$logfile
GROUP BY group#
HAVING COUNT(*) < 2;

2. ASM(Automatic Storage Management) 또는 검증된 스토리지 이중화 도입

Oracle ASM을 사용하면 Redo Log 파일의 Mirroring이 스토리지 레이어에서 자동으로 관리되어 단일 디스크 장애로 인한 LGWR 프로세스 종료를 근본적으로 예방할 수 있습니다. ASM 도입이 어려운 환경이라면 최소한 OS 레벨의 LVM 미러링이나 RAID-10 구성을 통해 Redo Log가 저장되는 디스크를 이중화해야 합니다. 또한 archive_lag_target 파라미터를 적절히 설정하여 아카이브 로그 생성 주기를 관리하면 장애 시 데이터 복구 가능 범위를 최대화할 수 있습니다.