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

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

이 글에서 다루는 내용

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

ORA-00304 requested INSTANCE_NUMBER is busy 는?

ORA-00304 에러는 Oracle RAC(Real Application Clusters) 환경에서 특정 인스턴스 번호(INSTANCE_NUMBER)를 사용하여 데이터베이스 인스턴스를 시작하려 할 때, 해당 번호가 이미 다른 인스턴스에 의해 사용 중이거나 아직 정상적으로 해제되지 않은 상태일 때 발생합니다. 쉽게 말해, RAC 클러스터 내에서 동일한 인스턴스 번호를 두 개의 인스턴스가 동시에 사용하려는 충돌 상황입니다. 이 에러는 인스턴스가 비정상 종료된 후 재시작하거나, 파라미터 파일(SPFILE/PFILE)의 INSTANCE_NUMBER 설정이 잘못된 경우에 주로 나타납니다.

주요 발생 원인

1. 비정상 종료 후 인스턴스 잠금(Lock) 미해제

RAC 환경에서 인스턴스가 비정상적으로 종료(OS 크래시, 강제 kill 등)된 경우, 해당 인스턴스가 사용하던 인스턴스 번호에 대한 잠금 정보가 OCR(Oracle Cluster Registry) 또는 공유 메모리 영역에 남아 있을 수 있습니다. 이 상태에서 동일한 INSTANCE_NUMBER로 인스턴스를 재시작하려 하면 ORA-00304 에러가 발생합니다. Oracle 클러스터웨어가 해당 번호를 여전히 “활성 중”으로 인식하기 때문에 충돌이 일어나는 것입니다.

2. INSTANCE_NUMBER 파라미터 중복 설정

SPFILE 또는 PFILE에서 여러 인스턴스가 동일한 INSTANCE_NUMBER 값을 갖도록 잘못 설정된 경우 이 에러가 발생합니다. 예를 들어, 노드를 추가하거나 인스턴스를 복제하는 과정에서 실수로 동일한 번호를 부여하는 경우가 대표적입니다. RAC 환경에서 각 인스턴스는 반드시 고유한 INSTANCE_NUMBER를 가져야 하며, 이 규칙이 위반될 경우 데이터베이스 시작 단계에서 즉시 에러가 발생합니다.

3. 클러스터웨어(Clusterware) 및 OCR 정보 불일치

Oracle Clusterware의 OCR 또는 Voting Disk에 저장된 인스턴스 구성 정보와 실제 데이터베이스 파라미터 파일 간에 불일치가 발생한 경우 이 에러가 나타날 수 있습니다. 클러스터웨어 업그레이드, 노드 재구성, 또는 수동으로 OCR을 수정한 이후에 이런 불일치가 발생하는 경우가 있습니다. 이 경우 단순히 파라미터를 변경하는 것만으로는 해결되지 않고, 클러스터웨어 레벨에서의 점검과 수정이 필요합니다.

해결 방법

원인 1 해결: 인스턴스 잠금 확인 및 강제 해제

먼저 현재 클러스터에서 활성화된 인스턴스 번호를 확인합니다.

-- 현재 클러스터 내 활성 인스턴스 조회
SELECT inst_id, instance_number, instance_name, status, host_name
FROM gv$instance
ORDER BY inst_id;

만약 문제가 되는 인스턴스가 GV$INSTANCE에 여전히 보인다면, SRVCTL 명령어로 강제 종료를 시도합니다.

-- SQL*Plus에서 해당 인스턴스 강제 종료 (노드 2번 인스턴스 예시)
-- OS 레벨에서 실행:
-- srvctl stop instance -d ORCL -i ORCL2 -o abort

-- 이후 재시작 시도
-- srvctl start instance -d ORCL -i ORCL2

OCR에 남아 있는 잠금 정보를 확인하려면 아래 쿼리를 활용합니다.

-- 잠금 관련 내부 뷰 조회 (SYS 권한 필요)
SELECT * FROM v$lock_activity;

