[ORACLE] ORA-00257 Archive Error & ORA-15041 RECO Disk Full 장애

ODA 환경 ORA-00257 Archive Error & ORA-15041 RECO Disk Full 장애 — 심층 기술 분석

ODA(Oracle Database Appliance) 환경은 Oracle Database + ASM + 전용 스토리지 구성이 하나의 통합 장비로 결합된 구조입니다. 이러한 환경에서 Archivelog의 저장 공간(RECO Diskgroup)이 가득 차면 Oracle은 즉시 Archive Stuck → LGWR 대기 → DB Freeze(정지) 흐름으로 진행되며 장애가 발생합니다.

ORA-00257과 ORA-15041은 단순 경고가 아니라 Redo 로그 자체가 더 이상 기록될 수 없는, DB 레벨의 치명적 정지 상황을 의미합니다.

1. 발생 오류 로그

ORA-00257: archiver error. Connect internal only, until freed
ORA-15041: diskgroup "RECO" space exhausted

ARC2: Error 19504 Creating archive log file to '+RECO'
ARC2: Stuck archiver: insufficient local LADs
ARC2: Stuck archiver condition declared

메시지의 핵심은 아카이버 프로세스가 로그 파일을 생성할 수 없고, RECO 공간은 완전히 소진된 상태라는 점입니다.

2. 오류가 발생하는 기술적 구조

2-1. LGWR와 ARCn의 관계

• LGWR는 Redo Log Buffer → Online Redo Log로 기록
• Redo Log가 가득 차면 ARCn이 이를 Archivelog로 복사
• ARCn이 제대로 기록하지 못하면 LGWR가 다음 로그를 할당할 수 없음
• 결과적으로 COMMIT 이후에도 로그를 기록할 수 없어 DB 전체가 멈춤

2-2. ODA의 FRA(+RECO) 구조적 특징

• ODA는 효율·안정성 중심 구성으로 RECO 크기가 제한적인 경우가 많음
• Redo/Archivelog가 폭증하면 RECO Diskgroup이 빠르게 포화
• ODA 환경은 RECO 포화 시 반응성이 떨어지기 때문에 장애 폭이 더 크게 나타남

2-3. Archive Stuck 메커니즘 확장 설명

• RECO가 Full → 아카이버가 기록 실패
• ARCn: “Stuck” 상태 진입
• LGWR는 새로운 Redo 로그를 할당할 수 없어 기다림
• 대기 이벤트 발생: ARCH wait, log file switch (archiving needed)
• 트랜잭션이 커밋되지 못하고 성능이 급락

3. 장애 원인 — 확장 설명

3-1. Archivelog 증가 원인 다양성

Archivelog 증가를 유발하는 상황은 단순 대량 작업뿐만 아니라 아래와 같은 경우도 포함됩니다:

• 애플리케이션 배포 후 SQL 패턴 변화
• 인덱스 재구성 또는 Online DDL
• Batch Job 오작동으로 동일 트랜잭션 반복 실행
• 대량 MERGE 또는 UPDATE 기반 배치
• 애플리케이션 오류로 인한 커밋 폭주

3-2. RMAN 보관 정책 미조정

• 기본 보관 주기가 길 경우, RECO에 Archivelog가 장기간 쌓임
• Archivelog 백업 이후에도 자동 삭제가 설정되어 있지 않음

3-3. ASM RECO 공간 부족 구조

• FRA와 Archivelog가 동일 RECO Diskgroup에서 관리
• Controlfile, Flashback log 등도 FRA 공간을 사용
• ODA 환경에서는 FRA 확장이 쉽지 않아 포화 위험이 높음

4. 장애 영향 — 확장 설명

• 모든 신규 트랜잭션이 Commit 불가능
• 세션이 장시간 hang 상태로 진입
• DB Writer(DBWR), LGWR 등 핵심 백그라운드 프로세스 대기
• RAC 환경에서는 인스턴스 간 Global Cache Latency 증가
• 서비스는 정상적으로 살아 있는 것처럼 보이지만 내부적으로 모든 작업이 멈추어 사실상 중단 상태

5. 즉각적인 조치(반드시 선행해야 하는 순서)

5-1. RECO 여유 공간 확보

• 백업 완료된 Archivelog 우선 삭제
• 필요 시 오래된 Flashback log 삭제 고려

RMAN> delete archivelog all completed before 'sysdate-4';

5-2. 백업 정책 조정

• 보관 기간 단축
• 백업 직후 즉시 Archivelog 삭제 정책 활성화
• FRA Cleaning Job이 정상 작동하는지 점검

5-3. RECO 용량 증설 또는 분리

• 가능하다면 FRA를 별도 디스크로 분리 운영
• ODA의 DISKGROUP 구성 변경을 통한 확장 고려

6. 재발 방지 전략 — 확장형

6-1. Archivelog 모니터링 체계 구축

• 일간/주간 Archivelog 증가 추세 그래프화
• 증가율 기반 Warning/Alert 자동화

6-2. RMAN 정책 최적화

• “Backup + Delete input” 방식으로 운영
• 불필요 백업 세트/카탈로그 정리

6-3. 대량 작업 사전 승인 절차

• 대량 DML, 인덱스 재생성, 병렬 작업 전 RECO 여유 공간 확보

6-4. FRA 설계 재검토

• 기존 FRA 대비 Archivelog 증가량을 고려한 150% 이상 설계
• Flashback 기능 비사용 시 Flashback log 비활성화로 공간절감