로그마이너란 무엇이며 DELETE 오실행 데이터를 복구하는 방법

로그마이너란 무엇이며 DELETE 오실행 데이터를 복구하는 방법

로그마이너는 Oracle Database의 Redo Log와 Archive Log를 SQL 형태로 분석하는 기능입니다.
실무 기준으로 보면 단순 조회 도구가 아니라, 누가 언제 어떤 DML을 수행했는지 추적하고 잘못 실행된 DELETE, UPDATE, INSERT를 되돌릴 근거를 찾는 복구 보조 도구에 가깝습니다.
특히 DELETE 오실행처럼 데이터는 사라졌지만 Redo Log가 남아 있는 상황에서는 SQL_UNDO를 활용해 복구 SQL을 만들 수 있습니다.

로그마이너란?

로그마이너(LogMiner)는 Oracle Database에서 발생한 변경 이력을 Redo Log 또는 Archive Log에서 읽어 사람이 이해할 수 있는 SQL 형태로 보여주는 기능입니다. 일반적으로 데이터베이스는 INSERT, UPDATE, DELETE 같은 변경 작업을 수행할 때 장애 복구를 위해 Redo Log에 변경 내용을 기록합니다. 로그마이너는 이 기록을 분석해 어떤 SQL이 실행되었는지, 어떤 트랜잭션이 커밋되었는지, 해당 변경을 되돌리려면 어떤 SQL을 실행해야 하는지 확인할 수 있게 해줍니다.

로그마이너를 사용하면 V$LOGMNR_CONTENTS 뷰를 통해 SQL_REDO와 SQL_UNDO를 확인할 수 있습니다. SQL_REDO는 실제 수행된 변경 SQL에 가깝고, SQL_UNDO는 해당 변경을 되돌리기 위한 SQL입니다. DELETE 오실행 복구에서는 보통 삭제된 행을 다시 INSERT하는 형태의 SQL_UNDO가 핵심이 됩니다.

로그마이너가 필요한 상황

상황	로그마이너 활용 방식
DELETE 조건을 잘못 입력한 경우	삭제 시점의 트랜잭션을 찾고 SQL_UNDO로 INSERT 복구 SQL을 생성합니다.
UPDATE로 값을 잘못 변경한 경우	변경 전 값을 기준으로 되돌리는 UPDATE SQL을 확인합니다.
누가 데이터를 변경했는지 확인해야 하는 경우	사용자명, 세션 정보, SCN, 시간대를 기준으로 변경 이력을 추적합니다.
장애 원인 분석이 필요한 경우	특정 시간대의 DML 흐름을 확인해 문제 발생 지점을 좁힙니다.

DELETE 오실행 복구 전 확인할 조건

로그마이너를 이용한 데이터 복구는 Redo Log 또는 Archive Log가 남아 있어야 가능합니다. 삭제가 발생한 시점의 로그가 이미 삭제되었거나, 필요한 보조 로깅 정보가 부족하면 SQL_UNDO가 완전하지 않을 수 있습니다. 따라서 운영 환경에서는 복구 가능성을 높이기 위해 Archive Log Mode와 Supplemental Logging 설정을 미리 점검하는 것이 중요합니다.

로그마이너는 백업을 대체하는 기능이 아닙니다.
대량 DELETE, 테이블 구조 변경, LOB 컬럼, 파티션 작업, DDL 혼재 상황에서는 SQL_UNDO만으로 완벽한 복구가 어려울 수 있습니다.
실제 운영 복구 전에는 반드시 테스트 DB 또는 별도 세션에서 복구 SQL을 검증해야 합니다.

기본 점검 SQL

-- Archive Log Mode 확인
ARCHIVE LOG LIST;

-- Supplemental Logging 확인
SELECT supplemental_log_data_min
     , supplemental_log_data_pk
     , supplemental_log_data_ui
FROM v$database;

최소 보조 로깅이 꺼져 있다면 일부 복구 SQL에서 식별 컬럼 정보가 부족할 수 있습니다. 운영 DB에서는 설정 변경 전 영향도를 검토해야 하며, 이미 발생한 과거 로그에는 설정 변경 효과가 소급 적용되지 않습니다.

로그마이너를 이용한 DELETE 복구 흐름

DELETE 오실행이 발생했을 때는 먼저 삭제가 발생한 시간대 또는 SCN 범위를 좁히는 것이 중요합니다. 범위를 넓게 잡으면 분석 대상 로그가 많아져 조회 시간이 길어지고, 동일 테이블의 정상 DELETE까지 함께 조회될 수 있습니다.

1. 삭제 발생 시간 확인
2. 해당 시간대의 Archive Log 또는 Redo Log 확인
3. LogMiner 세션 시작
4. V$LOGMNR_CONTENTS에서 DELETE 이력 조회
5. SQL_UNDO 추출
6. 복구 SQL 검증 후 실행
7. 복구 결과 확인 및 재발 방지 조치

1단계: 분석할 로그 파일 추가

삭제가 발생한 시간대의 Archive Log 파일을 확인한 뒤 로그마이너 분석 대상에 추가합니다. 파일 경로는 환경마다 다르므로 실제 DB의 Archive Log 경로를 기준으로 입력해야 합니다.

