[Oracle] ORA-03113 · ORA-03114 · ORA-24324 장애 복구

Oracle ORA-03113 · ORA-03114 · ORA-24324 장애 복구 가이드

아래 오류들은 Oracle 인스턴스가 **비정상 종료되었거나 메모리 구조(SGA/PGA)가 손상된 경우** 자주 함께 나타나는 오류 조합입니다.

• ORA-03113: end-of-file on communication channel
• ORA-03114: not connected to ORACLE
• ORA-24324: service handle not initialized
• ORA-01041: hostdef extension doesn't exist

동시에 나타날 경우, 이는 단순 커넥션 종료 문제가 아니라 DB 인스턴스 손상, redo 적용 중단, 컨트롤파일 불일치가 발생했음을 의미합니다.

1️⃣ 장애 증상 (예시 로그 기반)

DB를 startup 하였으나 mount 과정에서 세션이 끊기고, 이후 모든 명령이 hostdef 오류로 실패하는 전형적 패턴:

ORA-03113: end-of-file on communication channel
ORA-03114: not connected to ORACLE
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist

이후 connected to an idle instance 상태가 반복되고, 정상 startup 불가.

2️⃣ 원인 분석

✔ 1. 인스턴스 비정상 종료

• OS 수준에서 프로세스 강제 종료
• 메모리 부족(OOM)
• 디스크 I/O 지연으로 LGWR/DBWR hang → crash

✔ 2. redo / controlfile 불일치

장애 시 redo 필요한 부분이 incomplete 상태일 때 발생.

✔ 3. crash 후 SGA 손상

hostdef / service handle 오류는 대부분 SGA 초기화 실패 또는 불일치 문제에서 발생.

✔ 4. 인스턴스가 mount 직전에서 반복 crash

3️⃣ 복구 절차 — 안전한 표준 프로세스

아래는 실제 예시에 기반한 정상적인 복구 흐름입니다.

① 강제 종료

shutdown abort;

SGA가 정상 상태가 아니므로 abort가 필수.

② 인스턴스 재기동 (NOMOUNT)

startup nomount;

③ controlfile 로드 (MOUNT)

alter database mount;

④ media recovery 진행

예시에서는 redo 상태가 정상적이었기 때문에 auto-complete됨.

recover database until cancel;
Media recovery complete.

⑤ RESETLOGS 오픈

컨트롤파일과 redo 상태가 맞지 않거나 crash recovery가 필요한 경우 아래가 정답.

alter database open resetlogs;

⑥ 정상 종료 후 재기동

shutdown immediate;
startup;

이후 정상적으로 mount → open 까지 진행되면 복구 완료.

4️⃣ 추가적으로 반드시 점검해야 할 항목

✔ alert.log 재확인

$ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log

✔ redo / archive 손상 여부

✔ 파일시스템 & 스토리지 상태

• I/O hang 발생 여부
• multipath 상태
• 디스크 타임아웃 메시지(dmesg) 존재 여부

✔ OOM 발생 여부

dmesg | grep -i kill

✔ controlfile 다중 구성 여부

CONTROL_FILES 값이 서로 다르면 recover 오류가 반복됨.

5️⃣ 언제 OPEN RESETLOGS가 필요한가?

아래 특징이 보이면 RESETLOGS는 거의 필수다.

• mounted 직후 ORA-03113로 crash
• recover database 시 redo 적용이 즉시 완료됨
• open 시 ORA-01113 / ORA-01110 동반
• crash recovery 수행 흔적(alert.log)

이는 redo → controlfile 간 SCN 불일치로 판단되기 때문.

7️⃣ 기본 오류 대응 4단계

① 외부 노출 확인
OS 로그, I/O 오류, 프로세스 강제 종료 여부 확인

② 관련 역할/기능 비활성화
비정상 종료 유발 서비스, agent, 모니터링 도구 점검

③ 포트·프로세스 차단
DB Listener 재기동, 문제 세션 차단

④ 로그 모니터링 강화
alert.log, LGWR/DBWR 메시지, redo 적용 로그 확인

8️⃣ 결론

이 장애는 단순한 세션 종료가 아니라 **인스턴스 손상 → redo/recovery 필요 → resetlogs 필요** 흐름으로 이어지는 전형적인 Oracle crash 복구 사례입니다.

예시에서 수행한 절차인 shutdown abort → startup nomount → mount → recover → open resetlogs 은 Oracle이 권장하는 표준 복구 흐름이며, 매우 올바른 대응입니다.

추가로, 재발 방지를 위해 OS 계층의 I/O, 메모리 이벤트(OOM), 스토리지 로그 점검을 반드시 병행해야 합니다.