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

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

이 글에서 다루는 내용

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

ORA-00474 SMON process terminated with error 는?

ORA-00474는 Oracle 데이터베이스의 핵심 백그라운드 프로세스 중 하나인 SMON(System Monitor)이 비정상적으로 종료될 때 발생하는 에러입니다. SMON은 인스턴스 복구, 임시 세그먼트 정리, 딕셔너리 관리 테이블스페이스의 익스텐트 병합 등 데이터베이스 내부의 중요한 유지관리 작업을 담당하고 있습니다. 이 프로세스가 종료되면 Oracle은 즉시 인스턴스를 내리거나 경보를 발생시켜 DBA의 즉각적인 조치를 요구하게 됩니다.

주요 발생 원인

1. 손상된 데이터 딕셔너리 또는 시스템 테이블스페이스 오류

SMON은 데이터 딕셔너리와 긴밀하게 연동되어 작동합니다. SYSTEM 테이블스페이스나 SYSAUX 테이블스페이스에 블록 손상(block corruption)이 발생하거나, 내부 딕셔너리 뷰에 접근하는 과정에서 오류가 발생하면 SMON 프로세스가 즉시 비정상 종료될 수 있습니다. 특히 하드웨어 I/O 오류나 스토리지 장애가 선행된 경우 이 원인이 가장 빈번하게 확인됩니다.

2. 인스턴스 복구(Instance Recovery) 중 롤백 세그먼트 이상

데이터베이스가 비정상 종료된 후 재기동될 때 SMON은 인스턴스 복구를 수행합니다. 이 과정에서 롤백 세그먼트(Undo 세그먼트)에 손상이 있거나 특정 트랜잭션의 롤백이 불가능한 상태이면 SMON이 복구 작업을 완료하지 못하고 에러와 함께 종료됩니다. 오래된 버전의 Oracle에서는 UNDO 테이블스페이스의 익스텐트 할당 문제도 이 범주에 포함됩니다.

3. 메모리 부족(OOM) 또는 OS 레벨 리소스 부족

SMON은 Oracle SGA 영역을 직접 사용하며 운영체제의 리소스(메모리, 파일 핸들 등)와 밀접하게 연관되어 있습니다. 서버의 물리적 메모리가 부족하거나 OS의 OOM(Out of Memory) Killer가 Oracle 프로세스를 강제 종료하는 경우, 또는 ulimit 설정이 Oracle 권고치보다 낮게 설정된 경우 SMON이 비정상 종료될 수 있습니다. alert 로그와 OS 시스템 로그(/var/log/messages 또는 /var/log/syslog)를 동시에 확인하는 것이 이 원인을 진단하는 데 필수적입니다.

해결 방법

STEP 1. Alert 로그 및 트레이스 파일 즉시 확인

SMON 종료 시 Oracle은 반드시 alert log와 함께 트레이스 파일을 생성합니다. 가장 먼저 이 파일들을 분석해야 합니다.

-- alert log 위치 확인
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- 또는 ADR 홈 위치 확인
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'ADR Home';

-- SMON 관련 트레이스 파일 확인 (SQL*Plus에서)
-- background_dump_dest 확인
SHOW PARAMETER background_dump_dest;

STEP 2. 데이터 딕셔너리 및 블록 손상 확인

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

-- 블록 손상 확인 (RMAN 활용)
-- RMAN 프롬프트에서 실행
-- VALIDATE DATABASE;
-- 또는 특정 데이터 파일 검사
-- VALIDATE DATAFILE 1;

-- V$DATABASE_BLOCK_CORRUPTION 확인
SELECT FILE#, BLOCK#, BLOCKS, CORRUPTION_TYPE
FROM V$DATABASE_BLOCK_CORRUPTION;

STEP 3. 롤백/UNDO 세그먼트 문제 해결

인스턴스 복구 중 특정 UNDO 세그먼트 문제 발생 시 파라미터를 임시 설정하여 DB를 기동할 수 있습니다.

-- init.ora 또는 spfile에서 임시 설정 (문제 있는 언두 세그먼트 우회)
-- 아래는 pfile 예시이며, 실제 세그먼트 이름은 alert log에서 확인
-- _OFFLINE_ROLLBACK_SEGMENTS = (_SYSSMU1_123456789$)

-- SPFILE에서 설정하는 방법
ALTER SYSTEM SET "_offline_rollback_segments" = '_SYSSMU3_123456789$'
  SCOPE=SPFILE;

