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

ORA-00215란?

ORA-00215 에러는 Oracle 데이터베이스가 시작(STARTUP) 또는 마운트(MOUNT) 과정에서 유효한 컨트롤 파일(Control File)을 단 하나도 찾지 못했을 때 발생하는 치명적인 에러입니다. 컨트롤 파일은 데이터베이스의 물리적 구조 정보(데이터 파일 위치, 리두 로그 파일 위치, SCN 정보 등)를 담고 있는 핵심 바이너리 파일로, 이 파일 없이는 Oracle 인스턴스가 데이터베이스를 마운트하거나 오픈할 수 없습니다. 주로 초기화 파라미터 파일(SPFILE 또는 PFILE)의 CONTROL_FILES 파라미터 설정이 잘못되었거나, 실제 파일이 존재하지 않을 때 이 에러가 트리거됩니다.

주요 발생 원인

1. CONTROL_FILES 파라미터 경로 오기재 또는 파일 누락

가장 빈번한 원인으로, init.ora 또는 SPFILE 내의 CONTROL_FILES 파라미터에 지정된 경로가 실제 파일 시스템상의 경로와 일치하지 않을 때 발생합니다. 스토리지 마이그레이션, 서버 이전, 또는 단순한 오타로 인해 경로가 틀리게 설정된 경우가 대표적이며, Oracle은 지정된 경로에서 파일을 찾지 못하면 즉시 이 에러를 반환합니다.

2. 컨트롤 파일 물리적 삭제 또는 손상

운영 중 실수로 컨트롤 파일이 OS 레벨에서 삭제되거나, 디스크 장애·파일 시스템 오류로 인해 파일이 물리적으로 손상(corrupt)된 경우입니다. Oracle은 기본적으로 다중화(Multiplexing)된 컨트롤 파일을 권장하는데, 다중화가 되어 있지 않은 단일 구성 환경에서 이런 사고가 발생하면 복구가 매우 까다로워집니다. 파일이 0바이트로 비워지거나 부분적으로 덮어씌워진 경우도 동일한 에러를 유발합니다.

3. 데이터베이스 재생성(RECREATE) 또는 복제(CLONE) 후 파라미터 미수정

운영 데이터베이스를 복제하여 개발 또는 테스트 환경을 구성할 때, 원본 SPFILE을 그대로 복사하면 CONTROL_FILES 파라미터가 원본 경로를 그대로 가리키게 됩니다. 새로운 환경의 디렉토리 구조가 다르거나 컨트롤 파일이 아직 생성되지 않은 상태에서 인스턴스를 기동하면 ORA-00215가 발생합니다. 특히 RMAN을 활용한 Duplicate 작업 후 수동으로 파라미터를 조정하다 실수가 발생하는 경우가 많습니다.

해결 방법

원인 1 해결: CONTROL_FILES 파라미터 경로 확인 및 수정

먼저 현재 파라미터 파일이 어떤 경로를 참조하고 있는지 확인합니다. SPFILE 기반이라면 STARTUP NOMOUNT 이전 단계에서 PFILE로 덤프하거나, OS에서 strings 명령으로 내용을 확인합니다.

-- PFILE을 통해 NOMOUNT 상태로 기동 후 파라미터 확인
STARTUP NOMOUNT PFILE='/u01/app/oracle/admin/ORCL/pfile/init.ora';

-- 현재 인식된 CONTROL_FILES 파라미터 값 확인
SHOW PARAMETER CONTROL_FILES;

-- 또는 V$PARAMETER 뷰에서 확인
SELECT NAME, VALUE
FROM   V$PARAMETER
WHERE  NAME = 'control_files';

파라미터 경로가 잘못된 경우, PFILE을 직접 편집하거나 SPFILE을 수정합니다.

-- PFILE 직접 수정 후 재기동 (vi 편집기 등으로 수정)
-- init.ora 예시 내용:
-- control_files = ('/u01/app/oracle/oradata/ORCL/control01.ctl',
--                  '/u02/app/oracle/oradata/ORCL/control02.ctl')

-- SPFILE 수정 시 (NOMOUNT 상태에서 가능)
ALTER SYSTEM SET CONTROL_FILES=
  '/u01/app/oracle/oradata/ORCL/control01.ctl',
  '/u02/app/oracle/oradata/ORCL/control02.ctl'
SCOPE=SPFILE;

-- 이후 재기동
SHUTDOWN ABORT;
STARTUP;

원인 2 해결: 컨트롤 파일 복구

다중화된 컨트롤 파일 중 일부만 손상된 경우, 정상적인 컨트롤 파일을 손상된 위치로 복사합니다.

# OS 레벨에서 정상 컨트롤 파일 복사 (DB가 정지된 상태)
cp /u01/app/oracle/oradata/ORCL/control01.ctl \
   /u02/app/oracle/oradata/ORCL/control02.ctl

