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

ORA-01090
2026년 07월 04일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01090 shutdown in progress – connection is not permitted 는?

ORA-01090 에러는 Oracle 데이터베이스가 종료(Shutdown) 진행 중일 때 새로운 클라이언트 연결을 시도하면 발생하는 에러입니다. 데이터베이스가 SHUTDOWN IMMEDIATE, SHUTDOWN TRANSACTIONAL, 또는 SHUTDOWN NORMAL 명령으로 종료 절차를 밟고 있는 동안, 리스너는 여전히 살아 있어 연결 요청을 받을 수 있지만 Oracle 인스턴스 자체가 새로운 세션 생성을 거부합니다. 특히 배치 작업, 애플리케이션 서버, 모니터링 도구 등이 자동으로 재연결을 시도하는 환경에서 빈번하게 나타나며, 운영자가 즉각 인지하지 못하면 연쇄적인 장애로 이어질 수 있습니다.

주요 발생 원인

1. 계획된 데이터베이스 종료 중 애플리케이션 재연결 시도

DBA가 패치 적용, 백업, 또는 유지보수 목적으로 데이터베이스를 종료하는 도중, 애플리케이션 서버나 미들웨어의 커넥션 풀(Connection Pool)이 유효하지 않은 커넥션을 감지하고 자동으로 재연결을 시도하는 경우에 발생합니다. 커넥션 풀 설정에서 재연결 인터벌이 짧게 설정되어 있을수록 이 에러가 반복적으로 로그에 기록됩니다. 특히 WAS(Web Application Server)와 Oracle 사이에 별도의 연결 유효성 검사(Validation Query) 없이 운영되는 경우 더욱 빈번하게 발생합니다.

2. SHUTDOWN ABORT 이후 비정상적인 인스턴스 복구 중 연결 시도

SHUTDOWN ABORT 명령이 실행된 직후 Oracle은 Instance Recovery를 수행하게 되며, 이 복구 단계가 완전히 완료되기 전에 연결을 시도하면 ORA-01090이 발생할 수 있습니다. STARTUP 명령이 내부적으로 롤백(Undo) 작업을 수행하는 동안 데이터베이스는 OPEN 상태처럼 보이지 않기 때문에, 모니터링 스크립트나 헬스체크 툴이 이 타이밍에 연결을 시도하면 에러가 발생합니다. 이 경우는 실제로 데이터베이스에 문제가 있는 것이 아니라 순간적인 타이밍 이슈입니다.

3. RAC 환경에서 특정 노드 종료 시 로드 밸런서 미설정 문제

Oracle RAC(Real Application Clusters) 환경에서 특정 노드를 종료할 때 로드 밸런서 또는 SCAN(Single Client Access Name) 설정이 제대로 되어 있지 않으면, 이미 종료 중인 노드로 새로운 연결 요청이 계속 라우팅되어 ORA-01090이 발생합니다. 서비스 재배치(Service Relocation)가 자동으로 이루어지지 않거나 TAF(Transparent Application Failover) 설정이 미흡한 경우에도 동일한 문제가 발생합니다. RAC 환경에서는 노드 종료 전 반드시 서비스 이전 절차를 먼저 수행해야 합니다.

해결 방법

원인 1 해결: 데이터베이스 상태 확인 후 재시작

먼저 현재 데이터베이스의 상태를 확인합니다.

-- 데이터베이스 상태 확인
SELECT STATUS, DATABASE_STATUS, INSTANCE_NAME
FROM V$INSTANCE;

-- 데이터베이스가 종료 중인지 확인
SELECT VALUE
FROM V$PARAMETER
WHERE NAME = 'db_name';

데이터베이스가 완전히 종료된 것을 확인한 후 재기동합니다.

-- SQL*Plus 접속 후 재기동
CONNECT / AS SYSDBA

-- 데이터베이스 시작
STARTUP;

-- 기동 후 상태 확인
SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS
FROM V$INSTANCE;

-- 열린 세션 확인
SELECT COUNT(*) AS SESSION_COUNT
FROM V$SESSION
WHERE STATUS = 'ACTIVE';

원인 2 해결: Instance Recovery 완료 대기 및 모니터링

SHUTDOWN ABORT 이후 재기동 시 Instance Recovery 진행 상황을 모니터링합니다.

