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

ORA-01115
2026년 07월 06일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01115 IO error reading block from file 는?

ORA-01115 에러는 Oracle 데이터베이스가 데이터 파일로부터 특정 블록을 읽어들이는 과정에서 I/O(입출력) 오류가 발생했을 때 나타나는 에러입니다. 이 에러는 주로 운영체제 수준의 파일 시스템 문제, 스토리지 장애, 또는 데이터 파일 자체의 물리적 손상과 밀접하게 연관되어 있습니다. DBA 입장에서는 즉각적인 대응이 필요한 심각한 에러 중 하나로, 데이터 유실 가능성이 있으므로 반드시 신속하게 원인을 파악하고 복구 절차를 밟아야 합니다.

주요 발생 원인

1. 데이터 파일의 물리적 손상 또는 스토리지 장애

가장 빈번하게 발생하는 원인으로, 디스크 불량 섹터(Bad Sector), SAN/NAS 스토리지 오류, 또는 파일 시스템 손상이 이에 해당합니다. Oracle이 특정 데이터 블록을 읽으려 할 때 OS 또는 스토리지 레이어에서 I/O 요청이 실패하면서 이 에러가 발생합니다. 스토리지 벤더의 로그와 OS의 /var/log/messages 또는 Windows 이벤트 뷰어를 반드시 함께 확인해야 합니다.

2. 데이터 파일 접근 권한 문제 또는 파일 유실

Oracle 프로세스가 데이터 파일에 접근하려 할 때 파일이 삭제되었거나, OS 수준의 파일 권한이 변경되어 읽기 권한이 없는 경우에도 이 에러가 발생할 수 있습니다. 특히 배치 작업이나 외부 스크립트에 의해 실수로 데이터 파일이 삭제되거나 이동되는 경우가 실무에서 종종 발생합니다. 이 경우 OS 레벨에서 파일 존재 여부와 권한을 먼저 점검해야 합니다.

3. Oracle 데이터 블록 자체의 논리적 손상 (Block Corruption)

물리적 I/O는 성공하지만, 읽어온 블록의 체크섬(Checksum)이 맞지 않거나 블록 헤더 정보가 손상된 경우 논리적 블록 손상으로 간주되어 이 에러가 동반될 수 있습니다. 이는 ORA-01578 에러와 함께 발생하는 경우가 많으며, DBMS_REPAIR 패키지나 RMAN의 RECOVER BLOCK 기능을 통해 복구를 시도해야 합니다. 블록 손상 여부는 RMAN의 VALIDATE 명령으로 사전에 감지할 수 있습니다.

해결 방법

1단계: 에러 발생 파일 및 블록 확인

먼저 Alert Log와 트레이스 파일을 통해 어떤 파일의 몇 번 블록에서 에러가 발생했는지 확인합니다.

-- Alert Log 위치 확인
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'background_dump_dest';

-- 최근 발생한 에러 메시지 확인 (Oracle 11g 이상)
SELECT * FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

-- 데이터 파일 상태 확인
SELECT FILE#, NAME, STATUS, BLOCKS, BLOCK_SIZE
FROM V$DATAFILE
ORDER BY FILE#;

-- 문제 파일 상세 확인
SELECT FILE#, STATUS, FUZZY, CHECKPOINT_CHANGE#, LAST_CHANGE#
FROM V$DATAFILE_HEADER;

2단계: RMAN을 활용한 블록 손상 여부 검사

-- RMAN 접속 후 전체 데이터베이스 검증
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

-- 특정 데이터 파일만 검증 (파일 번호가 5인 경우)
RMAN> BACKUP VALIDATE CHECK LOGICAL DATAFILE 5;

-- 손상된 블록 목록 조회
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;

3단계: 손상된 블록 복구 (RMAN Block Recovery)

-- RMAN을 통한 개별 블록 복구
-- V$DATABASE_BLOCK_CORRUPTION에서 확인한 파일번호와 블록번호 사용
RMAN> RECOVER DATAFILE 5 BLOCK 100;

-- 다수의 손상 블록 일괄 복구
RMAN> RECOVER CORRUPTION LIST;

4단계: DBMS_REPAIR를 활용한 논리적 블록 복구

-- 손상 블록 감지 테이블 생성
BEGIN
  DBMS_REPAIR.ADMIN_TABLES(
    TABLE_NAME  => 'REPAIR_TABLE',
    TABLE_TYPE  => DBMS_REPAIR.REPAIR_TABLE,
    ACTION      => DBMS_REPAIR.CREATE_ACTION,
    TABLESPACE  => 'SYSAUX'
  );
END;
/

-- 특정 테이블의 손상 블록 감지
DECLARE
  v_num_corrupt INT;
BEGIN
  DBMS_REPAIR.CHECK_OBJECT(
    SCHEMA_NAME      => 'SCOTT',
    OBJECT_NAME      => 'EMP',
    REPAIR_TABLE_NAME => 'REPAIR_TABLE',
    CORRUPT_COUNT    => v_num_corrupt
  );
  DBMS_OUTPUT.PUT_LINE('손상 블록 수: ' || v_num_corrupt);
END;
/

-- 손상 블록 소프트 마킹 (건너뛰기 처리)
BEGIN
  DBMS_REPAIR.FIX_CORRUPT_BLOCKS(
    SCHEMA_NAME       => 'SCOTT',
    OBJECT_NAME       => 'EMP',
    REPAIR_TABLE_NAME => 'REPAIR_TABLE'
  );
END;
/

5단계: 데이터 파일 권한 및 존재 여부 확인 (OS 레벨)

-- 데이터 파일 경로 확인
SELECT FILE#, NAME, BYTES/1024/1024 AS SIZE_MB, STATUS
FROM V$DATAFILE;

-- Offline된 데이터 파일 Online으로 전환 시도
ALTER DATABASE DATAFILE '/oracle/oradata/prod/users01.dbf' ONLINE;

-- 데이터 파일을 새 경로로 이동 후 등록
ALTER DATABASE RENAME FILE '/old_path/users01.dbf'
  TO '/new_path/users01.dbf';

예방 방법

1. 정기적인 RMAN Backup Validation 스케줄링

단순히 백업을 수행하는 것에 그치지 않고, RMAN의 BACKUP VALIDATE 명령을 주기적으로(최소 주 1회) 실행하여 블록 손상을 사전에 감지하는 루틴을 수립해야 합니다. 또한 DB_BLOCK_CHECKSUM 파라미터를 TYPICAL 이상으로 설정하여 Oracle이 블록 기록 시 체크섬을 자동으로 검증하도록 구성하는 것이 중요합니다.

-- 블록 체크섬 설정 확인 및 변경
SHOW PARAMETER DB_BLOCK_CHECKSUM;
ALTER SYSTEM SET DB_BLOCK_CHECKSUM = TYPICAL SCOPE=BOTH;

-- 블록 쓰기 검증 설정 (I/O 오버헤드 있으나 안전성 향상)
ALTER SYSTEM SET DB_BLOCK_CHECKING = MEDIUM SCOPE=BOTH;

2. ASM(Automatic Storage Management) 및 스토리지 모니터링 강화

가능하다면 Oracle ASM을 활용하여 스토리지를 관리하고, ASM의 미러링 기능을 통해 디스크 장애 시 자동 복구가 가능하도록 구성합니다. OS 레벨에서도 iostat, sar 등의 모니터링 도구를 활용하거나 엔터프라이즈 스토리지 모니터링 솔루션을 도입하여 I/O 오류를 실시간으로 감지하고 알림을 받을 수 있는 체계를 갖추어야 합니다.