RAC 05: RMAN 백업 & Recovery — Catalog 서버 구축 · 인스턴스 장애 복구

DB 스터디/04_RAC 2026. 7. 2. 11:25

실습 스크립트 전체 보기: https://github.com/nsylove97/NSY-DB-Portfolio

실습 환경

OS	Oracle Linux 7.9 (VMware Virtual Machine)
DB	Oracle Database 19c
Grid	Oracle Grid Infrastructure 19c
구성	2 Node RAC (VM1 · VM2)
공유 스토리지	ASM (+DATA / +FRA / +REDO / +OCR)
네트워크	Public (NAT) · Private (Host-only) · VIP · SCAN
Catalog DB	rcatdb (단일 인스턴스, 2daydba VM)
VM1/VM2 초기 구성 참조	ASM 실습 01
RAC 구축 참조	RAC 02

목차
1. RMAN Catalog 서버 구축 — tnsnames · 테이블스페이스 · 사용자 생성
2. RMAN Catalog 연결 및 RAC 대상 DB 등록
3. RAC에서 RMAN 백업 실행 — 노드 간 인식 구조
4. Snapshot Controlfile 위치 확인 및 공유 스토리지 변경
5. RMAN 백업 채널 — +FRA 경로 지정
6. 인스턴스 장애 시뮬레이션 — 강제 종료 및 자동 인계 확인
7. RAC Instance Recovery 흐름 — GES → GCS → LMS → SMON
8. FAST_START_MTTR_TARGET — 단일 인스턴스 vs RAC
9. RECOVERY_PARALLELISM — 병렬 복구 프로세스 수
10. Asynchronous I/O · Buffer Cache와 복구 속도
11. 주요 명령어 정리

1. RMAN Catalog 서버 구축 — tnsnames · 테이블스페이스 · 사용자 생성

RAC는 인스턴스가 여러 개이므로 백업 이력을 각 노드의 컨트롤파일에만 의존하면 관리가 번거로움

별도 서버에 Recovery Catalog를 구축하여 모든 백업 메타데이터를 중앙에서 관리

-- [2daydba — SQL*Plus]
SQL> CREATE TABLESPACE rcat_ts
     DATAFILE '/u01/app/oracle/oradata/rcatdb/rcat_ts01.dbf' SIZE 500M
     AUTOEXTEND ON;
     
-- Tablespace created.

SQL> CREATE USER rman_catalog IDENTIFIED BY rman_catalog
     DEFAULT TABLESPACE rcat_ts
     QUOTA UNLIMITED ON rcat_ts;

-- User created.

SQL> GRANT recovery_catalog_owner TO rman_catalog;

-- Grant succeeded.

recovery catalog용 테이블스페이스 및 유저 생성, 권한 부여

-- [oelsvr1 · 2daydba — root, 양쪽 모두 동일하게 등록]
$ vi /etc/hosts

192.168.111.20  2daydba
192.168.111.50  oelsvr1

-- [2daydba, oelsvr1 — oracle]
$ vi $ORACLE_HOME/network/admin/tnsnames.ora

RCATDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 2daydba)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = orcl)))

2daydba와 VM1의 tnsnames.ora 파일에 rcatdb 등록

-- [oelsvr1 — oracle]
$ tnsping RCATDB

OK (10 msec)

Recovery Catalog는 RAC 대상 DB와 분리된 별도의 단일 인스턴스 DB에 두는 것이 일반적 — Target DB 손상 시 백업 메타데이터까지 함께 소실되는 것 방지
Catalog 전용 테이블스페이스와 계정을 분리해 두면 여러 Target DB를 하나의 Catalog로 통합 관리 가능

2. RMAN Catalog 연결 및 RAC 대상 DB 등록

-- [oelsvr1 — oracle, RAC Target DB]
$ rman target / catalog rman_catalog/rman_catalog@RCATDB

connected to target database: ORCL (DBID=1761551299)
connected to recovery catalog database

-- 카탈로그 스키마 생성
RMAN> CREATE CATALOG TABLESPACE rcat_ts;

recovery catalog created

-- catalog에 DB 등록
RMAN> REGISTER DATABASE;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

