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

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

이 글에서 다루는 내용

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

ORA-01172 recovery of thread stuck at block of file 는?

ORA-01172는 Oracle 데이터베이스의 미디어 복구(Media Recovery) 또는 인스턴스 복구(Instance Recovery) 도중, 특정 스레드(Thread)의 복구 작업이 특정 파일(File)의 특정 블록(Block)에서 멈춰 더 이상 진행되지 않을 때 발생하는 에러입니다. 이 에러는 주로 아카이브 로그 파일이 누락되었거나, 온라인 리두 로그(Online Redo Log)가 손상된 경우, 또는 데이터 파일이 물리적으로 손상된 상황에서 발생합니다. 복구 프로세스가 필요한 리두(Redo) 데이터를 찾지 못하거나 읽지 못할 때 이 에러와 함께 데이터베이스가 MOUNT 상태에 멈추게 됩니다.

주요 발생 원인

아카이브 로그 파일 누락 또는 손상

아카이브 로그(Archive Log) 파일이 삭제되었거나 물리적으로 손상된 경우, 복구 프로세스는 필요한 리두 변경 사항(Redo Changes)을 적용하지 못하고 해당 블록에서 멈추게 됩니다. 특히 불완전 복구(Incomplete Recovery) 환경이나 백업에서 복원한 데이터베이스에서 아카이브 로그 체인(Archive Log Chain)이 끊기면 이 에러가 빈번히 발생합니다. ARCHIVELOG 모드에서 운영하는 데이터베이스라면 아카이브 로그 파일의 연속성이 복구 성패를 좌우하는 핵심 요소입니다.

온라인 리두 로그(Online Redo Log) 손상 또는 비활성화

온라인 리두 로그 그룹이 손상되었거나, 데이터베이스가 비정상 종료(Abnormal Shutdown) 이후 CURRENT 또는 ACTIVE 상태의 리두 로그 그룹이 유실된 경우 복구 과정에서 이 에러가 발생합니다. Oracle은 인스턴스 복구 시 리두 로그를 반드시 참조해야 하는데, 이 파일이 없거나 읽을 수 없으면 복구가 특정 시점에서 블록됩니다. RAC(Real Application Clusters) 환경에서는 특정 노드(Thread)의 리두 로그 손상이 해당 스레드 복구를 막아 ORA-01172로 이어집니다.

데이터 파일의 물리적 블록 손상(Block Corruption)

데이터 파일 내 특정 블록이 물리적으로 손상된 경우, 복구 프로세스가 해당 블록에 리두를 적용하려 할 때 에러가 발생하고 복구가 중단됩니다. 이는 스토리지 장비의 I/O 오류, 운영체제 오류, 또는 디스크 불량 섹터로 인해 발생할 수 있으며, V$DATABASE_BLOCK_CORRUPTION 뷰를 통해 손상된 블록을 확인할 수 있습니다. 손상이 시스템 테이블스페이스(SYSTEM Tablespace)의 블록에 발생하면 데이터베이스 전체 복구가 불가능해질 수도 있어 더욱 심각합니다.

해결 방법

원인 1: 아카이브 로그 누락 시 해결 방법

먼저 어떤 아카이브 로그가 필요한지 확인합니다.

-- 현재 복구에 필요한 아카이브 로그 확인
SELECT * FROM V$RECOVERY_LOG;

-- 아카이브 로그 목록 및 상태 확인
SELECT SEQUENCE#, NAME, APPLIED, STATUS
FROM V$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE# FROM V$DATABASE)
ORDER BY SEQUENCE#;

-- 복구 상태 점검
SELECT * FROM V$RECOVERY_STATUS;

누락된 아카이브 로그를 다른 위치에서 복원한 후, RECOVER DATABASE 명령을 다시 시도합니다. 아카이브 로그 체인을 끊을 수 없는 경우, 불완전 복구를 통해 특정 시점까지만 복구하는 방법을 고려합니다.

-- RMAN을 이용한 불완전 복구 (특정 시점까지)
RMAN> RUN {
    SET UNTIL TIME "TO_DATE('2024-01-15 10:00:00','YYYY-MM-DD HH24:MI:SS')";
    RESTORE DATABASE;
    RECOVER DATABASE;
}

-- 불완전 복구 후 RESETLOGS로 오픈
ALTER DATABASE OPEN RESETLOGS;

원인 2: 온라인 리두 로그 손상 시 해결 방법

현재 온라인 리두 로그의 상태를 확인합니다.

-- 온라인 리두 로그 그룹 상태 확인
SELECT GROUP#, SEQUENCE#, STATUS, ARCHIVED, MEMBERS
FROM V$LOG
ORDER BY GROUP#;

-- 리두 로그 멤버 파일 경로 확인
SELECT GROUP#, MEMBER, STATUS
FROM V$LOGFILE
ORDER BY GROUP#;

-- 손상된 리두 로그 정보 확인
SELECT * FROM V$LOG_HISTORY
WHERE SEQUENCE# >= (SELECT MIN(SEQUENCE#) FROM V$LOG WHERE STATUS = 'CURRENT');

CURRENT/ACTIVE 상태의 리두 로그가 손상된 경우, 마지막 수단으로 _allow_resetlogs_corruption 숨김 파라미터를 사용할 수 있습니다. 이 방법은 데이터 손실이 발생할 수 있으므로 반드시 전문가와 상담 후 사용하십시오.