BEGIN
  DBMS_LOGMNR.ADD_LOGFILE(
    LOGFILENAME => '/u01/app/oracle/arch/1_12345_987654321.dbf',
    OPTIONS     => DBMS_LOGMNR.NEW
  );

  DBMS_LOGMNR.ADD_LOGFILE(
    LOGFILENAME => '/u01/app/oracle/arch/1_12346_987654321.dbf',
    OPTIONS     => DBMS_LOGMNR.ADDFILE
  );
END;
/

RAC 환경에서는 인스턴스별 Thread 로그를 함께 고려해야 합니다. 특정 Thread의 로그만 분석하면 일부 트랜잭션이 누락될 수 있습니다.

2단계: 로그마이너 세션 시작

일반적으로 현재 데이터 딕셔너리를 기준으로 분석하려면 DICT_FROM_ONLINE_CATALOG 옵션을 사용합니다. 커밋된 트랜잭션만 보고 싶다면 COMMITTED_DATA_ONLY 옵션을 함께 사용할 수 있습니다.

BEGIN
  DBMS_LOGMNR.START_LOGMNR(
    OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG
            + DBMS_LOGMNR.COMMITTED_DATA_ONLY
  );
END;
/

데이터 삭제 시점과 현재 테이블 구조가 크게 다르다면 온라인 카탈로그 기준 분석이 부정확할 수 있습니다. 이 경우 별도의 딕셔너리 파일 방식이나 백업 DB를 활용한 분석이 필요할 수 있습니다.

3단계: DELETE 이력 조회

V$LOGMNR_CONTENTS에서 대상 스키마, 테이블명, 작업 유형, 시간대를 기준으로 DELETE 이력을 조회합니다. 아래 예시는 APPUSER.CUSTOMER 테이블에서 발생한 DELETE를 찾는 형태입니다.

SELECT scn
     , timestamp
     , username
     , operation
     , seg_owner
     , table_name
     , sql_redo
     , sql_undo
FROM v$logmnr_contents
WHERE seg_owner = 'APPUSER'
  AND table_name = 'CUSTOMER'
  AND operation = 'DELETE'
ORDER BY timestamp, scn;

조회 결과에서 SQL_UNDO 컬럼을 보면 DELETE를 되돌리는 INSERT 문을 확인할 수 있습니다. 다만 동일 테이블에서 정상 DELETE와 오실행 DELETE가 섞여 있을 수 있으므로 시간, 사용자, 조건, 삭제 건수 등을 함께 확인해야 합니다.

4단계: SQL_UNDO 추출

DELETE 오실행으로 삭제된 데이터를 복구하려면 SQL_UNDO를 별도로 추출해 검증합니다. SQL_UNDO가 많을 경우 파일로 스풀링한 뒤 테스트 DB에서 먼저 실행하는 방식이 안전합니다.

SET LONG 100000
SET PAGESIZE 0
SET LINESIZE 300
SET TRIMSPOOL ON
SET FEEDBACK OFF

SPOOL delete_recovery.sql

SELECT sql_undo || ';'
FROM v$logmnr_contents
WHERE seg_owner = 'APPUSER'
  AND table_name = 'CUSTOMER'
  AND operation = 'DELETE'
  AND timestamp BETWEEN TO_DATE('2026-06-22 10:00:00', 'YYYY-MM-DD HH24:MI:SS')
                    AND TO_DATE('2026-06-22 10:10:00', 'YYYY-MM-DD HH24:MI:SS')
ORDER BY scn;

SPOOL OFF

추출된 SQL은 바로 운영 DB에 실행하지 않는 것이 좋습니다. 관리자 입장에서 가장 중요한 것은 복구 자체보다 잘못된 복구로 2차 장애를 만들지 않는 것입니다.

5단계: 복구 SQL 검증 후 실행

복구 SQL을 실행하기 전에는 중복 키, 제약 조건, 트리거, 외래 키 영향도를 확인해야 합니다. DELETE 이후 동일한 PK 값으로 데이터가 다시 생성되었다면 SQL_UNDO 실행 시 무결성 오류가 발생할 수 있습니다.

-- 예시: SQL_UNDO 형태
INSERT INTO "APPUSER"."CUSTOMER"
  ("CUSTOMER_ID", "CUSTOMER_NAME", "PHONE_NO", "CREATED_AT")
VALUES
  ('1001', '홍길동', '010-0000-0000', TO_DATE('2026-06-01 09:00:00', 'YYYY-MM-DD HH24:MI:SS'));

-- 검증 후 실행
COMMIT;

복구 SQL 실행 전에는 반드시 현재 테이블 데이터를 백업해 두는 것이 안전합니다.
예를 들어 CTAS 백업, Data Pump Export, Flashback Query 가능 여부 확인 등을 먼저 수행합니다.
대량 복구라면 트랜잭션 단위를 나누고 실행 로그를 남겨야 합니다.

로그마이너 사용 후 세션 종료