-- 확인
RMAN> LIST INCARNATION;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- ------- ---------- ----------
1       18      ORCL     1761551299       PARENT  1          17-APR-19
1       2       ORCL     1761551299       CURRENT 1920977    20-MAY-26

REGISTER DATABASE는 DBID 기준으로 1회만 수행하면 됨, 어느 노드에서 접속해 등록하든 카탈로그에는 동일하게 반영됨
RAC는 양 인스턴스가 같은 컨트롤파일 공유, 카탈로그 등록도 단일 인스턴스와 동일한 절차로 진행됨 — 인스턴스별로 별도 등록할 필요 없음

3. RAC에서 RMAN 백업 실행 — 노드 간 인식 구조

-- [oelsvr1 — RMAN, orcl1에서 백업 수행]
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=29 instance=orcl1 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
...
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

-- [oelsvr2 — RMAN, orcl2에서 확인]
RMAN> LIST BACKUP SUMMARY;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
-------- -- -- - ----------- --------------- ------- ------- ---------- ---
12      B  F  A DISK        ...             1       1       NO         TAG...

한 노드(orcl1)에서 수행한 백업이 다른 노드(orcl2)에서도 즉시 동일하게 조회됨 — 양 인스턴스가 같은 컨트롤 파일과 카탈로그를 공유하기 때문
백업 파일 자체는 +FRA(공유 ASM)에 기록됨, 어느 노드의 채널이 백업을 수행했는지와 무관하게 모든 노드가 해당 백업셋에 접근 가능
멀티 채널로 양 노드에 백업 부하를 분산 가능— CONFIGURE DEVICE TYPE DISK PARALLELISM 2로 채널 수를 늘리고 노드별 채널을 할당하는 방식

4. Snapshot Controlfile 위치 확인 및 공유 스토리지 변경

Snapshot Controlfile: 백업 시점의 컨트롤 파일 정보를 읽기 일관성 있게 고정하는 임시 파일 — RMAN이 백업·복구 명령을 실행하는 동안만 생성·사용됨

-- [oelsvr1 — RMAN]
-- 현재 snapshot controlfile 위치 확인
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;

RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/19.3.0/dbhome/dbs/snapcf_orcl1.f';

-- 공유 스토리지로 변경
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/snapcf_orcl1.f';

new RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/snapcf_orcl1.f';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete

-- 변경 확인
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;

RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/snapcf_orcl1.f';

RAC에서는 어느 노드에서 RMAN을 실행하든 동일한 파일에 접근해야 하므로, 반드시 모든 노드가 공유하는 위치에 두어야 함— 로컬 디스크 경로로 두면 다른 노드에서 실행 시 파일을 찾지 못해 오류 발생

5. RMAN 백업 채널 — +FRA 경로 지정

기존 +FRA를 백업 대상으로 사용 (실습 환경에서 디스크 여분이 없는 경우 무난한 선택)

-- [oelsvr1 — RMAN]
-- 현재 채널 설정 확인
RMAN> SHOW CHANNEL;

RMAN configuration parameters for database with db_unique_name ORCL are:
RMAN configuration has no stored or default parameters

-- 백업 채널 변경
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+FRA/%U';

new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '+FRA/%U';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete

-- [oelsvr1 — SQL*Plus]
-- FRA 용량 상한 확인
SQL> SHOW PARAMETER db_recovery_file_dest_size

NAME                         TYPE        VALUE
---------------------------- ----------- -----
db_recovery_file_dest_size   big integer 10088M

아카이브 로그와 백업이 +FRA를 공유하므로 db_recovery_file_dest_size로 전체 상한을 잡아 공간 확보
용량이 부족해지면 RMAN의 obsolete 정책(CONFIGURE RETENTION POLICY)에 따라 오래된 백업을 정리하여 여유 확보

6. 인스턴스 장애 시뮬레이션 — 강제 종료 및 자동 인계 확인

-- [oelsvr2 — oracle]
-- pmon 프로세스 pid 확인
$ ps -ef | grep pmon_orcl2

oracle   25836     1  0 09:13 ?        00:00:00 ora_pmon_orcl2

-- 강제 종료로 장애 발생
$ kill -9 25836

