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

ORA-01135
2026년 07월 08일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01135 file accessed for DML/query is offline 는?

ORA-01135 에러는 Oracle 데이터베이스에서 DML(INSERT, UPDATE, DELETE) 또는 SELECT 쿼리를 실행할 때 해당 쿼리가 접근하려는 데이터 파일(datafile)이 오프라인(offline) 상태에 있을 때 발생합니다. 쉽게 말해, 테이블이나 인덱스가 위치한 테이블스페이스의 데이터 파일이 정상적으로 온라인 상태가 아니기 때문에 Oracle이 해당 파일을 읽거나 쓸 수 없는 상황입니다. 이 에러는 DBA가 의도적으로 특정 데이터 파일을 오프라인으로 전환했거나, 디스크 장애, 파일 시스템 오류 등 비정상적인 원인으로 파일이 접근 불가 상태가 되었을 때 주로 발생합니다.

주요 발생 원인

1. DBA 또는 운영자가 의도적으로 데이터 파일 또는 테이블스페이스를 오프라인으로 전환

운영 중에 특정 데이터 파일에 물리적 손상이 발생하거나 유지보수 목적으로 DBA가 ALTER DATABASE DATAFILE ... OFFLINE 명령 또는 ALTER TABLESPACE ... OFFLINE 명령을 실행한 경우입니다. 이 상태에서 해당 파일에 속한 세그먼트(테이블, 인덱스 등)에 접근하려는 모든 SQL 구문은 ORA-01135 에러를 반환합니다. 특히 아카이브 로그 모드가 아닌 NOARCHIVELOG 모드에서 데이터 파일을 오프라인으로 전환하면 해당 파일을 다시 온라인으로 복구하는 것이 불가능해질 수 있으므로 각별한 주의가 필요합니다.

2. 디스크 장애 또는 OS 파일 시스템 문제로 인한 파일 접근 불가

스토리지 장비 장애, NFS 마운트 해제, 디스크 꽉 참(disk full), 파일 시스템 손상 등 OS 레벨의 물리적/논리적 문제로 인해 Oracle이 데이터 파일에 접근하지 못하게 되면, Oracle은 해당 데이터 파일을 자동으로 오프라인 상태로 표시합니다. 이 경우 Alert Log에 관련 ORA-01115, ORA-01116, ORA-27072 등의 선행 에러가 기록되며, 이후 해당 파일에 접근하는 모든 세션에서 ORA-01135가 발생합니다. 이러한 경우는 단순한 온라인 전환 명령만으로는 해결되지 않으며, 물리적 원인 제거와 미디어 복구(Media Recovery)가 필요합니다.

3. 불완전 복구(Incomplete Recovery) 또는 RMAN 복구 작업 후 데이터 파일 상태 불일치

RMAN을 이용한 복구 작업 도중 특정 데이터 파일만 복구가 누락되거나, Point-in-Time Recovery(PITR) 후 일부 데이터 파일의 SCN(System Change Number)이 데이터베이스 전체 SCN과 맞지 않아 Oracle이 해당 파일을 오프라인 처리하는 경우가 있습니다. 또한 데이터베이스를 오픈할 때 RESETLOGS 옵션을 사용한 후, 이전 인카네이션(incarnation)에 속하는 파일들이 오프라인 상태로 남아있는 경우에도 이 에러가 발생합니다. 이 경우 V$DATAFILE 뷰의 STATUS 컬럼과 V$RECOVER_FILE 뷰를 통해 복구 대상 파일을 정확히 파악해야 합니다.

해결 방법

1단계: 현재 오프라인 데이터 파일 확인

먼저 어떤 데이터 파일이 오프라인 상태인지 확인합니다.

-- 오프라인 상태의 데이터 파일 확인
SELECT file#, name, status, checkpoint_change#
FROM v$datafile
WHERE status IN ('OFFLINE', 'RECOVER');

-- 테이블스페이스별 파일 상태 확인
SELECT t.name AS tablespace_name,
       d.file# AS file_id,
       d.name AS file_name,
       d.status AS file_status
FROM v$tablespace t
JOIN v$datafile d ON t.ts# = d.ts#
WHERE d.status != 'ONLINE'
ORDER BY t.name;

-- 복구가 필요한 파일 목록 확인
SELECT * FROM v$recover_file;

2단계: 원인 파악 후 해결

[원인 1 해결] 의도적 오프라인 전환 후 온라인 복구 (ARCHIVELOG 모드)

-- 아카이브 로그 모드에서 데이터 파일 미디어 복구 후 온라인 전환
-- Step 1: 데이터 파일 복구
RECOVER DATAFILE '/u01/oradata/ORCL/users01.dbf';