-- 또는 DLM 잠금 상태 확인
SELECT resource_name1, grant_level, request_level, blocked
FROM v$ges_enqueue
WHERE resource_name1 LIKE '%BL%'
ORDER BY 1;

원인 2 해결: INSTANCE_NUMBER 파라미터 수정

현재 SPFILE에 설정된 인스턴스 번호를 확인하고 수정합니다.

-- 현재 인스턴스 번호 파라미터 확인
SHOW PARAMETER INSTANCE_NUMBER;

-- 또는 SPFILE 내용 조회
SELECT name, value, description
FROM v$spparameter
WHERE name = 'instance_number';

중복된 인스턴스 번호가 확인되었을 경우, 아래와 같이 수정합니다.

-- SPFILE에서 특정 인스턴스의 INSTANCE_NUMBER 변경
-- (예: 인스턴스명 ORCL2를 2번으로 설정)
ALTER SYSTEM SET INSTANCE_NUMBER = 2
  SCOPE = SPFILE
  SID = 'ORCL2';

-- 변경 후 해당 인스턴스 재시작 필요
-- SHUTDOWN IMMEDIATE;
-- STARTUP;

PFILE을 사용하는 환경이라면 직접 편집합니다.

-- PFILE 예시 (init<SID>.ora)
-- ORCL1.instance_number=1
-- ORCL2.instance_number=2  <-- 이 값이 중복되지 않아야 함

-- PFILE로부터 SPFILE 재생성
CREATE SPFILE FROM PFILE='/u01/app/oracle/product/19c/dbs/initORCL2.ora';

원인 3 해결: 클러스터웨어 구성 재동기화

클러스터웨어와 데이터베이스 구성 정보의 불일치를 해소합니다.

-- SRVCTL로 현재 데이터베이스 구성 확인 (OS 레벨)
-- srvctl config database -d ORCL -a

-- OCR 백업 상태 확인
-- ocrcheck
-- ocrdump -stdout | grep -i instance

-- 구성 정보 강제 재동기화
-- srvctl modify instance -d ORCL -i ORCL2 -n node2

클러스터웨어 로그를 통해 추가 정보를 확인합니다.

-- alert log 위치 확인
SELECT value FROM v$diag_info WHERE name = 'Diag Trace';

-- 클러스터웨어 로그 경로 (OS)
-- $GRID_HOME/log/<hostname>/crsd/crsd.log
-- $GRID_HOME/log/<hostname>/cssd/ocssd.log

예방 방법

1. SPFILE 파라미터 정기 감사 및 변경 관리 프로세스 수립

RAC 환경에서는 인스턴스를 추가하거나 변경할 때 반드시 INSTANCE_NUMBER, INSTANCE_NAME 등 인스턴스 식별 파라미터의 중복 여부를 사전에 검증하는 절차를 마련해야 합니다. 아래 쿼리를 배포 전 체크리스트에 포함시켜 정기적으로 실행하도록 합니다.

-- 전체 인스턴스 파라미터 현황 점검 쿼리
SELECT inst_id, name, value
FROM gv$parameter
WHERE name IN ('instance_number', 'instance_name', 'cluster_database_instances')
ORDER BY name, inst_id;

-- SPFILE 기준 중복 여부 확인
SELECT name, value, COUNT(*) AS cnt
FROM v$spparameter
WHERE name = 'instance_number'
GROUP BY name, value
HAVING COUNT(*) > 1;

2. 클러스터웨어 상태 정기 모니터링 및 정상 종료 절차 준수

인스턴스를 종료할 때는 반드시 SHUTDOWN IMMEDIATE 또는 srvctl stop instance 명령을 통해 정상적으로 종료하고, 비정상 종료 후에는 클러스터웨어 로그를 반드시 검토하는 습관을 들여야 합니다. 또한 Oracle Clusterware Health Monitor와 같은 모니터링 도구를 활용하여 인스턴스 상태를 주기적으로 점검하고, 이상 징후 발생 시 즉시 알림을 받을 수 있도록 설정하는 것이 중요합니다.