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

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

이 글에서 다루는 내용

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

ORA-00471 DBWR process terminated with error 는?

ORA-00471은 Oracle Database의 핵심 백그라운드 프로세스 중 하나인 DBWR(Database Writer) 프로세스가 비정상적으로 종료되었을 때 발생하는 심각한 에러입니다. DBWR 프로세스는 버퍼 캐시(Buffer Cache)에 있는 더티 블록(Dirty Block)을 데이터 파일에 기록하는 역할을 담당하며, 이 프로세스가 종료되면 데이터베이스 전체가 비정상 종료(Crash)될 수 있습니다. 이 에러는 즉각적인 조치가 필요한 Critical Level 에러로, 방치할 경우 데이터 손실 및 데이터베이스 복구 작업이 필요할 수 있습니다.

주요 발생 원인

1. OS 레벨의 I/O 오류 또는 디스크 장애

가장 빈번한 원인으로, DBWR이 데이터 파일에 쓰기 작업을 수행하던 중 운영체제 레벨에서 I/O 오류가 발생하면 DBWR 프로세스가 강제 종료됩니다. 디스크 불량 섹터, 스토리지 장치의 물리적 결함, NFS 마운트 해제, SAN/NAS 네트워크 단절 등이 대표적인 원인이며, OS의 alert 로그 및 시스템 로그(/var/log/messages, dmesg)에 관련 I/O 에러 메시지가 함께 기록됩니다. 특히 RAC 환경에서는 공유 스토리지 접근 불가 시 즉각적으로 이 에러가 발생할 수 있어 더욱 주의가 필요합니다.

2. 데이터 파일 또는 테이블스페이스 공간 부족 및 권한 문제

DBWR이 데이터 파일에 블록을 기록하려 할 때 파일 시스템이 가득 찼거나, 데이터 파일에 대한 OS 레벨의 쓰기 권한이 변경된 경우에도 이 에러가 발생합니다. 자동 확장(AUTOEXTEND) 설정이 되어 있더라도 파일 시스템 자체의 공간이 부족하면 확장이 불가능하여 DBWR이 실패합니다. 또한 Oracle 프로세스 소유자(oracle 계정)의 파일 권한 변경이나 umask 설정 오류도 간접적인 원인이 될 수 있습니다.

3. Oracle 메모리(SGA) 구성 오류 또는 OS 자원 부족

SGA의 버퍼 캐시 크기가 지나치게 크게 설정되어 OS의 가용 메모리를 초과하거나, OS의 스왑 공간이 고갈된 경우 DBWR 프로세스가 메모리를 할당받지 못해 종료될 수 있습니다. 리눅스 환경에서는 OOM Killer(Out Of Memory Killer)가 Oracle 프로세스를 강제 종료시키는 경우가 많으며, 이 경우 /var/log/messages에 OOM Kill 관련 로그가 함께 남습니다. Oracle의 db_writer_processes 파라미터를 과도하게 설정하거나 시스템의 최대 프로세스 수 제한(ulimit)을 초과했을 때도 유사한 증상이 나타납니다.

해결 방법

Step 1: Alert 로그 및 트레이스 파일 확인

가장 먼저 Oracle Alert 로그를 확인하여 에러의 근본 원인을 파악해야 합니다.

-- Alert 로그 위치 확인
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- 또는 BACKGROUND_DUMP_DEST 확인 (구버전)
SHOW PARAMETER BACKGROUND_DUMP_DEST;

-- ADR을 통한 최근 에러 확인
SELECT ORIGINATING_TIMESTAMP, MESSAGE_TEXT
FROM V$DIAG_ALERT_EXT
WHERE MESSAGE_TEXT LIKE '%ORA-00471%'
   OR MESSAGE_TEXT LIKE '%DBWR%'
ORDER BY ORIGINATING_TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

Step 2: 데이터 파일 및 디스크 공간 상태 확인

-- 데이터 파일 상태 확인
SELECT FILE#, NAME, STATUS, BYTES/1024/1024 AS SIZE_MB, AUTOEXTEND
FROM V$DATAFILE
ORDER BY FILE#;

-- 테이블스페이스별 사용률 확인
SELECT
    df.TABLESPACE_NAME,
    ROUND(df.TOTAL_BYTES / 1024 / 1024, 2) AS TOTAL_MB,
    ROUND(NVL(fs.FREE_BYTES, 0) / 1024 / 1024, 2) AS FREE_MB,
    ROUND((1 - NVL(fs.FREE_BYTES, 0) / df.TOTAL_BYTES) * 100, 2) AS USED_PCT
FROM
    (SELECT TABLESPACE_NAME, SUM(BYTES) AS TOTAL_BYTES
     FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME) df
LEFT JOIN
    (SELECT TABLESPACE_NAME, SUM(BYTES) AS FREE_BYTES
     FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME) fs
