Recovery Catalog 구성과 등록
Recovery Catalog 생성과 대상 DB 등록, 저장 스크립트 관리 및 등록 해제와 삭제 절차
#핵심 요약
Recovery Catalog는 RMAN 메타데이터를 대상 데이터베이스의 컨트롤 파일 밖, 별도 데이터베이스(카탈로그 DB)에 보관하는 스키마임
백업 파일 자체는 대상 쪽에 있음
절차: 카탈로그 DB에 소유자를 만들고 RECOVERY_CATALOG_OWNER 역할을 준 뒤, 그 사용자로 RMAN에 접속해 CREATE CATALOG, 대상과 카탈로그에 함께 접속해 REGISTER DATABASE
카탈로그에는 RMAN 스크립트를 저장해 RUN { EXECUTE SCRIPT ... }로 실행할 수 있음
KEEP FOREVER 보관용 백업은 카탈로그가 있어야 만들 수 있음(백업 보존과 정리)
#개념과 동작 원리
카탈로그 소유자에게 RECOVERY_CATALOG_OWNER 역할을 줌
이 역할에 카탈로그 유지와 조회에 필요한 권한이 모두 있음
공식 예시는 기본 테이블스페이스에 QUOTA UNLIMITED를 줌
CREATE CATALOG는 카탈로그 소유자의 기본 테이블스페이스에 카탈로그 테이블을 만듦TABLESPACE로 따로 지정할 수도 있음
12.1.0.2부터 카탈로그 DB는 Enterprise Edition이어야 하고, 카탈로그 DB에 Oracle Partitioning을 켜야 함
EXECUTE SCRIPT는 RUN 블록 안에서 실행함
스크립트 안의 명령 하나가 실패하면 그 뒤 명령은 실행되지 않음
같은 이름의 로컬 스크립트와 전역 스크립트가 있으면 로컬을 실행함
UNREGISTER DATABASE는 데이터베이스 이름과 DBID를 보여 주고 확인(YES/NO)을 받음
등록을 다시 할 가능성이 있으면 미리 LIST BACKUP SUMMARY, LIST COPY SUMMARY를 남겨 두라고 권함
컨트롤 파일에 없는 저장 스크립트는 함께 사라짐
RMAN 백업 정보는 대상 DB의 컨트롤 파일, 또는 Recovery Catalog(별도 테이블스페이스나 별도 DB)에 저장됨
| Recovery Catalog의 장점 | 내용 |
|---|---|
| 스크립트 저장 | RMAN 백업, 복구 스크립트를 저장하고 EXECUTE SCRIPT로 실행 |
| 더 많은 기록 | 컨트롤 파일보다 오래, 많은 백업 기록을 보관 |
| 컨트롤 파일 손실 대비 | 컨트롤 파일을 복구하지 못해도 백업 기록을 잃지 않음 |
| 영구 보관 | KEEP FOREVER로 중요한 백업을 영구 보관 가능 |
카탈로그 삭제는 만들 때의 역순(등록 해제, 카탈로그 삭제, 사용자와 테이블스페이스 정리)으로 진행함
#필수 명령어 또는 SQL
#카탈로그 DB 쪽 준비
CREATE TABLESPACE rc_ts DATAFILE '<DATAFILE_DIR>/rc_ts01.dbf' SIZE 100M;
CREATE USER <CATALOG_USER> IDENTIFIED BY <PASSWORD> DEFAULT TABLESPACE rc_ts;
GRANT RECOVERY_CATALOG_OWNER TO <CATALOG_USER>;
GRANT UNLIMITED TABLESPACE TO <CATALOG_USER>;결과 해석:
실습에서는 Quota 대신 UNLIMITED TABLESPACE 권한을 줬음
공식 예시는 QUOTA UNLIMITED ON <테이블스페이스>임
tnsping <CATALOG_SERVICE>
rman catalog <CATALOG_USER>@<CATALOG_SERVICE>CREATE CATALOG TABLESPACE rc_ts;결과 해석: 개별 실행 출력은 기재 없음
#대상 등록
rman target sys@<TARGET_SERVICE> catalog <CATALOG_USER>@<CATALOG_SERVICE>REGISTER DATABASE;LIST DB_UNIQUE_NAME ALL;
LIST BACKUP OF DATABASE;결과 해석:
실습 기록: 접속 때 connected to target database: NONCDB (DBID=<DBID>)와 connected to recovery catalog database가 나왔고, 등록 때 database registered in recovery catalog, starting full resync of recovery catalog, full resync complete가 나왔음
#RAC 노드에 카탈로그 DB 만들기와 카탈로그가 멈췄을 때
실습은 별도 VM을 둘 메모리가 없어 1번 노드에 카탈로그용 싱글 non-CDB를 만들고, 데이터 파일은 공유 ASM이 아닌 그 노드 로컬 파일 시스템에 둬 공유 디스크 장애와 분리했음
그 노드가 죽으면 카탈로그도 멈추므로 운영에서는 복구 대상 RAC와 다른 서버에 둠
$ORACLE_HOME/bin/dbca -silent -createDatabase \
-templateName General_Purpose.dbc \
-gdbName <CATALOG_DB_NAME> -sid <CATALOG_DB_NAME> \
-databaseConfigType SINGLE -nodelist <NODE1> \
-createAsContainerDatabase false \
-sysPassword <PASSWORD> -systemPassword <PASSWORD> \
-storageType FS -datafileDestination <DATAFILE_DIR> \
-characterSet AL32UTF8 -nationalCharacterSet AL16UTF16 \
-memoryMgmtType AUTO_SGA -totalMemory 800 \
-emConfiguration NONE -ignorePreReqs
srvctl config database -d <CATALOG_DB_NAME>
srvctl status database -d <CATALOG_DB_NAME>결과 해석:
-databaseConfigType SINGLE -nodelist로 RAC 옵션이 켜진 DB 홈에서도 한 노드 전용 싱글 DB를 만들고, -storageType FS로 로컬 디스크에 둠-totalMemory는 SGA+PGA 합계(MB)
실습 기록: 약한 암호라 DBT-06208 경고만 나고 100% complete, srvctl config database에 <DB_NAME>와 <CATALOG_DB_NAME> 두 개, <CATALOG_DB_NAME>은 Type: SINGLE, Configured nodes는 1번 노드였음
클러스터의 싱글 DB도 CRS 자원(ora.<CATALOG_DB_NAME>.db)으로 등록돼 srvctl로 관리함
다른 노드에서 원격 접속이 ORA-12514면 카탈로그 DB에서 ALTER SYSTEM SET local_listener = '(ADDRESS=(PROTOCOL=TCP)(HOST=<NODE1>)(PORT=1521))' SCOPE = BOTH, ALTER SYSTEM REGISTER
대상 등록은 ORACLE_SID가 대상 인스턴스인 창에서 함
카탈로그 DB 자신을 대상으로 등록하지 않도록 창을 구분하며, RAC는 DBID가 하나라 한 번 등록하면 두 thread의 이력이 같은 DB로 관리됨(rc_archived_log에 thread 1, 2가 모두 보임)
srvctl stop database -d <CATALOG_DB_NAME>
srvctl status database -d <DB_NAME>
rman target / catalog <CATALOG_USER>@<CATALOG_SERVICE> # RMAN-04004 ... ORA-12514
rman target / nocatalog # BACKUP ARCHIVELOG ALL
srvctl start database -d <CATALOG_DB_NAME>
rman target / catalog <CATALOG_USER>@<CATALOG_SERVICE> # RESYNC CATALOG결과 해석:
실습 기록: 카탈로그 DB를 내려도 대상 RAC의 두 인스턴스는 계속 실행됐고, 카탈로그 접속은 RMAN-04004: error from recovery catalog database: ORA-12514로 실패했지만 nocatalog 백업은 컨트롤 파일에만 기록됐음
카탈로그를 다시 띄운 뒤 RESYNC CATALOG로 그동안의 이력을 반영했음
연습 문제: 백업 스크립트를 2번 노드로 옮기자 카탈로그 접속이 ORA-12154로 실패해 nocatalog로만 백업된 경우, 2번 노드 tnsnames.ora에 카탈로그 별칭을 넣고 RESYNC CATALOG로 이력을 반영함
#저장 스크립트
CREATE SCRIPT whole_backup {
BACKUP DATABASE INCLUDE CURRENT CONTROLFILE;
}
RUN { EXECUTE SCRIPT whole_backup; }SELECT * FROM rc_stored_script;
SELECT * FROM rc_stored_script_line;결과 해석:
실습에서는 카탈로그 소유자로 위 뷰를 조회해 저장된 스크립트와 그 줄을 확인했음
#등록 해제와 카탈로그 삭제
UNREGISTER DATABASE;DROP CATALOG;
DROP CATALOG;DROP USER <CATALOG_USER> CASCADE;
DROP TABLESPACE rc_ts INCLUDING CONTENTS AND DATAFILES;결과 해석:
설명: DROP CATALOG는 두 번 실행해야 함
첫 실행이 확인을 요구하는 동작으로 보이나, 공식 문서의 해당 문장은 확인 불가
#사용 조건과 주의사항
실습에서는 대상 접속 문자열에 SYS 비밀번호를 적었음
위 블록은 비밀번호를 프롬프트로 받는 형태로 바꿨음