🚨 [장애 보고/회고] Oracle TRUNCATE 사고 복구 시도 및 REDO/UNDO 개념 정리

1. 🛑 배경 및 증상 (Context & Symptom)

• 상황: 다른 PC에서 같은 계정으로 작업 중이던 동료가 운영/개발 테이블의 데이터를 실수로 삭제함.
• 초기 증상: 데이터를 되돌리기 위해 Flashback Query(AS OF TIMESTAMP)를 시도했으나, ORA-01466: 테이블 정의가 변경되었습니다 에러 발생.
• 가설: 단순 DELETE 후 COMMIT만 한 것이 아니라, ALTER나 TRUNCATE 등의 DDL 작업이 개입되어 오라클 딕셔너리 구조가 변경되었을 것으로 추정.

---

2. 🔍 트러블슈팅 과정 (Troubleshooting)

Step 1: 관리자 권한 확인 및 아카이브 로그 모드 체크

• USER_ROLE_PRIVS 조회 결과 DBA 권한 확인.
• v$database 조회 결과 DB가 ARCHIVELOG 모드로 동작 중임을 확인하여 LogMiner를 통한 복구 시도 결정.

Step 2: LogMiner를 이용한 과거 로그 추적

• RAC 환경(thread_1, thread_2)을 고려하여, 사고 발생 추정 시간대(10:00 ~ 10:40)의 아카이브 로그 파일을 순차적으로 조회.
• DBMS_LOGMNR.ADD_LOGFILE을 사용하여 첫 파일은 NEW, 이후 파일은 ADDFILE 옵션으로 병합 등록.
• DBMS_LOGMNR.START_LOGMNR (온라인 딕셔너리 기준) 실행 후, V$LOGMNR_CONTENTS 뷰에서 OPERATION = 'DELETE' 조건으로 복구 쿼리(SQL_UNDO) 추출 시도.

Step 3: 원인 발견 및 복구 실패 사유 확인

• DELETE 작업 내역이 조회되지 않아, 조건을 풀고 전체 OPERATION을 확인한 결과 TRUNCATE TABLE 명령어 실행 흔적 발견.
• LogMiner 분석 세션 정상 종료 (DBMS_LOGMNR.END_LOGMNR();).

---

3. 🧠 핵심 개념 정리: REDO vs UNDO, DELETE vs TRUNCATE

💡 이번 장애를 통해 명확히 이해한 데이터베이스 아키텍처의 차이점

구분 SQL_REDO (Roll-forward) SQL_UNDO (Roll-back) LogMiner 복구 가능 여부

DELETE (DML)	DELETE FROM 테이블... (지운 행위 자체)	INSERT INTO 테이블... (지운 데이터를 다시 넣기)	🟢 가능 (UNDO 쿼리가 생성됨)
TRUNCATE (DDL)	TRUNCATE TABLE... (공간을 날렸다는 기록)	없음 (생성 불가)	🔴 불가능 (로우 단위 기록이 남지 않음)

• REDO 로그: 장애 시 '똑같이 다시 실행(Re-do)'하기 위해 모든 변경 사항을 기록하는 일기장.
• UNDO 데이터: 작업을 '없었던 일로 되돌리기(Un-do)' 위해 이전 상태의 값을 저장하는 임시 공간.
• TRUNCATE의 치명성: 데이터를 한 줄씩 지우는 것이 아니라, 데이터가 들어있는 논리적 공간(Block) 자체를 초기화하는 DDL 명령어이므로 오라클은 UNDO 데이터를 생성하지 않음.

---

4. 🛠️ 해결 및 후속 조치 (Resolution)

• 현재 상태: LogMiner 및 Flashback을 통한 논리적/시간적 복구는 불가능함을 확정.
• Next Step: 사내 백업 정책에 따라 다음 중 하나의 방법으로 물리적 복원 진행 예정.
  1. 전일 자 논리적 백업본(Data Pump, .dmp) 확인 및 impdp 수행
  2. RMAN 백업본을 이용해 임시 인스턴스 기동 후 해당 테이블 데이터 추출

---

5. 📝 회고 (Retrospective)

• 데이터 인프라의 중요성: AI나 화려한 모델링 이전에, 기반이 되는 데이터 자체의 무결성과 보존 환경(백업, 아카이브)을 탄탄하게 갖추는 것이 데이터를 다루는 엔지니어링의 최우선 과제임을 깊이 체감했다.
• 소통과 피드백의 가치: 치명적인 장애가 발생했을 때 범인을 색출하거나 책임을 묻는 데 에너지를 쏟기보다는, 서로 간에 투명하게 상황을 소통하는 것이 먼저다. 듣기 좋은 말이 아니더라도 피드백을 적극적으로 수용하고 공유해야 갈등 없이 문제를 가장 빠르게 풀 수 있으며, 이를 팀 차원의 권한 분리나 프로세스 개선을 위한 계기로 삼아야 한다.

---