-- 복사 후 데이터베이스 재기동
STARTUP;

-- 기동 후 컨트롤 파일 상태 확인
SELECT NAME, STATUS FROM V$CONTROLFILE;

모든 컨트롤 파일이 소실된 경우 RMAN 백업을 활용하여 복구합니다.

-- RMAN을 통한 컨트롤 파일 복구
RMAN TARGET /

-- 자동 백업된 컨트롤 파일 복구
RESTORE CONTROLFILE FROM AUTOBACKUP;

-- 복구 후 MOUNT 상태로 전환
ALTER DATABASE MOUNT;

-- 데이터베이스 불완전 복구 수행 (필요 시)
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

-- RESETLOGS로 오픈
ALTER DATABASE OPEN RESETLOGS;

컨트롤 파일 백업조차 없는 최악의 시나리오에서는 CREATE CONTROLFILE 명령으로 재생성해야 합니다.

-- 컨트롤 파일 재생성 (데이터 파일 및 리두 로그 파일 목록 사전 파악 필요)
-- alert log 또는 기존 trace 파일에서 목록 확인 후 실행
STARTUP NOMOUNT;

CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/app/oracle/oradata/ORCL/redo01.log' SIZE 50M,
  GROUP 2 '/u01/app/oracle/oradata/ORCL/redo02.log' SIZE 50M,
  GROUP 3 '/u01/app/oracle/oradata/ORCL/redo03.log' SIZE 50M
DATAFILE
  '/u01/app/oracle/oradata/ORCL/system01.dbf',
  '/u01/app/oracle/oradata/ORCL/sysaux01.dbf',
  '/u01/app/oracle/oradata/ORCL/undotbs01.dbf',
  '/u01/app/oracle/oradata/ORCL/users01.dbf'
CHARACTER SET AL32UTF8;

-- 이후 복구 및 오픈
RECOVER DATABASE;
ALTER DATABASE OPEN;

⚠️ 주의: CREATE CONTROLFILE 실행 전 반드시 기존 데이터 파일과 리두 로그 파일의 정확한 경로와 목록을 파악해야 합니다. 잘못된 정보로 생성 시 추가적인 데이터 손실이 발생할 수 있습니다.

원인 3 해결: 복제 환경 파라미터 정정

-- NOMOUNT 상태에서 SPFILE을 PFILE로 덤프
CREATE PFILE='/tmp/init_new.ora' FROM SPFILE;

-- OS에서 init_new.ora 편집 후 CONTROL_FILES 경로 수정
-- 수정된 PFILE로 기동
STARTUP NOMOUNT PFILE='/tmp/init_new.ora';

-- 정상 기동 확인 후 SPFILE 재생성
CREATE SPFILE FROM PFILE='/tmp/init_new.ora';

-- 최종 재기동
SHUTDOWN IMMEDIATE;
STARTUP;

예방 방법

1. 컨트롤 파일 다중화(Multiplexing) 및 자동 백업 설정

컨트롤 파일은 반드시 서로 다른 디스크(또는 ASM 디스크 그룹)에 최소 2~3개 이상 다중화하여 단일 장애 지점(SPOF)을 제거해야 합니다. 또한 RMAN의 CONFIGURE CONTROLFILE AUTOBACKUP ON 설정을 통해 모든 백업 작업 및 구조 변경 시 컨트롤 파일이 자동으로 백업되도록 구성하면, 재해 발생 시 신속한 복구가 가능합니다.

-- 컨트롤 파일 다중화 확인
SELECT NAME FROM V$CONTROLFILE;

-- RMAN 컨트롤 파일 자동 백업 활성화
RMAN TARGET /
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/rman/%F';

-- 현재 RMAN 설정 확인
SHOW ALL;

2. 정기적인 컨트롤 파일 트레이스(Trace) 덤프 생성 및 보관

ALTER DATABASE BACKUP CONTROLFILE TO TRACE 명령을 주기적으로 실행하여 CREATE CONTROLFILE 스크립트가 포함된 트레이스 파일을 생성하고 안전한 위치에 보관하는 습관을 가져야 합니다. 이 스크립트는 모든 컨트롤 파일이 소실되는 극단적인 상황에서 데이터베이스 구조를 재구성하는 마지막 보루가 됩니다.

-- 컨트롤 파일 내용을 트레이스 파일로 덤프
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

-- 특정 파일로 직접 덤프 (Oracle 10g 이상)
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/backup/scripts/controlfile_script.sql' REUSE;

-- 이진 형태로도 별도 백업
ALTER DATABASE BACKUP CONTROLFILE TO '/backup/controlfile/control_backup.ctl' REUSE;

推荐订阅源

DEV Community