-- Instance Recovery 진행 상황 모니터링
SELECT RECOVERY_ESTIMATED_IOS,
       ACTUAL_IOS_DONE,
       ESTIMATED_IOS,
       RECOVERY_ESTIMATED_IOS - ACTUAL_IOS_DONE AS REMAINING_IOS
FROM V$INSTANCE_RECOVERY;

-- Alert Log에서 복구 완료 메시지 확인 (External Script 참고용)
-- tail -f $ORACLE_BASE/diag/rdbms/<dbname>/<instance>/trace/alert_<instance>.log

-- 복구 완료 후 데이터베이스 상태 재확인
SELECT STATUS FROM V$INSTANCE;

-- Undo 세그먼트 상태 확인
SELECT SEGMENT_NAME, STATUS
FROM DBA_ROLLBACK_SEGS
WHERE STATUS != 'ONLINE'
ORDER BY SEGMENT_NAME;

원인 3 해결: RAC 환경에서 서비스 이전 후 노드 종료

RAC 환경에서는 노드 종료 전 서비스를 먼저 다른 노드로 이전합니다.

-- 현재 서비스 상태 확인
SELECT NAME, NETWORK_NAME, ENABLED, AQ_HA_NOTIFICATIONS
FROM DBA_SERVICES
ORDER BY NAME;

-- 특정 노드에서 실행 중인 서비스 확인
SELECT SERVICE_NAME, INST_ID, STATUS
FROM GV$SESSION
WHERE INST_ID = 1  -- 종료할 노드 번호
GROUP BY SERVICE_NAME, INST_ID, STATUS;

-- 서비스를 다른 노드로 이전 (SRVCTL 사용 - OS 레벨)
-- srvctl relocate service -d <db_name> -s <service_name> -i <old_instance> -t <new_instance>

-- 이전 후 연결 세션이 없는지 확인
SELECT COUNT(*) AS ACTIVE_SESSIONS
FROM GV$SESSION
WHERE INST_ID = 1
  AND USERNAME IS NOT NULL
  AND STATUS = 'ACTIVE';

-- 안전하게 노드 종료
SHUTDOWN IMMEDIATE;

애플리케이션 측 연결 검증 쿼리 예시

커넥션 풀에서 사용할 유효성 검사 쿼리를 설정하면 에러를 사전에 방지할 수 있습니다.

-- 커넥션 유효성 검사에 사용하는 가장 가벼운 쿼리
SELECT 1 FROM DUAL;

-- 또는 데이터베이스 상태를 포함한 검사
SELECT INSTANCE_NAME, STATUS
FROM V$INSTANCE
WHERE STATUS = 'OPEN';

예방 방법

1. 유지보수 계획 수립 및 사전 공지 자동화

데이터베이스 종료 전 애플리케이션 서버의 커넥션 풀을 먼저 드레인(Drain)하는 절차를 표준화해야 합니다. Oracle Database 12c 이상에서는 Planned Maintenance 기능을 활용하여 Application Continuity와 함께 무중단에 가까운 종료 절차를 구현할 수 있습니다. 또한 종료 전 아래와 같이 현재 활성 세션을 확인하고 정리하는 스크립트를 표준 운영 절차(SOP)에 포함시켜야 합니다.

-- 종료 전 활성 세션 확인 및 정리 스크립트
SELECT 'ALTER SYSTEM KILL SESSION ''' || SID || ',' || SERIAL# || ''' IMMEDIATE;'
FROM V$SESSION
WHERE USERNAME IS NOT NULL
  AND STATUS = 'ACTIVE'
  AND USERNAME NOT IN ('SYS', 'SYSTEM', 'DBSNMP');

2. 모니터링 도구에 데이터베이스 상태 사전 확인 로직 추가

모니터링 스크립트나 헬스체크 툴이 연결을 시도하기 전에 리스너 상태와 데이터베이스 상태를 먼저 확인하는 로직을 추가해야 합니다. OEM(Oracle Enterprise Manager) 또는 커스텀 모니터링 솔루션을 사용하는 경우, 연결 실패 시 즉시 재연결하는 공격적인 재시도 정책 대신 지수 백오프(Exponential Backoff) 전략을 적용하여 데이터베이스 종료 중 불필요한 에러 로그가 쌓이지 않도록 관리해야 합니다.