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

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

이 글에서 다루는 내용

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

ORA-00340 IO error processing online log of thread 는?

ORA-00340 에러는 Oracle 데이터베이스가 온라인 리두 로그(Online Redo Log) 파일을 읽거나 쓰는 과정에서 입출력(I/O) 오류가 발생했을 때 나타나는 심각한 에러입니다. 이 에러는 데이터베이스의 핵심 컴포넌트인 리두 로그 파일에 접근할 수 없거나, 파일 자체가 손상되었을 때 주로 발생하며, 방치할 경우 데이터베이스 인스턴스가 비정상 종료되거나 데이터 손실로 이어질 수 있습니다. 일반적으로 alert log 파일에 해당 에러와 함께 어느 thread와 sequence 번호에서 문제가 발생했는지 상세 정보가 기록되므로, 즉각적인 원인 파악과 대응이 필요합니다.

주요 발생 원인

1. 온라인 리두 로그 파일의 물리적 손상 또는 삭제

온라인 리두 로그 파일이 OS 레벨에서 실수로 삭제되거나, 디스크 불량(Bad Sector) 등으로 인해 물리적으로 손상된 경우 이 에러가 발생합니다. Oracle은 트랜잭션을 기록하기 위해 리두 로그 파일에 지속적으로 쓰기 작업을 수행하는데, 해당 파일이 존재하지 않거나 읽을 수 없는 상태라면 LGWR(Log Writer) 프로세스가 실패하면서 ORA-00340이 트리거됩니다. 이 경우는 가장 치명적인 상황 중 하나로, 즉각적인 복구 작업이 요구됩니다.

2. 파일 시스템 또는 스토리지 레이어의 I/O 오류

SAN, NAS 또는 로컬 디스크에서 발생하는 스토리지 레벨의 I/O 에러가 Oracle 리두 로그 파일 접근에 영향을 미치는 경우입니다. 네트워크 파일 시스템(NFS) 마운트 해제, ASM 디스크 그룹의 디스크 장애, 또는 볼륨 매니저의 오작동 등이 이 문제를 유발할 수 있습니다. 특히 RAC(Real Application Clusters) 환경에서는 공유 스토리지 문제가 여러 노드에 동시에 영향을 미쳐 더욱 심각한 상황을 초래합니다.

3. 파일 권한(Permission) 문제 또는 OS 리소스 부족

Oracle 프로세스가 리두 로그 파일에 접근하기 위한 충분한 OS 파일 권한이 없거나, 파일 디스크립터(File Descriptor) 한계 초과, 디스크 공간 부족 등의 OS 레벨 문제로 인해 발생할 수 있습니다. oracle 계정의 권한이 변경되거나 umask 설정이 잘못된 경우에도 리두 로그 파일 접근이 실패할 수 있습니다. 이런 유형의 원인은 상대적으로 해결이 간단하지만, 빠른 진단이 중요합니다.

해결 방법

1단계: 현재 리두 로그 상태 확인

가장 먼저 어느 로그 그룹에서 문제가 발생했는지 파악해야 합니다.

-- 온라인 리두 로그 그룹 및 멤버 상태 확인
SELECT a.GROUP#, a.THREAD#, a.SEQUENCE#, a.MEMBERS,
       a.ARCHIVED, a.STATUS, b.MEMBER, b.STATUS AS FILE_STATUS
FROM V$LOG a
JOIN V$LOGFILE b ON a.GROUP# = b.GROUP#
ORDER BY a.GROUP#, b.MEMBER;

-- alert log 경로 확인 (Oracle 11g 이상)
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- 현재 활성 로그 그룹 확인
SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG WHERE STATUS = 'CURRENT';

2단계: 손상된 리두 로그 파일 복구 (Multiplexing된 경우)

리두 로그 멀티플렉싱이 설정되어 있다면, 손상되지 않은 멤버가 존재할 수 있습니다.

-- 특정 로그 그룹에 새 멤버 추가 (기존 손상 멤버 대체 목적)
ALTER DATABASE ADD LOGFILE MEMBER '/u01/oradata/orcl/redo01b.log' TO GROUP 1;

-- 손상된 멤버 삭제 (그룹 내 다른 정상 멤버가 있을 때만 가능)
ALTER DATABASE DROP LOGFILE MEMBER '/u01/oradata/orcl/redo01_bad.log';

3단계: INACTIVE 상태 로그 그룹 재생성

해당 로그 그룹이 INACTIVE 상태라면(아카이빙 완료된 상태), 해당 그룹을 삭제 후 재생성할 수 있습니다.