-- [oelsvr1 — oracle, 양 노드 상태 확인]
$ srvctl status database -d orcl

Instance orcl1 is running on node oelsvr1
Instance orcl2 is not running on node oelsvr2

-- [oelsvr1 — orcl1, 생존 노드에서 세션 정상 처리 확인]
SQL> SELECT inst_id, status FROM gv$instance;

   INST_ID STATUS
---------- ------------
         1 OPEN

-- 잠시 후 — Clusterware 정책(AUTOMATIC)에 따른 자동 재기동 확인
$ srvctl status database -d orcl

Instance orcl1 is running on node oelsvr1
Instance orcl2 is running on node oelsvr2

pmon 강제 종료 시 ORA-00474 에러와 함께 orcl2가 즉시 비정상 종료
orcl2가 비정상 종료되어도 orcl1은 영향 없이 서비스 계속됨 — RAC의 핵심 가치인 가용성이 직접 확인되는 지점
srvctl 정책이 AUTOMATIC이면 Clusterware가 일정 시간 내 인스턴스를 자동으로 재기동— RAC 03편에서 다룬 srvctl config database 정책과 직결됨

7. RAC Instance Recovery 흐름 — GES → GCS → LMS → SMON

-- [oelsvr1 — orcl1 alert log에서 복구 단계 확인]
$ tail -80 $ORACLE_BASE/diag/rdbms/orcl/orcl1/trace/alert_orcl1.log

* dead instance detected - domain 0 invalid = TRUE
 Communication channels reestablished
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
2026-07-02T10:17:09.820770+09:00
 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2026-07-02T10:17:09.822850+09:00
 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
 Set master node info
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
 Post SMON to start 1st pass IR
Reconfiguration complete (total time 0.1 secs)
Decreasing priority of 2 RS
2026-07-02T10:17:10.075460+09:00
Instance recovery: looking for dead threads
2026-07-02T10:17:10.077627+09:00
Beginning instance recovery of 1 threads
 parallel recovery started with 3 processes
 Thread 2: Recovery starting at checkpoint rba (logseq 16 block 10928), scn 0
2026-07-02T10:17:10.128869+09:00
Started redo scan
2026-07-02T10:17:10.165734+09:00
Completed redo scan
 read 326 KB redo, 38 data blocks need recovery
validate pdb 0, flags x10, valid 0, pdb flags x8a4
* validated domain 0, flags = 0x8a0
2026-07-02T10:17:10.224388+09:00
Started redo application at
 Thread 2: logseq 16, block 10928, offset 0
2026-07-02T10:17:10.228394+09:00
Recovery of Online Redo Log: Thread 2 Group 4 Seq 16 Reading mem 0
  Mem# 0: +REDO/ORCL/ONLINELOG/group_4.260.1233770977
  Mem# 1: +FRA/ORCL/ONLINELOG/group_4.260.1233770977
2026-07-02T10:17:10.236805+09:00
Completed redo application of 0.14MB
2026-07-02T10:17:10.245959+09:00
Completed instance recovery at
 Thread 2: RBA 16.11581.16, nab 11581, scn 0x00000000002cc4cf
 32 data blocks read, 38 data blocks written, 326 redo k-bytes read

단계	담당	역할
GES (Reconfiguration)	LMON	죽은 인스턴스 감지, 클러스터 재구성 시작, GRD 동결(freeze)
GCS (Resource Remastering)	LMS	죽은 노드가 마스터링하던 리소스를 생존 노드로 재할당
Lock 정리	LCK0 / LMD	죽은 인스턴스가 보유하던 Enqueue·Lock 해제
Redo 복구	SMON	죽은 인스턴스의 Thread Redo를 읽어 변경사항 재적용

장애 노드의 Thread Redo만 적용하면 됨
RAC 04편에서 다룬 인스턴스별 독립 Thread 구조가 이 복구 범위를 좁히는 핵심 전제가 됨
Reconfiguration started ~ Instance recovery complete까지가 GES/GCS 레벨에서 SMON 레벨로 넘어가는 전체 흐름, 이 과정에서 생존 노드의 서비스는 중단되지 않음