-- Step 2: 데이터 파일 온라인 전환
ALTER DATABASE DATAFILE '/u01/oradata/ORCL/users01.dbf' ONLINE;

-- Step 3: 테이블스페이스 전체를 오프라인/온라인 전환하는 경우
ALTER TABLESPACE users OFFLINE;
-- ... 유지보수 작업 수행 ...
ALTER TABLESPACE users ONLINE;

-- Step 4: 정상 복구 여부 확인
SELECT file#, name, status FROM v$datafile
WHERE name LIKE '%users01%';

[원인 2 해결] 디스크/파일 시스템 장애 복구 (RMAN 사용)

-- Alert Log 에서 선행 에러 확인 후 RMAN 복구 수행
-- RMAN 복구 절차 예시

-- Step 1: RMAN 접속
-- $ rman target /

-- Step 2: 오프라인 파일 복구 (RMAN 내에서 실행)
-- RMAN> RESTORE DATAFILE 5;
-- RMAN> RECOVER DATAFILE 5;
-- RMAN> SQL 'ALTER DATABASE DATAFILE 5 ONLINE';

-- SQL*Plus 에서 파일 번호로 온라인 전환
ALTER DATABASE DATAFILE 5 ONLINE;

-- 특정 테이블스페이스 전체 복구
-- RMAN> RESTORE TABLESPACE users;
-- RMAN> RECOVER TABLESPACE users;
-- RMAN> SQL 'ALTER TABLESPACE users ONLINE';

[원인 3 해결] 불완전 복구 후 데이터 파일 상태 정상화

-- v$recover_file 확인
SELECT file#, online, online_status, error, change#, time
FROM v$recover_file;

-- SCN 불일치로 오프라인된 파일 복구 (RMAN PITR 이후)
-- RMAN에서:
-- RMAN> RESTORE DATAFILE <file#> UNTIL SCN <target_scn>;
-- RMAN> RECOVER DATAFILE <file#>;

-- 복구 후 온라인 전환
ALTER DATABASE DATAFILE <file#> ONLINE;

-- 데이터베이스 전체 상태 확인
SELECT name, open_mode, log_mode FROM v$database;
SELECT file#, status, fuzzy, checkpoint_change# FROM v$datafile_header;

[원인 공통] 테이블스페이스 READ ONLY 모드로 인한 DML 오류 확인

-- READ ONLY 테이블스페이스 확인 (DML 불가)
SELECT tablespace_name, status
FROM dba_tablespaces
WHERE status = 'READ ONLY';

-- READ WRITE로 전환 (필요 시)
ALTER TABLESPACE users READ WRITE;

예방 방법

1. 정기적인 데이터 파일 상태 모니터링 및 알림 설정

ORA-01135가 발생하기 전에 선제적으로 데이터 파일 상태를 주기적으로 점검하는 모니터링 스크립트를 스케줄러(DBMS_SCHEDULER 또는 OS cron)에 등록하여 오프라인 파일이 감지되면 즉시 DBA에게 알림이 가도록 설정해야 합니다. 또한 Oracle Enterprise Manager(OEM) 또는 서드파티 모니터링 툴을 활용하여 v$datafile, v$tablespace 뷰의 상태 변화를 지속적으로 감시하고, Alert Log를 실시간으로 파싱하여 ORA- 에러 발생 시 즉각 대응하는 체계를 구축하는 것이 중요합니다.

-- 모니터링용 쿼리 예시 (정기 실행 권장)
SELECT d.file#,
       t.name AS tablespace_name,
       d.name AS file_name,
       d.status,
       d.bytes / 1024 / 1024 AS size_mb
FROM v$datafile d
JOIN v$tablespace t ON d.ts# = t.ts#
WHERE d.status NOT IN ('ONLINE', 'SYSTEM')
ORDER BY d.file#;

2. ARCHIVELOG 모드 운영 및 RMAN 백업 정책 철저 준수

NOARCHIVELOG 모드에서는 데이터 파일이 오프라인이 된 경우 미디어 복구가 불가능하여 데이터 손실이 불가피하므로, 운영 데이터베이스는 반드시 ARCHIVELOG 모드로 운영해야 합니다. 또한 RMAN을 통한 전체 백업(Full Backup)과 증분 백업(Incremental Backup)을 정기적으로 수행하고, 백업 완료 후 VALIDATE 명령으로 백업 세트의 무결성을 검증하며, 복구 테스트(Recovery Drill)를 주기적으로 수행하여 실제 장애 발생 시 신속하게 복구할 수 있는 준비 태세를 갖춰야 합니다.

-- 데이터베이스 ARCHIVELOG 모드 확인
SELECT log_mode FROM v$database;

-- RMAN 최근 백업 현황 확인
-- RMAN> LIST BACKUP SUMMARY;
-- RMAN> REPORT NEED BACKUP;