-- 로그 그룹 상태가 INACTIVE인지 확인
SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG;

-- INACTIVE 그룹 삭제
ALTER DATABASE DROP LOGFILE GROUP 2;

-- 새 로그 그룹 추가 (멀티플렉싱 권장)
ALTER DATABASE ADD LOGFILE GROUP 2
  ('/u01/oradata/orcl/redo02a.log',
   '/u02/oradata/orcl/redo02b.log') SIZE 200M;

4단계: CURRENT 또는 ACTIVE 상태 로그 손상 시 (최악의 시나리오)

현재 사용 중인(CURRENT) 또는 아직 체크포인트가 완료되지 않은(ACTIVE) 그룹의 파일이 손상된 경우, 불완전 복구(Incomplete Recovery)가 필요할 수 있습니다.

-- RMAN을 이용한 복구 시도 (가능한 경우)
-- RMAN 프롬프트에서:
-- RECOVER DATABASE UNTIL CANCEL;

-- SQL*Plus에서 불완전 복구 후 RESETLOGS 오픈
SHUTDOWN ABORT;
STARTUP MOUNT;

-- 리두 로그를 초기화하여 강제 오픈 (최후 수단, 데이터 손실 가능)
ALTER DATABASE OPEN RESETLOGS;

-- 이후 즉시 전체 백업 수행 권장

5단계: 파일 권한 및 존재 여부 확인

-- OS 레벨에서 확인 (DBA가 직접 실행)
-- ls -la /u01/oradata/orcl/redo*.log
-- chown oracle:oinstall /u01/oradata/orcl/redo*.log
-- chmod 640 /u01/oradata/orcl/redo*.log

-- Oracle에서 로그 파일 경로 재확인
SELECT GROUP#, MEMBER, STATUS FROM V$LOGFILE ORDER BY GROUP#;

-- ASM 사용 환경에서 디스크 그룹 상태 확인
SELECT NAME, STATE, TOTAL_MB, FREE_MB FROM V$ASM_DISKGROUP;

예방 방법

1. 온라인 리두 로그 멀티플렉싱(Multiplexing) 구성

모든 프로덕션 환경에서는 반드시 각 리두 로그 그룹에 최소 2개 이상의 멤버를 서로 다른 물리적 디스크나 경로에 배치해야 합니다. 멀티플렉싱이 적용되면 하나의 멤버 파일이 손상되더라도 Oracle은 다른 정상 멤버를 통해 작업을 계속할 수 있어, ORA-00340 발생 시에도 즉각적인 서비스 중단 없이 복구 시간을 확보할 수 있습니다.

-- 현재 로그 멀티플렉싱 상태 점검 쿼리
SELECT GROUP#, COUNT(*) AS MEMBER_COUNT
FROM V$LOGFILE
GROUP BY GROUP#
HAVING COUNT(*) < 2; -- 2개 미만인 그룹 식별

-- 멀티플렉싱 추가 예시
ALTER DATABASE ADD LOGFILE MEMBER
  '/u02/oradata/orcl/redo01b.log' TO GROUP 1,
  '/u02/oradata/orcl/redo02b.log' TO GROUP 2,
  '/u02/oradata/orcl/redo03b.log' TO GROUP 3;

2. 정기적인 스토리지 및 리두 로그 모니터링 자동화

OS 레벨의 디스크 상태(SMART 점검, iostat 등)와 Oracle 레벨의 리두 로그 상태를 주기적으로 모니터링하는 스크립트를 cron 또는 Oracle Scheduler로 등록해 두면 조기에 이상 징후를 감지할 수 있습니다.

-- Oracle Scheduler를 활용한 리두 로그 상태 모니터링 잡 예시
BEGIN
  DBMS_SCHEDULER.CREATE_JOB(
    job_name        => 'MONITOR_REDO_LOGS',
    job_type        => 'PLSQL_BLOCK',
    job_action      => '
      DECLARE
        v_count NUMBER;
      BEGIN
        SELECT COUNT(*) INTO v_count
        FROM V$LOGFILE
        WHERE STATUS = ''INVALID'' OR STATUS = ''DELETED'';
        IF v_count > 0 THEN
          -- 알림 발송 또는 로그 테이블 기록
          INSERT INTO DBA_ALERT_LOG (alert_time, alert_msg)
          VALUES (SYSDATE, ''REDO LOG FILE ISSUE DETECTED: '' || v_count || '' files affected'');
          COMMIT;
        END IF;
      END;',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=HOURLY;INTERVAL=1',
    enabled         => TRUE,
    comments        => 'Monitor redo log file health'
  );
END;
/