8. FAST_START_MTTR_TARGET — 단일 인스턴스 vs RAC

fast_start_mttr_target: 인스턴스 장애 후 복구 완료까지 걸리는 목표 시간(초)을 오라클에 지정하는 파라미터
이 값을 기준으로 오라클이 체크포인트 빈도를 자동 조절해 Redo 적용량을 목표 시간 안에 처리할 수 있도록 유지

-- [oelsvr1 — SQL*Plus, orcl1]
-- 현재 fast_start_mttr_target 상태 확인

SQL> SHOW PARAMETER fast_start_mttr_target

NAME                       TYPE    VALUE
-------------------------- ------- ------
fast_start_mttr_target     integer 0

기본값 0은 비활성 상태 — 오라클이 체크포인트 빈도를 자체적으로 결정, 복구 목표 시간을 별도로 제어하지 않음

-- 복구 목표 시간 설정 — 양 노드 적용
SQL> ALTER SYSTEM SET fast_start_mttr_target=300 SID='*';

System altered.

-- 설정 후 복구 목표 시간 예측 조회
SQL> SELECT target_mttr, estimated_mttr, ckpt_block_writes
     FROM v$instance_recovery;

TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES
----------- -------------- -----------------
        30               0              1456

-- 예측 조회 — Advisor
SQL> SELECT mttr_target_for_estimate, advice_status,
            estd_total_writes, estd_total_write_factor
     FROM v$mttr_target_advice
     ORDER BY mttr_target_for_estimate;

MTTR_TARGET_FOR_ESTIMATE ADVIC ESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTOR
------------------------ ----- ----------------- -----------------------
                       3 ON                   71                       1
                       9 ON                   71                       1
                      16 ON                   71                       1
                      23 ON                   71                       1
                      30 ON                   71                       1

단일 인스턴스에서는 자기 자신의 Crash Recovery 시간만 결정
RAC에서는 인스턴스마다 개별 설정되어 각 노드가 자신의 Thread를 복구할 때 적용된다.
MTTR 목표를 낮게 잡으면 체크포인트가 자주 발생해 복구는 빨라지지만 평상시 I/O 부하(CKPT_BLOCK_WRITES)가 늘어남 — 트레이드오프를 v$mttr_target_advice로 사전 확인 후 결정

9. RECOVERY_PARALLELISM — 병렬 복구 프로세스 수

-- [oelsvr1 — SQL*Plus, orcl1]
SQL> SHOW PARAMETER recovery_parallelism

NAME                    TYPE    VALUE
----------------------- ------- ------
recovery_parallelism    integer 0

recovery_parallelism 파라미터 확인, 오라클이 자동 결정

-- 변경 — 병렬 복구 슬레이브 프로세스 수 지정
SQL> ALTER SYSTEM SET recovery_parallelism=4 SID='*';

System altered.

기본값 0은 CPU 코어 수 기준으로 오라클이 자동 결정한다는 의미
명시적으로 값을 지정하면 해당 개수의 병렬 복구 슬레이브(Parallel Recovery Slave)가 기동됨
alert log의 SMON: Parallel transaction recovery slaves 메시지가 이 파라미터에 의해 기동된 프로세스 수와 직결됨

10. Asynchronous I/O · Buffer Cache와 복구 속도

-- [oelsvr1 — SQL*Plus, orcl1]
SQL> SHOW PARAMETER disk_asynch_io

NAME              TYPE     VALUE
----------------- -------- -----
disk_asynch_io    boolean  TRUE

-- [Buffer Cache 크기 확인]
SQL> SHOW PARAMETER db_cache_size

NAME             TYPE    VALUE
---------------- ------- -------
db_cache_size    big integer 0

SQL> SELECT component, current_size/1024/1024 MB
     FROM v$sga_dynamic_components
     WHERE component = 'DEFAULT buffer cache';

COMPONENT                MB
------------------------ ----
DEFAULT buffer cache     3664

buffer cache 크기는 자동 설정, 기본 버퍼 캐시 크기는 3664MB