ON df.TABLESPACE_NAME = fs.TABLESPACE_NAME
ORDER BY USED_PCT DESC;

-- 데이터 파일 추가 (공간 부족 시)
ALTER TABLESPACE USERS
ADD DATAFILE '/u01/app/oracle/oradata/ORCL/users02.dbf'
SIZE 1G AUTOEXTEND ON NEXT 100M MAXSIZE 10G;

Step 3: I/O 오류로 인한 데이터 파일 복구

-- 데이터 파일 오프라인 후 복구 시도
ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' OFFLINE;

-- RMAN을 이용한 데이터 파일 복구
-- (RMAN 프롬프트에서 실행)
-- RMAN> RESTORE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf';
-- RMAN> RECOVER DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf';

-- 복구 후 온라인 전환
ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/users01.dbf' ONLINE;

-- 데이터 파일 상태 재확인
SELECT FILE#, NAME, STATUS, RECOVER FROM V$DATAFILE WHERE STATUS != 'ONLINE';

Step 4: SGA 메모리 설정 점검 및 조정

-- 현재 SGA 구성 확인
SELECT COMPONENT, CURRENT_SIZE/1024/1024 AS CURRENT_MB,
       MIN_SIZE/1024/1024 AS MIN_MB,
       MAX_SIZE/1024/1024 AS MAX_MB
FROM V$SGA_DYNAMIC_COMPONENTS;

-- SGA 전체 크기 확인
SHOW PARAMETER SGA_TARGET;
SHOW PARAMETER SGA_MAX_SIZE;
SHOW PARAMETER DB_CACHE_SIZE;

-- SGA 크기 조정 (OS 가용 메모리의 60~70% 권장)
ALTER SYSTEM SET SGA_TARGET = 4G SCOPE=SPFILE;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1G SCOPE=SPFILE;

-- DB Writer 프로세스 수 확인 및 조정 (CPU 수의 1/8 권장)
SHOW PARAMETER DB_WRITER_PROCESSES;
ALTER SYSTEM SET DB_WRITER_PROCESSES = 4 SCOPE=SPFILE;

Step 5: 데이터베이스 재기동 (불가피한 경우)

-- Restricted Mode로 기동하여 상태 점검
STARTUP RESTRICT;

-- 데이터베이스 무결성 확인
SELECT STATUS FROM V$INSTANCE;

-- 정상 모드로 전환
ALTER SYSTEM DISABLE RESTRICTED SESSION;

-- 또는 Mount 상태에서 복구 후 기동
-- STARTUP MOUNT;
-- RECOVER DATABASE;
-- ALTER DATABASE OPEN;

예방 방법

1. 정기적인 모니터링 및 자동화된 알림 체계 구축

테이블스페이스 사용률, 디스크 여유 공간, OS 자원(메모리, 스왑) 등을 주기적으로 모니터링하고 임계치 초과 시 즉각 알림을 받을 수 있는 체계를 마련해야 합니다.

-- 테이블스페이스 사용률 90% 이상인 경우 확인하는 모니터링 쿼리
-- (Cron Job 또는 OEM에서 주기 실행 권장)
SELECT TABLESPACE_NAME,
       ROUND(USED_PERCENT, 2) AS USED_PCT,
       CASE WHEN USED_PERCENT >= 90 THEN 'CRITICAL'
            WHEN USED_PERCENT >= 80 THEN 'WARNING'
            ELSE 'NORMAL' END AS STATUS
FROM DBA_TABLESPACE_USAGE_METRICS
WHERE USED_PERCENT >= 80
ORDER BY USED_PERCENT DESC;

모든 데이터 파일에 대해 AUTOEXTEND ON을 설정하되, 반드시 MAXSIZE를 지정하여 파일 시스템 고갈을 방지하는 것이 중요합니다. Oracle Enterprise Manager(OEM) 또는 서드파티 모니터링 툴(Zabbix, Prometheus+Grafana 등)을 활용하면 실시간 이상 감지 및 자동 알림이 가능합니다.

2. 정기적인 백업 및 RMAN 구성 검증

DBWR 에러로 인한 데이터 파일 손상에 대비하여 RMAN(Recovery Manager)을 통한 정기 백업을 반드시 구성해야 하며, 단순히 백업을 설정하는 것에 그치지 않고 주기적인 복구 테스트(Restore & Recovery Test)를 수행하여 백업의 유효성을 검증해야 합니다.

-- RMAN 백업 상태 확인
SELECT INPUT_TYPE, STATUS, START_TIME, END_TIME,
       ROUND(OUTPUT_BYTES/1024/1024/1024, 2) AS OUTPUT_GB
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY START_TIME DESC
FETCH FIRST 10 ROWS ONLY;

Flash Recovery Area(FRA) 크기를 충분히 확보하고, 아카이브 로그 모드(ARCHIVELOG MODE)를 반드시 활성화하여 Point-in-Time Recovery가 가능한 환경을 유지하는 것이 핵심입니다.