-- 최후 수단: 손상된 리두 로그를 강제로 무시하고 복구 시도
-- !! 주의: 이 파라미터 사용은 데이터 손실 위험이 있습니다 !!
-- SPFILE 또는 PFILE에 아래 파라미터 추가 후 재시작
-- _allow_resetlogs_corruption=TRUE

-- SQL*Plus에서 임시 적용 (Startup nomount 상태에서)
STARTUP MOUNT;

-- 복구 시도
RECOVER DATABASE UNTIL CANCEL;

-- CANCEL 입력 후 강제 오픈
ALTER DATABASE OPEN RESETLOGS;

-- 작업 완료 후 파라미터 반드시 제거
-- _allow_resetlogs_corruption 파라미터를 FALSE로 되돌리거나 삭제

원인 3: 블록 손상(Block Corruption) 시 해결 방법

-- 손상된 블록 확인
SELECT FILE#, BLOCK#, BLOCKS, CORRUPTION_CHANGE#, CORRUPTION_TYPE
FROM V$DATABASE_BLOCK_CORRUPTION;

-- RMAN을 이용한 블록 미디어 복구 (Block Media Recovery)
RMAN> BLOCKRECOVER DATAFILE 5 BLOCK 233;

-- 또는 손상된 블록 범위 복구
RMAN> BLOCKRECOVER DATAFILE 5 BLOCK 100 TO 200;

-- 손상 여부 검증
RMAN> VALIDATE DATAFILE 5 BLOCK 100 TO 200;

-- 전체 데이터베이스 블록 검증
RMAN> VALIDATE DATABASE;

블록 손상이 심각하여 RMAN 복구도 불가능한 경우, DBMS_REPAIR 패키지를 활용하여 손상된 블록을 표시하고 우회할 수 있습니다.

-- DBMS_REPAIR를 이용한 손상 블록 처리
-- 1단계: 복구 테이블 생성
BEGIN
    DBMS_REPAIR.ADMIN_TABLES(
        TABLE_NAME => 'REPAIR_TABLE',
        TABLE_TYPE => DBMS_REPAIR.REPAIR_TABLE,
        ACTION => DBMS_REPAIR.CREATE_ACTION,
        TABLESPACE => 'SYSTEM'
    );
END;
/

-- 2단계: 손상 블록 검사
DECLARE
    num_corrupt INT;
BEGIN
    DBMS_REPAIR.CHECK_OBJECT(
        SCHEMA_NAME => 'SCOTT',
        OBJECT_NAME => 'EMP',
        REPAIR_TABLE_NAME => 'REPAIR_TABLE',
        corrupt_count => num_corrupt
    );
    DBMS_OUTPUT.PUT_LINE('손상된 블록 수: ' || TO_CHAR(num_corrupt));
END;
/

-- 3단계: 손상 블록 마킹 (Skip Corrupt Blocks)
BEGIN
    DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(
        SCHEMA_NAME => 'SCOTT',
        OBJECT_NAME => 'EMP'
    );
END;
/

예방 방법

정기적인 백업 및 아카이브 로그 보관 정책 수립

RMAN을 활용하여 전체 백업(Full Backup)과 아카이브 로그 백업을 정기적으로 수행하고, 백업 후 반드시 VALIDATE 명령으로 백업 무결성을 검증하는 루틴을 자동화하십시오. 아카이브 로그는 최소 2개 이상의 물리적으로 분리된 위치에 보관하여 단일 장애점(SPOF)을 제거하고, 보관 주기를 복구 목표(RTO/RPO)에 맞게 설정하는 것이 중요합니다.

“`sql

— RMAN 백업 스크립트 예시 (매일 자동 실행 권장)

RMAN> RUN {

BACKUP AS COMPRESSED BACKUPSET DATABASE

FORMAT ‘/backup/rman/db_%d_%T_%s_%p.bkp’

TAG ‘DAILY_FULL_BACKUP’;

BACKUP ARCHIVELOG ALL

FORMAT ‘/backup/rman/arch_%d_%T_%s_%p.bkp’

DELETE INPUT;

VALIDATE BACKUPSET ALL;

}

“`

데이터베이스 정기 헬스 체크 및 블록 무결성 검증 자동화

Oracle Data Guard를 구성하여 물리적 스탠바이(Physical Standby) 데이터베이스를 운영하면 주 데이터베이스의 블록 손상 및 리두 로그 문제를 사전에 탐지하고 자동으로 복구할 수 있습니다. 또한 RMAN의 VALIDATE DATABASE 명령을 주기적으로 실행하여 블록 손상을 조기에 발견하고, AWR/ASH 리포트와 Alert 로그를 모니터링하여 I/O 오류 징후를 선제적으로 파악하십시오.

“`sql

— 정기 블록 검증 스크립트

RMAN> VALIDATE DATABASE CHECK LOGICAL;

— Alert 로그에서 ORA- 에러 모니터링 쿼리

SELECT ORIGINATING_TIMESTAMP, MESSAGE_TEXT

FROM V$DIAG_ALERT_EXT

WHERE MESSAGE_TEXT LIKE ‘%ORA-%’

AND ORIGINATING_TIMESTAMP > SYSDATE – 1

ORDER BY ORIGINATING_TIMESTAMP DESC;

“`