ASM 환경의 백업과 복구

#핵심 요약

ASM 환경에서도 RMAN 명령은 파일 시스템 환경과 같음
다른 것은 파일 위치가 +DATA, +RECO 같은 디스크 그룹이라는 점과, 파일을 보고 지우는 도구가 운영체제 명령이 아니라 asmcmd라는 점임

FRA가 ASM 디스크 그룹이면 아카이브 로그(USE_DB_RECOVERY_FILE_DEST)와 백업 조각도 그 디스크 그룹에 만들어짐

테이블스페이스를 만들 때는 디스크 그룹 이름만 적고(DATAFILE '+DATA'), 파일 이름은 Oracle이 정함

컨트롤 파일 다중화는 CONTROL_FILES를 바꾸고 NOMOUNT에서 RESTORE CONTROLFILE로 복사함
디스크 그룹만 적으면 새 이름으로 만들고 SPFILE도 고쳐 줌

#개념과 동작 원리

데이터 파일을 둘 수 있는 스토리지는 세 가지임
파일 시스템(리눅스 디렉터리의 일반 파일), ASM(Oracle이 직접 관리하는 디스크 그룹), raw device(파일 시스템 없이 디스크 장치에 직접 기록, 지금은 거의 쓰지 않음)

ASM(Automatic Storage Management)은 여러 디스크를 디스크 그룹으로 묶고 파일 배치를 ASM이 정하는 Oracle의 스토리지 관리 기능임
DB 인스턴스와 별도로 ASM 인스턴스(+ASM)가 필요하고, ASM 안의 파일은 운영체제 ls로 볼 수 없어 asmcmd나 SQL로 확인함

설명: asmcmd에서 사람이 정한 이름(current.ctl)은 실제 파일이 아니라 Oracle이 정한 이름(current.<번호>.<번호>)을 가리키는 별칭임
별칭을 지우면 가리키는 실제 파일도 함께 지워짐

#필수 명령어 또는 SQL

#환경 확인과 아카이브 모드 전환

ps -ef | grep pmon

SELECT file_name FROM dba_data_files;
ARCHIVE LOG LIST
SHOW PARAMETER db_recovery_file_dest

결과 해석:

실습 기록: 데이터 파일 이름이 +DATA로 시작했고, 처음에는 NOARCHIVELOG 모드였으며 아카이브 대상은 USE_DB_RECOVERY_FILE_DEST, FRA는 +RECO였음

SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

srvctl stop database -d <DB_NAME>
srvctl start database -d <DB_NAME> -o mount

결과 해석:

설명: Oracle Restart(그리드) 환경이면 srvctl로도 내리고 올릴 수 있음

ALTER SYSTEM SWITCH LOGFILE;
SELECT sequence#, name FROM v$archived_log ORDER BY sequence#;

ls +RECO/<DB_NAME>/ARCHIVELOG/

결과 해석:

실습 기록: 아카이브 로그가 +RECO/<DB_NAME>/ARCHIVELOG/<날짜>/thread_1_seq_8.<번호>.<번호> 형태로 만들어졌음

#RMAN 백업과 데이터 파일 복구

BACKUP DATABASE PLUS ARCHIVELOG;
LIST BACKUP SUMMARY;
LIST BACKUP OF DATAFILE 1;

결과 해석:

실습 기록: 백업 조각 이름이 +RECO/<DB_NAME>/BACKUPSET/<날짜>/nnndf0_tag<번호>.<번호>.<번호> 형태였음

CREATE TABLESPACE ts01 DATAFILE '+DATA' SIZE 10M;

REPORT NEED BACKUP;
BACKUP DATAFILE <FILE_NO>;

결과 해석:

실습에서는 로그 스위치와 체크포인트 뒤 SHUTDOWN ABORT하고, asmcmd의 +DATA/<DB_NAME>/DATAFILE에서 그 데이터 파일을 rm으로 지웠음

STARTUP
SELECT * FROM v$recover_file;

RESTORE DATAFILE <FILE_NO>;
RECOVER DATAFILE <FILE_NO>;

결과 해석:

실습에서는 복구 뒤 DB를 여는 명령과 결과를 적지 않았음
일반 절차는 데이터 파일과 블록 복구에 있음

#컨트롤 파일 다중화

BACKUP CURRENT CONTROLFILE;

ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '<TRACE_FILE>';
SELECT name FROM v$controlfile;

결과 해석:

설명: 작업 전에 컨트롤 파일 백업과 재생성 스크립트를 받아 둠
백업 조각이 +RECO에 만들어진 것으로 FRA 디스크 그룹을 알 수 있음

별칭 이름을 지정해 추가하는 방법:

ALTER SYSTEM SET control_files =
  '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>',
  '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>',
  '+RECO/<DB_NAME>/CONTROLFILE/current.ctl'
  SCOPE = SPFILE;
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT

RESTORE CONTROLFILE TO '+RECO/<DB_NAME>/CONTROLFILE/current.ctl'
  FROM '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>';
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;

결과 해석:

설명: RESTORE CONTROLFILE TO '<위치>' FROM '<복사할_파일>'은 지정한 한 위치에만 복사함
asmcmd의 ls -l에서 current.ctl => +RECO/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>처럼 별칭으로 보임
실습에서는 별칭을 두 개(current.ctl, current2.ctl) 추가했으나 결과 기록에는 세 개만 나옴

디스크 그룹만 지정하는 방법:

ALTER SYSTEM SET control_files =
  '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>',
  '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>',
  '+DATA'
  SCOPE = SPFILE;
SHUTDOWN IMMEDIATE
STARTUP NOMOUNT

RESTORE CONTROLFILE FROM '+DATA/<DB_NAME>/CONTROLFILE/current.<번호>.<번호>';
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;

SELECT name FROM v$controlfile;
SHOW PARAMETER control_files

결과 해석:

설명: TO 없이 RESTORE CONTROLFILE FROM을 쓰면 CONTROL_FILES의 모든 위치에 복원함
디스크 그룹만 적힌 자리는 새 이름으로 만들고 SPFILE의 '+DATA'도 실제 파일 이름으로 바뀜

#온라인 리두 로그 그룹 손실

SELECT group#, status, sequence#, members FROM v$log;
SELECT group#, member FROM v$logfile ORDER BY group#;

결과 해석:

실습 기록: 그룹 세 개, 그룹마다 멤버 두 개이고 모두 +DATA/<DB_NAME>/ONLINELOG/에 있었음
그룹 1, 2는 INACTIVE, 그룹 3은 CURRENT였음

INACTIVE 그룹: 실습에서는 SHUTDOWN ABORT 뒤 asmcmd에서 그룹 1의 멤버 두 개를 지우고 다음처럼 복구했음

ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE ADD LOGFILE GROUP 1;

결과 해석:

실습에서는 ADD LOGFILE GROUP 1에 파일 위치를 적지 않았음
새 멤버가 어디에 몇 개 만들어지는지는 기재 없음

CURRENT 그룹: 실습에서는 미리 전체 백업을 받은 뒤 그룹 3의 멤버 두 개를 지우고 불완전 복구했음

RUN {
  SET UNTIL SEQUENCE 3 THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

ALTER DATABASE OPEN RESETLOGS;

결과 해석:

실습에서는 이 절차를 "cancel base 불완전 복구"로 불렀지만 명령은 시퀀스 기준임
실습에서는 끝난 뒤 다시 전체 백업을 받았음
리두 로그 상태별 판단은 리두 로그 장애 처리에 있음

#ASM 인스턴스 장애와 디스크 그룹 복구

SELECT inst_id, name, state FROM gv$asm_diskgroup ORDER BY inst_id, name;
SELECT * FROM gv$asm_operation;

tail -f "$ORACLE_BASE/diag/asm/+asm/+ASM2/trace/alert_+ASM2.log"

-- 2번 DB 인스턴스를 먼저 내린 뒤(srvctl stop instance)
ALTER DISKGROUP DATA DISMOUNT;
-- (실습에서는 이 상태에서 1번 ASM을 강제 종료)
ALTER DISKGROUP DATA MOUNT;

srvctl status asm
srvctl start asm -node <NODE1>
srvctl status database -db <DB_NAME>
srvctl start database -db <DB_NAME>

결과 해석:

1. 다른 ASM이 살아 있는 경우: 1번 ASM의 PMON을 kill -9로 죽인 뒤 2번 ASM에서 보면 DATA, FRA가 계속 MOUNTED였음
   수업 자료는 남은 ASM이 바로 복구한다고 설명함
2. 마지막 ASM이 멈춘 경우: 2번 DB 인스턴스를 내리고 2번 ASM에서 DATA를 DISMOUNT해 1번 ASM만 마운트한 상태로 만든 뒤 1번 ASM을 강제 종료하고, 2번 ASM에서 DATA를 다시 MOUNT하면 그때 crash recovery가 일어난다고 설명함(alert log의 "ASM Crash Recovery", "Completing crash recovery" 같은 메시지로 확인)
3. 마지막에는 1번 ASM을 srvctl start asm으로 올려 두 노드 모두 DATA, FRA가 MOUNTED인지 보고 DB를 기동함
   실습 출력에는 이때 두 DB 인스턴스가 모두 멈춰 있었음

"즉시 복구"와 "다음 마운트 때 복구"는 수업 자료의 설명이며, MOUNTED 상태만으로 실제 복구가 일어났는지 입증할 수 없어 ASM alert log의 메시지와 시점으로 확인함

GV$ASM_OPERATION은 주로 리밸런싱 진행 상태를 조회하는 뷰임
ASM 장애 복구 완료 여부는 alert log도 확인해야 함

DB 인스턴스 복구와 ASM 디스크 그룹 메타데이터 복구는 다른 것임

ASM PMON 강제 종료는 DB와 Clusterware에 영향을 주고 Clusterware가 자동 재기동해 순서가 달라질 수 있으므로 격리된 실습 VM에서만 함

#사용 조건과 주의사항

ASM 파일은 asmcmd나 SQL로만 다룸
실습의 rm은 장애를 만들기 위한 것임