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

ORA-01578
2026년 07월 25일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-01578 ORACLE data block corrupted 는?

ORA-01578은 Oracle 데이터베이스에서 데이터 블록(Data Block)이 물리적 또는 논리적으로 손상되었을 때 발생하는 심각한 에러입니다. 데이터베이스가 특정 블록을 읽거나 쓰는 과정에서 블록의 체크섬(Checksum)이 일치하지 않거나, 블록 헤더 정보가 유효하지 않을 경우 이 에러가 발생합니다. 이 에러는 단순한 쿼리 오류가 아니라 데이터 무결성에 직접적인 영향을 주는 치명적인 문제이므로, 즉각적인 조치가 반드시 필요합니다.

주요 발생 원인

1. 하드웨어 장애 (디스크 불량 또는 I/O 오류)

가장 흔한 원인으로, 물리적 디스크의 배드 섹터(Bad Sector)나 스토리지 컨트롤러의 오류가 데이터 블록을 손상시킵니다. RAID 컨트롤러의 캐시 문제나 SAN(Storage Area Network) 경로 불안정도 이 유형에 해당하며, 하드웨어 레벨에서 먼저 점검해야 합니다.

2. Oracle 소프트웨어 버그 또는 비정상 종료

Oracle 프로세스가 비정상적으로 종료되거나(Kill -9 등 강제 종료), 버그로 인해 블록이 디스크에 제대로 기록되지 않은 경우 손상이 발생할 수 있습니다. 특히 DB_BLOCK_CHECKSUM 파라미터가 비활성화된 환경에서는 손상 감지가 늦어져 피해가 더 커질 수 있습니다.

3. 메모리(RAM) 오류

SGA(System Global Area) 영역에서 메모리 오류가 발생하면, 손상된 데이터가 그대로 디스크에 기록될 수 있습니다. ECC(Error Correcting Code) 메모리가 아닌 환경이거나 메모리 모듈 자체에 결함이 있을 경우 이 유형의 블록 손상이 나타납니다.

해결 방법

Step 1: 손상된 블록 식별

에러 메시지에서 파일 번호(File#)와 블록 번호(Block#)를 확인한 후, 어떤 객체가 영향을 받는지 조회합니다.

-- 손상된 블록이 속한 세그먼트(테이블/인덱스) 확인
SELECT owner, segment_name, segment_type, partition_name
FROM dba_extents
WHERE file_id = &file_no
  AND &block_no BETWEEN block_id AND block_id + blocks - 1;

-- V$DATABASE_BLOCK_CORRUPTION 뷰로 손상 블록 전체 조회
SELECT file#, block#, blocks, corruption_type
FROM v$database_block_corruption
ORDER BY file#, block#;

Step 2: RMAN으로 블록 복구 (권장 방법)

RMAN의 BLOCKRECOVER 명령은 백업에서 손상된 블록만 선택적으로 복구하는 가장 효율적인 방법입니다.

-- RMAN을 사용한 블록 단위 복구
RMAN> BLOCKRECOVER DATAFILE 5 BLOCK 123;

-- V$DATABASE_BLOCK_CORRUPTION의 모든 손상 블록 일괄 복구
RMAN> BLOCKRECOVER CORRUPTION LIST;

-- 특정 테이블스페이스 전체 복구가 필요한 경우
RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;

Step 3: DBMS_REPAIR 패키지를 이용한 손상 블록 스킵 처리

RMAN 백업이 없는 경우, DBMS_REPAIR 패키지를 사용하여 손상된 블록을 “사용 불가” 상태로 마킹하고 나머지 데이터를 구출할 수 있습니다.

-- 1단계: 손상 블록 탐지 및 리포트 테이블 생성
BEGIN
  DBMS_REPAIR.ADMIN_TABLES(
    table_name  => 'REPAIR_TABLE',
    table_type  => DBMS_REPAIR.REPAIR_TABLE,
    action      => DBMS_REPAIR.CREATE_ACTION,
    tablespace  => 'USERS'
  );
END;
/

-- 2단계: 손상 블록 탐지 실행
DECLARE
  v_num_corrupt INTEGER;
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;
/

-- 3단계: 손상 블록을 SOFT CORRUPT로 마킹 (스킵 처리)
BEGIN
  DBMS_REPAIR.FIX_CORRUPT_BLOCKS(
    schema_name      => 'SCOTT',
    object_name      => 'EMP',
    repair_table_name => 'REPAIR_TABLE'
  );
END;
/

-- 4단계: 손상 블록을 제외하고 데이터 구출
CREATE TABLE scott.emp_rescued AS
SELECT * FROM scott.emp
WHERE ROWID NOT IN (
  SELECT ROWID FROM scott.emp
  /* DBMS_REPAIR가 마킹한 블록은 자동으로 스킵됨 */
);

Step 4: 인덱스 손상의 경우 재생성

손상된 세그먼트가 인덱스인 경우, 테이블 데이터는 안전하므로 인덱스만 재생성하면 됩니다.

-- 기존 손상 인덱스 삭제 후 재생성
DROP INDEX scott.emp_idx;

CREATE INDEX scott.emp_idx ON scott.emp(empno)
  TABLESPACE users
  PARALLEL 4;

-- 병렬 처리 후 원복
ALTER INDEX scott.emp_idx NOPARALLEL;

예방 방법

1. DB_BLOCK_CHECKSUM 활성화 및 정기적인 RMAN 검증 수행

DB_BLOCK_CHECKSUM 파라미터를 TYPICAL 또는 FULL로 설정하면, 블록이 디스크에 기록될 때마다 체크섬을 검증하여 손상을 조기에 감지할 수 있습니다. 또한 RMAN의 VALIDATE DATABASE 명령을 주기적으로 실행하여 잠재적 손상 블록을 사전에 발견하는 것이 중요합니다.

-- DB_BLOCK_CHECKSUM 설정 확인 및 변경
SHOW PARAMETER db_block_checksum;

ALTER SYSTEM SET db_block_checksum = TYPICAL SCOPE=BOTH;

-- RMAN으로 정기적인 데이터베이스 무결성 검증 (크론잡 등록 권장)
-- RMAN 실행:
-- RMAN> VALIDATE DATABASE;
-- RMAN> VALIDATE DATAFILE 1, 2, 3;

2. 충분한 RMAN 백업 정책 유지 및 백업 유효성 검증

블록 손상 발생 시 RMAN 블록 복구가 가장 빠르고 안전한 방법입니다. 따라서 최소 7일 이상의 백업 보관 정책(Retention Policy)을 유지하고, RESTORE VALIDATE 명령으로 백업 파일 자체의 유효성도 주기적으로 검증해야 합니다.

-- RMAN 백업 보관 정책 설정
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

-- 백업 유효성 검증 (실제 복구 없이 검증만 수행)
RMAN> RESTORE DATABASE VALIDATE;
RMAN> RESTORE TABLESPACE users VALIDATE;