증분 백업과 BCT

#핵심 요약

레벨 0은 데이터가 든 블록을 모두 백업하는 증분 전략의 기준임
전체 백업과의 차이는 증분 전략에 포함되느냐뿐임

레벨 1 차등(기본값)은 가장 최근 레벨 1 또는 0 이후 바뀐 블록을, 레벨 1 누적은 가장 최근 레벨 0 이후 바뀐 블록을 백업함

누적은 백업이 크지만 복구 때 적용할 증분이 적어 복구 시간이 중요할 때 나음

BCT를 켜면 변경 추적 파일의 비트맵으로 바뀌지 않은 블록을 읽지 않음
BCT를 켠 뒤 레벨 0을 한 번 받아야 다음 레벨 1부터 쓰임

#개념과 동작 원리

레벨 0은 백업셋이나 이미지 카피 모두 될 수 있지만, 레벨 1은 백업셋만 됨

매체 복구 때 RMAN은 고를 수 있으면 아카이브 로그보다 증분 백업을 먼저 씀
블록 단위 적용이 리두 적용보다 빠르기 때문임

증분 백업은 바뀐 블록을 그대로 담으므로 NOLOGGING으로 바뀐 내용도 복구할 수 있음
NOLOGGING 변경 전 백업을 복원했다면 증분 백업이 그 변경을 되살리는 유일한 방법임

블록이 바뀔 때 CTWR(Change Tracking Writer) 백그라운드 프로세스가 바뀐 블록 위치를 변경 추적 파일에 기록함
BCT가 없으면 레벨 1도 데이터 파일의 모든 블록을 읽어 변경 여부를 확인해야 하지만, BCT가 있으면 추적 파일에 적힌 블록만 읽어 훨씬 빨라짐

BCT가 켜져 있어도 RMAN은 읽은 블록의 SCN을 다시 확인해 포함 여부를 정함

설명:

BCT를 켜면 CTWR 백그라운드 프로세스가 기동해 바뀐 블록 위치를 변경 추적 파일에 기록함

변경 추적 파일은 바이너리 파일이므로 편집하거나 지우면 안 됨
BCT를 끄면 파일은 자동으로 삭제됨

실습 운영 예: 레벨 0은 보통 주말에, 레벨 1은 매일 밤에 받음

#필수 명령어 또는 SQL

#레벨별 백업

BACKUP INCREMENTAL LEVEL 0 DATABASE;
BACKUP INCREMENTAL LEVEL 1 DATABASE;              -- 차등
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;   -- 누적

결과 해석:

실습에서는 레벨 0 뒤 데이터를 넣고 로그 스위치와 체크포인트를 한 다음 레벨 1을 받는 과정을 두 번 반복했음

#증분 백업 확인

SELECT backup_type, incremental_level,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI') start_time
  FROM v$backup_set
 WHERE incremental_level IN (0, 1)
 ORDER BY start_time DESC;

LIST BACKUP SUMMARY;

결과 해석:

설명: LIST BACKUP SUMMARY의 LV 열에서 0과 1을 구분함

#증분 백업으로 복구

ALTER TABLESPACE users OFFLINE IMMEDIATE;

LIST BACKUP OF DATAFILE <FILE_NO> SUMMARY;
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;

ALTER TABLESPACE users ONLINE;

결과 해석:

실습 기록: 데이터 파일을 지운 뒤 온라인으로 올리려 하자 ORA-01157, ORA-01110이 났음
파일이 없을 때는 일반 OFFLINE이 실패할 수 있어 OFFLINE IMMEDIATE를 썼음
설명: RESTORE는 레벨 0을 되살리고, RECOVER는 레벨 1 증분을 먼저 적용한 뒤 나머지를 아카이브 로그로 채움
복구 메시지에 starting incremental datafile backup set restore가 보이면 증분 백업이 쓰인 것임

#BCT 켜기와 확인

mkdir -p <BACKUP_DIR>

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '<BACKUP_DIR>/block_tracking.chg';

SELECT status, filename, bytes/1024/1024 AS mb FROM v$block_change_tracking;

ps -ef | grep ctwr

결과 해석:

실습 기록 형식: STATUS가 ENABLED이고 FILENAME이 지정한 경로임

BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT '<BACKUP_DIR>/%U';
BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT '<BACKUP_DIR>/%U';

결과 해석: 개별 실행 출력은 기재 없음

#BCT 효과 확인

SELECT file#,
       AVG(datafile_blocks),
       AVG(blocks_read),
       AVG(blocks_read / datafile_blocks) * 100 AS pct_read_for_backup,
       AVG(blocks)
  FROM v$backup_datafile
 WHERE used_change_tracking = 'YES'
   AND incremental_level > 0
 GROUP BY file#;

결과 해석:

설명: DATAFILE_BLOCKS는 데이터 파일 전체 블록 수, BLOCKS_READ는 백업 때 실제로 읽은 블록 수, BLOCKS는 백업에 담긴 블록 수임
PCT_READ_FOR_BACKUP이 낮을수록 전체를 훑지 않고 바뀐 블록만 읽었다는 뜻임

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

결과 해석: 개별 실행 출력은 기재 없음

#매일 밤 레벨 1 자동 실행

#!/bin/bash
export ORACLE_SID=<ORACLE_SID>
export ORACLE_HOME=<ORACLE_HOME>
export PATH=$ORACLE_HOME/bin:$PATH

LOG_DIR=/home/oracle/rman_logs
mkdir -p $LOG_DIR
LOG_FILE=$LOG_DIR/rman_inc1_$(date +%Y%m%d_%H%M%S).log

rman target sys/<PASSWORD>@<TARGET_SERVICE> catalog <USERNAME>/<PASSWORD>@<CATALOG_SERVICE> << EOF >> $LOG_FILE 2>&1
backup incremental level 1 database;
EOF

chmod +x rman_incr.sh
crontab -e
# 0 1 * * * /home/oracle/rman_incr.sh

결과 해석:

설명: cron은 로그인 환경 변수를 읽지 않으므로 ORACLE_SID, ORACLE_HOME, PATH를 스크립트 안에서 지정함
crontab 형식은 분 시 일 월 요일 명령이고 요일은 0(일요일)~6(토요일)임
이 스크립트는 SQL*Plus와 SQLcl의 실습 스크립트와 달리 export가 호출 앞에 바르게 있음
비밀번호를 스크립트에 평문으로 두는 문제는 수업 자료에 언급이 없음

#증분 갱신 백업 (이미지 카피를 매일 최신으로)

레벨 0 이미지 카피를 한 번만 만들어 두고, 이후에는 레벨 1 증분을 받아 그 카피에 적용(RECOVER COPY)함
이미지 카피가 매일 "어제 수준"으로 갱신되므로 복원이 단순하고 적용할 리두도 적음
최신 카피로 SWITCH TO COPY하면 복사 시간 없이 바로 복구할 수도 있음

태그는 어느 카피에 증분을 적용할지 알려 주는 이름표라 이후 같은 태그를 계속 씀

REPORT SCHEMA;

BACKUP INCREMENTAL LEVEL 0 AS COPY DATAFILE <FILE_NO>
  FORMAT '<BACKUP_DIR>/incre_0_%U'
  TAG '<TAG>';

LIST COPY OF DATAFILE <FILE_NO>;     -- Ckp SCN을 적어 둠

BACKUP INCREMENTAL LEVEL 1
  FOR RECOVER OF COPY WITH TAG '<TAG>'
  DATAFILE <FILE_NO>;

RECOVER COPY OF DATAFILE <FILE_NO> WITH TAG '<TAG>';
LIST COPY OF DATAFILE <FILE_NO>;

그 태그의 카피가 아직 없으면 첫 번째 명령은 증분 대신 레벨 0 이미지 카피를 먼저 만듦

결과 해석: RECOVER COPY 뒤 LIST COPY의 Ckp SCN이 커지면 카피가 최신으로 갱신된 것임

데이터베이스 전체도 같은 방식으로 관리함
실습 자료는 실무에서 매일 밤 아래 블록 하나를 반복 실행한다고 적었음
적용을 먼저, 백업을 나중에 두면 첫날은 레벨 0 카피가 만들어지고 둘째 날부터는 전날 증분을 적용한 뒤 새 증분을 받음

RUN {
  RECOVER COPY OF DATABASE WITH TAG '<TAG>';
  BACKUP INCREMENTAL LEVEL 1
    FOR RECOVER OF COPY WITH TAG '<TAG>'
    DATABASE;
}

결과 해석:

카피로 복구할 때는 일반 복구와 같이 RESTORE DATAFILE, RECOVER DATAFILE을 씀
SYSTEM과 UNDO 파일은 오프라인으로 내릴 수 없으므로 MOUNT 상태에서 복구함

SPFILE과 모든 데이터 파일을 함께 잃은 경우 실습에서는 다음 순서로 복구했음

STARTUP NOMOUNT;
SET DBID <DBID>;
RESTORE SPFILE FROM AUTOBACKUP
  DB_RECOVERY_FILE_DEST = '<FRA_DIR>'
  DB_NAME = '<DB_NAME>';
SHUTDOWN ABORT;
STARTUP MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;

결과 해석:

RMAN은 파라미터 파일이 없어도 SPFILE을 꺼내기 위한 임시 파라미터로 인스턴스를 NOMOUNT까지 띄움

장애 전에 LIST BACKUP OF SPFILE로 자동 백업 위치와 DBID를 확인해 둠

#사용 조건과 주의사항

BCT를 켜기 전에 받은 레벨 0은 추적 기록이 없으므로 BCT를 켠 뒤 레벨 0을 다시 받음