disk_asynch_io=TRUE이면 체크포인트 기록과 Redo 적용 시 I/O 요청을 비동기로 처리 (복구 중 디스크 대기 시간감소 — 기본값을 임의로 FALSE로 바꾸지 않음)
Buffer Cache가 클수록 Dirty Block이 메모리에 더 오래 머무를 수 있어 체크포인트 빈도는 감소. 동시에 한 번 장애가 발생했을 때 적용해야 할 변경분(복구 대상) 증가 — MTTR 목표와 Buffer Cache 크기는 함께 고려해야 하는 트레이드오프 관계

11. 주요 명령어 정리

-- Catalog 연결
rman target / catalog <user>/<password>@<CATALOG_TNS>

-- 카탈로그 스키마 생성 (1회)
CREATE CATALOG TABLESPACE rcat_ts;

-- DB 등록 (1회)
REGISTER DATABASE;

-- 백업 이력 조회
LIST BACKUP SUMMARY;
LIST INCARNATION;

-- Snapshot Controlfile 위치 확인
SHOW SNAPSHOT CONTROLFILE NAME;

-- Snapshot Controlfile 위치 변경
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '<공유경로>';

-- 백업 채널 설정 확인
SHOW CHANNEL;

-- 백업 채널 디스크 그룹 지정
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '<디스크그룹>/%U';

-- 전체 백업
BACKUP DATABASE PLUS ARCHIVELOG;

-- RAC DB 전체 상태 확인
srvctl status database -d <db_unique_name>

-- pmon 프로세스 확인
ps -ef | grep pmon_<SID>

-- 복구 관련 파라미터
SHOW PARAMETER fast_start_mttr_target
SHOW PARAMETER recovery_parallelism

SELECT target_mttr, estimated_mttr, ckpt_block_writes 
FROM v$instance_recovery;

SELECT mttr_target_for_estimate, advice_status, estd_total_writes, estd_total_write_factor 
FROM v$mttr_target_advice;

핵심 요약

주제	핵심 포인트
Recovery Catalog	RAC와 분리된 별도 DB(2daydba)에 구축, 계정 생성 → CREATE CATALOG → REGISTER DATABASE 순서 필수
RAC 백업 인식	한 노드 백업이 공유 컨트롤파일·카탈로그로 전 노드에 즉시 반영
Snapshot Controlfile	SHOW SNAPSHOT CONTROLFILE NAME으로 확인, RAC에서는 반드시 공유 스토리지(+DATA) 경로로 지정
백업 채널 경로	디스크 여분이 없는 경우 +FRA 통합 운용, db_recovery_file_dest_size로 용량 상한 관리
인스턴스 장애 시뮬레이션	pmon 강제 종료로 장애 재현, 생존 노드 서비스 지속 및 Clusterware 자동 재기동 확인
Instance Recovery 흐름	GES(LMON) → GCS(LMS) → Lock 정리 → SMON Redo 적용 순서
FAST_START_MTTR_TARGET	인스턴스 장애 후 복구 목표 시간(초) 지정, 0은 비활성, RAC에서는 인스턴스별 개별 설정
RECOVERY_PARALLELISM	0은 자동 결정, 명시 설정 시 병렬 복구 슬레이브 수 고정
Async I/O / Buffer Cache	비동기 I/O는 복구 지연 감소, db_cache_size=0이면 AMM/ASMM이 크기 자동 조절

'DB 스터디 > 04_RAC' 카테고리의 다른 글

RAC 04: RAC 파라미터 · SPFILE · Redo · UNDO 관리 (0)	2026.06.19
RAC 03: Clusterware 관리 — crsctl · srvctl · OCR · 로그 분석 (0)	2026.06.18
RAC 02: 2 Node RAC 구축 — VM 환경 준비 & Grid 설치 (0)	2026.05.20
RAC 01: 개념 & 아키텍처 — Cluster · GCS/GES · Cache Fusion (0)	2026.05.06

ABOUT ME

nsylove97 님의 블로그 nsylove97 님의 블로그

핵심 요약

'DB 스터디 > 04_RAC' 카테고리의 다른 글

티스토리툴바

ABOUT ME

핵심 요약

'DB 스터디 > 04_RAC' 카테고리의 다른 글

관련글 관련글 더보기

티스토리툴바