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

#oracle #database #dba #sql

ORA-00072 process is not active 는?

ORA-00072 에러는 Oracle 데이터베이스 내부에서 특정 프로세스(Process)가 더 이상 활성 상태가 아닌데, 해당 프로세스와 통신하거나 작업을 위임하려 할 때 발생하는 에러입니다. 주로 백그라운드 프로세스(Background Process)나 서버 프로세스(Server Process)가 비정상적으로 종료되었거나, 아직 완전히 초기화되지 않은 상태에서 요청이 들어올 경우 Oracle 커널 레벨에서 감지하여 반환합니다. 실무에서는 인스턴스 기동/종료 과정, 비정상적인 세션 종료, 또는 RAC(Real Application Clusters) 환경에서의 노드 장애 시 빈번하게 관찰됩니다.

주요 발생 원인

1. 백그라운드 프로세스의 비정상 종료(Crash)

Oracle 인스턴스를 구성하는 PMON, SMON, DBWn, LGWR 등 핵심 백그라운드 프로세스 중 하나가 예기치 않게 종료될 경우, 해당 프로세스에 작업을 요청하던 다른 프로세스나 세션이 ORA-00072를 마주하게 됩니다. 운영체제 레벨의 메모리 부족(OOM Killer), 시그널(SIGKILL) 강제 종료, 또는 Oracle 내부 버그로 인해 백그라운드 프로세스가 갑작스럽게 다운될 수 있으며, 이 경우 대부분 인스턴스 전체가 비정상 종료(Instance Crash)로 이어지기도 합니다.

2. 세션 또는 서버 프로세스의 강제 종료 후 재참조

DBA가 ALTER SYSTEM KILL SESSION 명령을 실행하거나, 운영체제에서 Oracle 서버 프로세스(ora_xxxx)를 kill -9로 강제 종료한 직후, 해당 프로세스의 정보가 아직 SGA(System Global Area) 내 프로세스 테이블에 남아 있는 짧은 시간 동안 다른 세션이나 내부 루틴이 해당 프로세스를 참조할 경우 에러가 발생합니다. PMON이 정리(cleanup)를 완료하기 이전의 타이밍 이슈(Race Condition)로 볼 수 있으며, 대개 일시적으로 나타났다가 자동으로 소멸되는 경우가 많습니다.

3. RAC 환경에서의 노드 장애 또는 인터커넥트 단절

Oracle RAC 구성에서 특정 노드(Node)가 다운되거나, 노드 간 Private Interconnect 네트워크가 순간적으로 끊기면, 살아있는 노드의 프로세스들이 죽은 노드의 프로세스에 접근하려다 ORA-00072를 발생시킬 수 있습니다. 이 경우 CSS(Cluster Synchronization Services) 또는 Clusterware 로그와 함께 연쇄적인 에러가 alert.log에 기록되며, 경우에 따라 해당 노드의 강제 재시작(Node Eviction)이 트리거됩니다.

해결 방법

원인 1: 백그라운드 프로세스 비정상 종료 대응

먼저 alert.log와 백그라운드 트레이스 파일을 확인하여 어떤 프로세스가 종료되었는지 파악합니다.

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

-- 현재 활성 백그라운드 프로세스 목록 확인
SELECT PNAME, PID, SPID, BACKGROUND, LATCHWAIT, LATCHSPIN
FROM V$PROCESS
WHERE BACKGROUND = '1'
ORDER BY PNAME;

-- 인스턴스 상태 확인
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS, ACTIVE_STATE
FROM V$INSTANCE;

백그라운드 프로세스 종료로 인해 인스턴스가 다운된 경우라면, 재기동 후 원인 분석을 진행합니다.

-- 인스턴스 재기동 (SYSDBA 권한 필요)
-- SQL*Plus 접속 후:
SHUTDOWN ABORT;
STARTUP;

-- 재기동 후 인스턴스 복구 여부 확인
SELECT STATUS FROM V$INSTANCE;

-- 최근 에러 로그 확인 (AWR 또는 V$DIAG_ALERT_EXT 활용)
SELECT ORIGINATING_TIMESTAMP, MESSAGE_TEXT
FROM V$DIAG_ALERT_EXT
WHERE MESSAGE_TEXT LIKE '%ORA-00072%'
   OR MESSAGE_TEXT LIKE '%process died%'
ORDER BY ORIGINATING_TIMESTAMP DESC
FETCH FIRST 20 ROWS ONLY;

원인 2: 세션/프로세스 강제 종료 후 잔여 참조 처리

DBA가 세션을 종료한 후 잔여 프로세스가 남아있는지 확인하고 정리합니다.

-- 현재 세션 상태 중 KILLED 상태인 세션 확인
SELECT SID, SERIAL#, USERNAME, STATUS, OSUSER, MACHINE, PROGRAM, LAST_CALL_ET
FROM V$SESSION
WHERE STATUS = 'KILLED'
ORDER BY LAST_CALL_ET DESC;

-- KILLED 상태가 오래 지속되는 세션 강제 종료
-- (PMON이 자동으로 정리하지만, 지연 시 수동 처리)
ALTER SYSTEM KILL SESSION '&SID,&SERIAL#' IMMEDIATE;