-- 언두 세그먼트 상태 확인
SELECT SEGMENT_NAME, STATUS, TABLESPACE_NAME
FROM DBA_ROLLBACK_SEGS;

-- 문제 있는 언두 세그먼트를 OFFLINE으로 전환
ALTER ROLLBACK SEGMENT "_SYSSMU3_123456789$" OFFLINE;

STEP 4. 임시 세그먼트 수동 정리

SMON이 임시 세그먼트를 정리하는 도중 실패한 경우, 수동으로 임시 세그먼트를 삭제합니다.

-- 임시 세그먼트 확인
SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, BYTES
FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE = 'TEMPORARY';

-- 임시 테이블스페이스 공간 확인
SELECT TABLESPACE_NAME, BYTES_USED, BYTES_FREE
FROM V$TEMP_SPACE_HEADER;

-- TEMP 테이블스페이스 shrink (Oracle 11g 이상)
ALTER TABLESPACE TEMP SHRINK SPACE KEEP 100M;

STEP 5. OS 레벨 리소스 점검

-- Oracle 세션 및 프로세스 확인
SELECT COUNT(*) AS TOTAL_SESSIONS FROM V$SESSION;
SELECT COUNT(*) AS TOTAL_PROCESSES FROM V$PROCESS;

-- 현재 SGA 사용 현황
SELECT POOL, NAME, BYTES/1024/1024 AS MB
FROM V$SGASTAT
WHERE POOL IS NOT NULL
ORDER BY BYTES DESC
FETCH FIRST 10 ROWS ONLY;

OS 커맨드로 ulimit 및 메모리 확인:

-- OS 명령어 (Linux 기준, SQL이 아닌 shell에서 실행)
-- ulimit -a
-- free -m
-- dmesg | grep -i "out of memory"
-- /var/log/messages 확인

예방 방법

1. 정기적인 데이터베이스 헬스 체크 및 RMAN 백업 검증

주기적으로 RMAN을 이용한 데이터베이스 전체 검증(VALIDATE DATABASE)을 수행하고, 블록 체크섬(DB_BLOCK_CHECKSUM) 파라미터를 활성화하여 I/O 레벨에서 블록 손상을 조기에 감지해야 합니다. 또한 OEM(Oracle Enterprise Manager) 또는 커스텀 모니터링 스크립트를 통해 SMON을 포함한 모든 백그라운드 프로세스의 상태를 실시간으로 모니터링하는 체계를 구축하는 것이 바람직합니다.

-- DB_BLOCK_CHECKSUM 활성화 확인 및 설정
SHOW PARAMETER db_block_checksum;

ALTER SYSTEM SET DB_BLOCK_CHECKSUM = TYPICAL SCOPE=BOTH;

-- 백그라운드 프로세스 상태 모니터링 쿼리
SELECT PNAME, PID, SPID, BACKGROUND, LATCHWAIT, LATCHSPIN
FROM V$PROCESS
WHERE BACKGROUND = 1
ORDER BY PNAME;

2. OS 리소스 및 Oracle 파라미터 권고치 준수

Oracle의 운영 환경에 맞는 OS 커널 파라미터(shmmax, semaphore 등)와 ulimit 값을 Oracle 공식 설치 가이드(OS별 Pre-Installation Checklist) 기준으로 설정하고 정기적으로 검토해야 합니다. 또한 UNDO_RETENTION 파라미터와 UNDO 테이블스페이스 크기를 업무 트랜잭션 패턴에 맞게 적절히 조정하여 SMON의 복구 부담을 최소화하는 것이 중요합니다.

-- UNDO 관련 파라미터 확인
SHOW PARAMETER undo;

-- UNDO 테이블스페이스 사용 현황
SELECT TABLESPACE_NAME,
       ROUND(SUM(BYTES)/1024/1024, 2) AS TOTAL_MB,
       ROUND(SUM(DECODE(STATUS,'EXPIRED',BYTES,0))/1024/1024,2) AS EXPIRED_MB,
       ROUND(SUM(DECODE(STATUS,'UNEXPIRED',BYTES,0))/1024/1024,2) AS UNEXPIRED_MB,
       ROUND(SUM(DECODE(STATUS,'ACTIVE',BYTES,0))/1024/1024,2) AS ACTIVE_MB
FROM DBA_UNDO_EXTENTS
GROUP BY TABLESPACE_NAME;