분석이 끝나면 로그마이너 세션을 종료합니다. 세션을 종료하지 않으면 불필요한 리소스가 유지될 수 있으므로 작업 후 정리하는 습관이 필요합니다.

BEGIN
  DBMS_LOGMNR.END_LOGMNR;
END;
/

복구 시 자주 발생하는 문제

문제	원인	대응
SQL_UNDO가 NULL로 보임	딕셔너리 정보 부족, 보조 로깅 부족, 지원되지 않는 작업 유형	로그 범위와 딕셔너리 옵션을 재검토하고 백업 DB 분석을 고려합니다.
테이블명이 UNKNOWN으로 표시됨	데이터 딕셔너리 매핑 실패	DICT_FROM_ONLINE_CATALOG 옵션 또는 딕셔너리 파일 방식을 확인합니다.
복구 SQL 실행 시 PK 오류 발생	삭제 후 동일 키 데이터가 재생성됨	현재 데이터와 SQL_UNDO 대상을 비교한 뒤 필요한 행만 선별합니다.
조회 결과가 너무 많음	시간 또는 SCN 범위가 넓음	사용자, 테이블, 트랜잭션 ID, 시간 범위를 좁혀 조회합니다.

Flashback과 로그마이너의 차이

Oracle에서 실수로 삭제된 데이터를 복구할 때는 Flashback 기능도 자주 검토됩니다. Flashback Query는 특정 시점의 데이터를 조회해 복구할 수 있어 비교적 간단하지만, Undo Retention 범위 안에 있어야 합니다. 반면 로그마이너는 Redo Log와 Archive Log를 분석하므로 삭제 시점의 로그가 남아 있다면 더 넓은 범위의 변경 추적이 가능합니다.

구분	Flashback Query	LogMiner
주요 목적	과거 시점 데이터 조회	Redo Log 기반 변경 이력 분석
복구 방식	과거 데이터를 INSERT SELECT로 복구	SQL_UNDO를 추출해 복구
제약	Undo 보존 기간 영향	Redo/Archive Log 보존 여부 영향
분석 정보	데이터 상태 중심	사용자, 작업, SQL, SCN 중심

운영 환경에서의 권장 절차

실제 사용 시 DELETE 오실행이 발생하면 우선 애플리케이션 또는 배치 작업을 멈추고 추가 변경을 최소화해야 합니다. 이후 삭제 시간, 실행 계정, 대상 테이블, 예상 삭제 건수를 확인한 뒤 로그마이너 분석 범위를 정합니다. 복구 SQL은 테스트 환경에서 검증하고, 운영 반영 전 현재 데이터를 백업한 뒤 실행하는 순서가 안전합니다.

운영 복구 권장 순서
장애 접수 및 변경 중지
삭제 시점과 대상 테이블 확인
Archive Log 보존 여부 확인
LogMiner로 SQL_UNDO 추출
테스트 DB에서 복구 SQL 검증
운영 DB 현재 상태 백업
복구 SQL 실행 및 결과 검증
재발 방지 대책 적용

재발 방지를 위한 관리 포인트

로그마이너는 사고 이후 분석과 복구에 유용하지만, 가장 좋은 대응은 오실행을 사전에 줄이는 것입니다. 운영 DB에서는 DELETE나 UPDATE 실행 전 조건절 검증, 영향 건수 확인, 트랜잭션 수동 커밋, 배포 승인 절차를 함께 운영하는 것이 좋습니다.

-- DELETE 전 영향 건수 확인 예시
SELECT COUNT(*)
FROM appuser.customer
WHERE created_at < TO_DATE('2026-01-01', 'YYYY-MM-DD');

-- 실제 DELETE는 조건 재확인 후 수행
DELETE FROM appuser.customer
WHERE created_at < TO_DATE('2026-01-01', 'YYYY-MM-DD');

-- 영향 건수 확인 후 명시적으로 COMMIT 또는 ROLLBACK
ROLLBACK;

또한 핵심 테이블은 정기 백업, Flashback 활용 가능성, Archive Log 보존 기간, Supplemental Logging 정책을 함께 점검해야 합니다. 로그마이너는 사고 대응 시간을 줄이는 도구이지만, 백업·권한·변경 통제와 함께 운영될 때 복구 성공률이 높아집니다.

정리

로그마이너는 Oracle Redo Log와 Archive Log를 분석해 데이터 변경 이력을 SQL 형태로 확인하는 기능입니다. DELETE 오실행이 발생했을 때는 V$LOGMNR_CONTENTS에서 삭제 이력을 찾고 SQL_UNDO를 추출해 복구 SQL로 활용할 수 있습니다. 다만 로그 보존 여부, 보조 로깅 설정, 테이블 구조 변경, 제약 조건에 따라 복구 가능 범위가 달라질 수 있으므로 운영 반영 전 검증이 필수입니다.

결론적으로 로그마이너는 단순한 로그 조회 기능이 아니라, Oracle 데이터 복구와 변경 이력 추적을 위한 핵심 분석 도구입니다. DELETE 복구를 안정적으로 수행하려면 로그마이너 사용법뿐 아니라 백업 정책, Archive Log 관리, 변경 통제 절차까지 함께 관리해야 합니다.