-- 운영체제 레벨 프로세스 ID 확인 후 정리
SELECT p.SPID AS OS_PID, s.SID, s.SERIAL#, s.USERNAME, s.STATUS
FROM V$PROCESS p
JOIN V$SESSION s ON p.ADDR = s.PADDR
WHERE s.STATUS = 'KILLED';

-- 위 결과의 SPID를 이용해 OS에서 확인 (DBA가 OS 레벨에서 실행)
-- Linux: kill -9 <SPID>
-- 단, Oracle 프로세스를 OS에서 직접 kill하는 것은 최후의 수단으로만 사용할 것

-- 고아 트랜잭션(Orphan Transaction) 확인
SELECT t.ADDR, t.XIDUSN, t.XIDSLOT, t.XIDSQN, t.STATUS, t.START_TIME
FROM V$TRANSACTION t
LEFT JOIN V$SESSION s ON t.SES_ADDR = s.PADDR
WHERE s.SID IS NULL;

원인 3: RAC 환경 노드 장애 대응

RAC 환경에서 ORA-00072 발생 시 클러스터 상태와 GCS/GES 프로세스를 점검합니다.

-- RAC 전체 인스턴스 상태 확인
SELECT INST_ID, INSTANCE_NAME, STATUS, DATABASE_STATUS, ACTIVE_STATE
FROM GV$INSTANCE
ORDER BY INST_ID;

-- 각 노드의 백그라운드 프로세스 확인
SELECT INST_ID, PNAME, PID, SPID, BACKGROUND
FROM GV$PROCESS
WHERE BACKGROUND = '1'
  AND PNAME IN ('LMD0','LMS0','LCK0','LMON','DIAG')
ORDER BY INST_ID, PNAME;

-- 노드 간 통신 상태 확인 (GCS: Global Cache Service)
SELECT INST_ID, NAME, VALUE
FROM GV$SYSSTAT
WHERE NAME IN (
    'gc current blocks received',
    'gc cr blocks received',
    'gc current block receive time',
    'gc cr block receive time'
)
ORDER BY INST_ID, NAME;

-- 특정 노드 재시작 후 리소스 재조정 확인
-- (Clusterware 명령어 - OS 레벨, DBA 참고용)
-- srvctl status database -d <DB_NAME>
-- crsctl stat res -t

-- 장애 발생 전후 SCN 흐름 확인
SELECT CURRENT_SCN, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') AS CHK_TIME
FROM V$DATABASE;

예방 방법

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

백그라운드 프로세스의 상태를 주기적으로 점검하는 모니터링 스크립트를 Cron Job 또는 Oracle Enterprise Manager(OEM) 알림 정책으로 등록하여, 프로세스 이상 징후를 사전에 감지하는 체계를 마련해야 합니다. 또한 운영체제의 메모리, CPU, 스왑(Swap) 사용률을 지속적으로 모니터링하여 OOM Killer가 Oracle 프로세스를 종료하는 상황을 예방하고, /proc/sys/vm/overcommit_memory 설정 및 Oracle 프로세스에 대한 메모리 보호 정책을 적용하는 것이 권장됩니다.

-- 주기적으로 실행할 프로세스 상태 점검 쿼리 (모니터링 스크립트에 활용)
SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS CHECK_TIME,
       COUNT(*) AS TOTAL_PROCESS,
       SUM(CASE WHEN BACKGROUND = '1' THEN 1 ELSE 0 END) AS BG_PROCESS,
       SUM(CASE WHEN BACKGROUND IS NULL THEN 1 ELSE 0 END) AS FG_PROCESS
FROM V$PROCESS;

-- 비정상 세션 현황 모니터링
SELECT STATUS, COUNT(*) AS CNT
FROM V$SESSION
WHERE TYPE = 'USER'
GROUP BY STATUS
ORDER BY CNT DESC;

2. 정기적인 헬스체크 및 Oracle Patch 적용

Oracle 내부 버그로 인한 프로세스 비정상 종료를 방지하기 위해, My Oracle Support(MOS)에서 권고하는 최신 PSU(Patch Set Update) 또는 RU(Release Update)를 정기적으로 적용하는 패치 관리 프로세스를 수립해야 합니다. 특히 RAC 환경에서는 Grid Infrastructure와 RDBMS 패치 레벨을 일치시키는 것이 중요하며, 패치 적용 전후로 opatch lsinventory 명령으로 패치 상태를 문서화하고, 주기적으로 Database Health Monitor(DHM) 또는 DBMS_HM 패키지를 통해 헬스체크를 실행하는 것이 Best Practice입니다.

-- Oracle Health Monitor 실행 (자동 진단)
BEGIN
    DBMS_HM.RUN_CHECK(
        check_name   => 'Process Failure Check',
        run_name     => 'MANUAL_PROCESS_CHECK_' || TO_CHAR(SYSDATE,'YYYYMMDD'),
        input_params => NULL
    );
END;
/

-- 헬스체크 결과 확인
SELECT RUN_NAME, CHECK_NAME, STATUS, START_TIME, END_TIME
FROM V$HM_RUN
ORDER BY START_TIME DESC
FETCH FIRST 10 ROWS ONLY;