복구 실무
이론적인 복구 원리를 이해했다면, 실무에서 사용하는 Oracle의 복구 도구와 백업 전략을 다룹니다. 복구 실무는 DBA의 핵심 역량이며, 장애 발생 시 데이터 손실을 최소화하면서 서비스를 빠르게 정상화하는 것이 목표입니다.
복구의 분류
데이터베이스 복구는 장애 유형과 범위에 따라 분류됩니다.
| 복구 유형 | 원인 | 자동/수동 | 도구 |
|---|---|---|---|
| 인스턴스 복구 | 정전, 프로세스 크래시 | 자동 | Oracle 자동 수행 |
| 완전 미디어 복구 | 디스크 손상, 파일 유실 | 수동 | RMAN |
| 불완전 미디어 복구 | 사용자 실수, 논리적 오류 | 수동 | RMAN + RESETLOGS |
| Flashback | 잘못된 DML, DROP 실수 | 수동 | SQL / RMAN |
Oracle 인스턴스 복구
Oracle 인스턴스(서버 프로세스)가 비정상 종료된 후 재시작하면 자동으로 인스턴스 복구가 수행됩니다. DBA가 별도로 명령을 실행할 필요 없이 STARTUP 시 자동으로 진행됩니다.
롤백은 데이터베이스를 연 후 백그라운드로 진행되므로, 사용자는 빠르게 접속할 수 있습니다. 이를 Fast-Start Instance Recovery라고 합니다.
RMAN (Recovery Manager)
RMAN은 Oracle의 표준 백업·복구 도구입니다. OS 명령어(cp, tar)로 파일을 복사하는 것보다 안전하고 효율적입니다.
──── RMAN 접속 ────
$ rman target / -- 로컬 접속
$ rman target sys/pwd@orcl catalog rman/pwd@catdb -- 카탈로그 사용
──── 백업 ────
-- 전체 백업 (데이터파일 + 제어 파일 + 아카이브 로그)
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
-- 증분 백업 (레벨 0 = 전체, 레벨 1 = 변경분)
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
-- 테이블스페이스 백업
RMAN> BACKUP TABLESPACE users_ts;
-- 압축 백업
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;
-- 특정 데이터파일 백업
RMAN> BACKUP DATAFILE '/oradata/users01.dbf';
──── 복구 ────
-- 전체 복구
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
-- 테이블스페이스 복구 (온라인 상태에서)
RMAN> SQL 'ALTER TABLESPACE users_ts OFFLINE IMMEDIATE';
RMAN> RESTORE TABLESPACE users_ts;
RMAN> RECOVER TABLESPACE users_ts;
RMAN> SQL 'ALTER TABLESPACE users_ts ONLINE';
-- 데이터파일 복구
RMAN> SQL 'ALTER DATABASE DATAFILE 5 OFFLINE';
RMAN> RESTORE DATAFILE 5;
RMAN> RECOVER DATAFILE 5;
RMAN> SQL 'ALTER DATABASE DATAFILE 5 ONLINE';RMAN 증분 백업 상세
증분 백업은 전체 백업 대비 시간과 공간을 크게 절약합니다.
-- 변경 블록 추적 활성화 (증분 백업 성능 향상)
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/oradata/bct/change_tracking.f';
효과:
* 증분 백업 시 전체 데이터파일 스캔 불필요
* 변경 추적 파일에서 변경 블록 위치 즉시 파악
* 대용량 DB에서 증분 백업 시간 90%+ 단축
상태 확인:
SELECT filename, status, bytes
FROM V$BLOCK_CHANGE_TRACKING;백업 전략
| 전략 | 설명 | 복구 시간 | 저장 공간 |
|---|---|---|---|
| 전체 백업 (Full) | 모든 데이터를 백업 | 빠름 | 많음 |
| 증분 백업 (Incremental) | 변경된 블록만 백업 | 보통 | 적음 |
| 차등 백업 (Differential) | 마지막 전체 백업 이후 변경분 | 보통 | 중간 |
| 누적 증분 (Cumulative) | 마지막 Level 0 이후 누적 변경 | 빠름 | 점점 증가 |
아카이브 로그 모드
미디어 복구(PITR 포함)를 위해서는 아카이브 로그 모드가 필수입니다.
┌──────────────────┬───────────────────┬───────────────────┐
│ │ NOARCHIVELOG │ ARCHIVELOG │
├──────────────────┼───────────────────┼───────────────────┤
│ Redo 로그 재사용 │ 덮어쓰기 │ 아카이브 후 재사용│
│ 미디어 복구 │ 불가능 │ 가능 │
│ PITR │ 불가능 │ 가능 │
│ 핫 백업 │ 불가능 │ 가능 │
│ 디스크 사용 │ 적음 │ 아카이브 로그 공간│
│ 운영 환경 │ 사용 금지 │ 반드시 사용 │
│ 개발 환경 │ 사용 가능 │ 선택 │
└──────────────────┴───────────────────┴───────────────────┘
-- 아카이브 로그 모드 전환
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
-- 아카이브 로그 확인
ARCHIVE LOG LIST;
-- 아카이브 로그 위치 설정
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 =
'LOCATION=/archivelog/' SCOPE=BOTH;물리적 백업 vs 논리적 백업
| 구분 | 물리적 백업 | 논리적 백업 |
|---|---|---|
| 대상 | 데이터 파일 자체 (바이너리) | 데이터 내용 (SQL/덤프) |
| 도구 | RMAN, OS 명령어 | Data Pump (expdp/impdp) |
| 속도 | 빠름 | 느림 |
| 이식성 | 같은 DBMS/플랫폼 | 다른 DBMS 가능 |
| PITR | 가능 | 불가 |
| 사용 목적 | 재해 복구, 운영 백업 | 마이그레이션, 데이터 이동 |
| 일관성 | 블록 수준 | 논리적 수준 |
──── 디렉토리 오브젝트 생성 ────
CREATE DIRECTORY dump_dir AS '/backup/dumps';
GRANT READ, WRITE ON DIRECTORY dump_dir TO hr;
──── 스키마 단위 백업 (Export) ────
$ expdp hr/password \
schemas=HR \
directory=DUMP_DIR \
dumpfile=hr_%U.dmp \
filesize=2G \
parallel=4 \
logfile=hr_exp.log
──── 테이블 단위 백업 ────
$ expdp hr/password \
tables=EMPLOYEES,DEPARTMENTS \
directory=DUMP_DIR \
dumpfile=tables.dmp
──── 복원 (Import) ────
$ impdp system/password \
schemas=HR \
directory=DUMP_DIR \
dumpfile=hr_%U.dmp \
parallel=4 \
remap_schema=HR:HR_NEW \
logfile=hr_imp.log
──── 주요 옵션 ────
CONTENT=DATA_ONLY -- 데이터만 (DDL 제외)
CONTENT=METADATA_ONLY -- DDL만 (데이터 제외)
EXCLUDE=TABLE:"='TEMP_LOG'" -- 특정 테이블 제외
QUERY=EMPLOYEES:"WHERE hire_date > DATE '2023-01-01'"
-- 조건부 백업MySQL/PostgreSQL 백업 도구
Oracle 외 DBMS의 백업 도구도 이해해야 합니다.
──── mysqldump (논리적 백업) ────
$ mysqldump -u root -p \
--single-transaction \
--routines --triggers --events \
mydb > mydb_backup.sql
$ mysqldump --all-databases > full_backup.sql
복원:
$ mysql -u root -p mydb < mydb_backup.sql
──── mysqlpump (병렬 논리적 백업) ────
$ mysqlpump -u root -p \
--default-parallelism=4 \
mydb > mydb_pump.sql
──── Percona XtraBackup (물리적 백업, 핫 백업) ────
$ xtrabackup --backup --target-dir=/backup/full
$ xtrabackup --prepare --target-dir=/backup/full
$ xtrabackup --copy-back --target-dir=/backup/full
특징
* InnoDB 핫 백업 (서비스 중단 없음)
* 증분 백업 지원
* 압축/암호화 지원PITR (Point-in-Time Recovery)
특정 시점까지 데이터베이스를 복원하는 기법입니다. 사용자가 실수로 대량 데이터를 삭제했을 때 핵심적인 복구 방법입니다.
Oracle Flashback
Flashback은 Oracle 고유의 기능으로, 과거 시점의 데이터를 쉽게 조회하거나 복원할 수 있습니다. RMAN 복구보다 빠르고 간단하며, 논리적 오류 복구에 적합합니다.
| Flashback 유형 | 용도 | 의존 기술 |
|---|---|---|
| Flashback Query | 특정 시점의 데이터 조회 | Undo 세그먼트 |
| Flashback Version Query | 데이터 변경 이력 추적 | Undo 세그먼트 |
| Flashback Transaction Query | 트랜잭션 단위 변경 조회 | Undo + Supplemental Log |
| Flashback Table | 테이블을 과거 시점으로 되돌림 | Undo 세그먼트 |
| Flashback Drop | DROP된 테이블 복원 (휴지통) | Recyclebin |
| Flashback Database | 전체 DB를 과거 시점으로 복원 | Flashback Log |
-- 1시간 전 데이터 조회
SELECT * FROM users
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' HOUR)
WHERE id = 101;
-- SCN 기반 과거 데이터 조회
SELECT * FROM orders
AS OF SCN 12345678
WHERE order_id = 999;
-- 현재 vs 과거 비교 (실수 확인)
SELECT curr.*, past.salary AS old_salary
FROM employees curr,
employees AS OF TIMESTAMP
(SYSTIMESTAMP - INTERVAL '2' HOUR) past
WHERE curr.employee_id = past.employee_id
AND curr.salary <> past.salary;-- 특정 행의 모든 변경 이력 조회
SELECT versions_starttime, versions_endtime,
versions_operation, -- I(Insert), U(Update), D(Delete)
employee_id, salary
FROM employees
VERSIONS BETWEEN TIMESTAMP
SYSTIMESTAMP - INTERVAL '1' DAY AND SYSTIMESTAMP
WHERE employee_id = 101;
-- versions_operation으로 언제 누가 변경했는지 추적 가능-- 실수로 삭제한 테이블 복원 (휴지통에서)
FLASHBACK TABLE users TO BEFORE DROP;
FLASHBACK TABLE users TO BEFORE DROP RENAME TO users_restored;
-- 테이블을 특정 시점으로 되돌림
ALTER TABLE orders ENABLE ROW MOVEMENT; -- 사전 설정 필수
FLASHBACK TABLE orders TO TIMESTAMP
TO_TIMESTAMP('2024-01-15 14:30:00', 'YYYY-MM-DD HH24:MI:SS');복구 시나리오별 대응 절차
실무에서 발생할 수 있는 다양한 장애 시나리오와 대응 방법입니다.
상황: /oradata/users01.dbf 파일 손실 (디스크 장애)
즉시 대응:
1. 해당 테이블스페이스 오프라인
SQL> ALTER TABLESPACE users_ts OFFLINE IMMEDIATE;
2. RMAN으로 데이터파일 복원
RMAN> RESTORE DATAFILE '/oradata/users01.dbf';
3. 아카이브 로그 적용 (완전 복구)
RMAN> RECOVER DATAFILE '/oradata/users01.dbf';
4. 테이블스페이스 온라인
SQL> ALTER TABLESPACE users_ts ONLINE;
※ DB를 종료하지 않고 복구 가능 (온라인 복구)상황: 서버 전체 재해 (화재, 장비 폐사)
복구 절차
1. 새 서버에 Oracle 설치 (동일 버전)
2. 원격 백업(테이프, 클라우드)에서 백업셋 복사
3. RMAN으로 제어 파일 복원
RMAN> RESTORE CONTROLFILE FROM '/backup/ctrl.bkp';
4. DB MOUNT
RMAN> ALTER DATABASE MOUNT;
5. 데이터파일 복원
RMAN> RESTORE DATABASE;
6. 아카이브 로그 적용
RMAN> RECOVER DATABASE;
7. DB OPEN
RMAN> ALTER DATABASE OPEN RESETLOGS;
8. 즉시 전체 백업 수행
필수 조건: 백업이 원격지에 존재해야 함!백업 검증과 복구 테스트
백업이 있어도 복구가 안 되면 소용없습니다. 정기적인 검증이 필수입니다.
백업 보존 정책
고가용성(HA) 아키텍처와 복구
대규모 시스템에서는 복구보다 장애 예방과 자동 전환이 더 중요합니다.
복구 실무 종합 정리
| DBMS | 물리적 백업 | 논리적 백업 | PITR | HA 솔루션 |
|---|---|---|---|---|
| Oracle | RMAN | Data Pump | Redo + Archive | Data Guard |
| MySQL | XtraBackup | mysqldump | Binlog | Replication + MHA |
| PostgreSQL | pg_basebackup | pg_dump | WAL Archive | Streaming Rep + Patroni |
| SQL Server | BACKUP DATABASE | BCP / SSIS | T-Log | Always On AG |
다음 장에서는 쿼리의 성능을 분석하고 개선하는 쿼리 최적화를 다루겠습니다.