RMAN ARCHIVE 복구 시나리오

BUMSOO·2024년 9월 13일
RMAN오라클 DBA

Backup & Recovery

목록 보기
12/18
  • noarchive 모드에서 archive 모드로 변경 전 변경사항
    -스토리지 이슈로 log archive dest 설정을 2개에서 1개로 줄이겠다.

alter system reset log_archive_dest_2 scope=spfile;

log_archive_dest 파라미터는 static 파라미터이다.

  • 모드가 변경 되면 이전 백업본은 의미가 없어진다.

archive mode에서는 DB가 운영중인 상태에서도 RMAN으로 backup database를 할 수 있다.

online backup 받은걸 확인하면 datafile 과 control file의 scn번호가 다른걸 확인할 수있는데, user managed 방식에서는 scn 차이때문에 복구가 안됬지만 RMAN에서는 SCN이 달라도 복구가 가능하다.

RMAN을 이용한 ARCHIVE 복구 1

일반 테이블스페이스 복구

  1. 테이블 생성

  2. 수동으로 log switch 발생해서 아카이크 로그 파일 생성

  3. 데이터파일 삭제로 장애유발

rman에서 복구작업

  1. rman 에서 controlfile의 정보를 확인해보면 user 데이터파일은 없기 때문에 사이즈가 0으로 조회된다.
    report schema

  2. 어떤 문제로 장애가 발생되었는지 RMAN에서 확인하는 방법
    1) list failure; : 장애 원인을 알려준다

2) list failure 장애번호 detail; : 장애에 대해 자세히 알려준다.

  1. RMAN 에서 아카이브로그 파일 확인하는 방법
    list archivelog all;

  2. 문제가 있는 테이블스페이스를 offline 모드로 변경한다
    sql 'alter tablespace users offline immediate';
    - immediate를 하면 해당 테이블스페이스에 checkpoint를 발생하지 않는다.

  3. 문제있는 테이블스페이스의 데이터파일만 restore 해준다.
    restore tablespace users;

  4. 해당 테이블스페이스를 recover 해서 완전복구
    recover tablespace users;

  5. 복구가 완료됬으면 online으로 모드 변경
    sql 'alter tablespace users online';

RMAN을 이용한 ARCHIVE 복구 2

일반 테이블스페이스를 다른 위치에 복구

  1. 테이블스페이스를 생성하는데 다른 위치로 생성

  2. 신규 테이블스페이스에 신규 테이블 생성

  3. RMAN 에서 특정한 테이블스페이스만 백업
    backup tablespace insa_tbs;

  4. 백업 리스트 확인
    list backup;

  5. 특정한 테이블스페이스에 대한 백업정보만 확인하고 싶을때
    list backup of tablespace insa_tbs;

  6. 특정 데이터파일 삭제로 장애유발

  7. DB 비정상 종료 후 MOUNT 단계까지 재실행 후 문제되는 데이터파일을 OFFLINE으로 변경

  8. DB OPEN

  9. RMAN에서 복구해야할 데이터파일의 위치를 변경 후 restore을 하고 recover 까지 한번에 수행

run {
	--sql 'alter tablespace insa_tbs offline immediate'; 우리는 이미 이전에 문제있는 데이터파일을 offline 모드로 변경하였기 때문에 수행하지 않는다.
    set newname for datafile 4 to '/u01/app/oracle/oradata/ORA19C/insa_tbs01.df';
    restore tablespace insa_tbs;
    switch datafile 4;
    recover tablespace insa_tbs;
    sql 'alter tablespace insa_tbs online';
}
  1. 데이터파일의 위치도 변경 되었고, online으로 변경되었다.

  1. 이제 필요가 없다고 생각되어 테이블스페이스를 삭제

  2. rman에서 정책상 필요없는 백업정보, 아카이브 정보 확인
    report obsolete;

  1. 정책상 필요없는 백업정보, 아카이브 정보 삭제
    delete obsolete;

RMAN을 이용한 ARCHIVE 복구 3

system datafile 손상

  1. system datafile 삭제로 장애유발

  2. DB 비정상 종료 후 재시동 하지만 mount 단계까지만 실행 후 오류 발생

  3. system 파일은 offline으로 변경해도 DB를 OPEN 할 수는 없다.

  4. RMAN 에서 system datafile만 restore

  5. restore 한 system 파일을 recover 해준다.

  6. system 파일을 online으로 변경 후 DB OPEN 해주면 된다.

  7. control 파일에 변경사항이 생겨 자동으로 새롭게 백업이 되었다. rman 에서 정책상 필요없는 백업정보를 확인해보면 이전 control file 백업본이 조회된다.
    report obsolete;

  8. 이전 control file 백업본은 필요 없기 때문에 삭제해줘도 된다.
    delete obsolete;

RMAN을 이용한 ARCHIVE 복구 4

모든 데이터파일이 손상, 기존위치가 아닌 새로운 위치로 데이터파일 복구

  1. RMAN 으로 받은 가장 최근의 백업본 SCN 이후에 대한 아카이브 로그 파일이 있는지 확인

  2. 모든 데이터파일 삭제로 장애유발

  3. DB 비정상적인 종료

  4. rman으로 현재 schema 정보 확인

  5. 컨트롤파일에 데이터파일, 템프 파일 위치 변경 후 restore 하고 recover 후 DB OPEN 까지 하면 된다.

run {
	set newname for datafile 1 to '/home/oracle/oradata/system01.dbf';
    set newname for datafile 2 to '/home/oracle/oradata/undotbs01.dbf';
    set newname for datafile 3 to '/home/oracle/oradata/sysaux01.dbf';
    set newname for datafile 5 to '/home/oracle/oradata/example01.dbf';
    set newname for datafile 7 to '/home/oracle/oradata/users01.dbf';
    set newname for tempfile 1 to '/home/oracle/oradata/temp01.dbf';

	restore database;
    switch datafile all;
    switch tempfile all;	
    recover database;
    
    alter database open;
}

RMAN을 이용한 ARCHIVE 복구 5

백업 받지 않은 테이블스페이스에 데이터 파일이 손상

  1. 새로운 테이블스페이스 생성 후 해당 테이블스페이스에 테이블을 생성

  2. 백업 받지 않았는데 데이터파일을 삭제해버려 장애유발

  3. DB를 정상적으로 종료 시도 하지만 오류 발생

  4. DB를 비정상 종료 후 RMAN 으로 접속

  5. startup 하지만 손상된 데이터파일이 있기 때문에 open 되지않는다. 하지만 다른 업무들은 수행해야 하기 때문에 문제있는 데이터파일만 offline 으로 변경 후 DB OPEN

  6. 문제있는 데이터파일은 백업파일이 없기 때문에 redo 정보를 받을 데이터파일을 생성해줘야 한다.
    alter database create datafile '/u01/app/oracle/oradata/ORA19C/data_tbs01.dbf';

  7. 생성된 데이터파일로 redo 정보를 recover 해주면 된다.
    recover datafile '/u01/app/oracle/oradata/ORA19C/data_tbs01.dbf';

  8. recover 되었으면 online으로 변경할 수 있고 정상적으로 조회가 된다.

그 후 테이블스페이스에 데이터파일 추가 후 손상

  1. data tbs 테이블스페이스에 데이터파일을 추가
    alter tablespace data_tbs add datafile '/u01/app/oracle/oradata/ORA19C/data_tbs02.dbf' size 5m;

  2. 신규 테이블 생성

create table hr.emp_2024 tablespace data_tbs as select * from hr.employees;
  1. 어떤 데이터파일을 사용하고 있는지 확인
select f.tablespace_name, f.file_name,count(*)
from dba_extents e, dba_data_files f
where f.file_id = e.file_id
and e.segment_name = 'EMP_2024'
and e.owner = 'HR'
group by f.tablespace_name, f.file_name;

  1. 대량의 데이터를 추가하여 데이터파일을 추가한 데이터파일을 쓰도록 유도

  2. 추가한 데이터파일은 백업을 안해놨기 때문에 데이터파일 레벨로 백업

  3. 추가한 데이터파일 삭제로 장애 유발

  4. DB 종료하려고 하는데 오류발생

  5. RMAN으로 접속 후 MOUNT 단계까지 실행

  6. list failure로 문제되는 파일 확인

  1. 문제되는 데이터파일 offline 으로 변경 후 DB OPEN

  2. hr.new는 data_tbs01 에만 존재하기 때문에 조회가 가능하지만 hr.emp_2024는 data_tbs01에도 존재하지만 data_tbs02에도 존재하기 때문에 조회하려고 하면 오류가 발생한다.'

  3. rman에서 recover 필요한 데이터파일만 restore 작업

  4. restore 되면 recover도 데이터파일 레벨로 수행

  5. recover 된 데이터파일은 online으로 변경하면 끝난다.

  6. 이후 아까 조회 오류가 났던 hr.emp_2024테이블을 조회해보면 정상적으로 조회된다.

  7. 테이블스페이스 삭제 후 백업파일도 필요없어졌으니 정책상 필요없는 백업파일 및 아카이브 로그 파일을 조회 후 삭제해준다.

RMAN을 이용한 ARCHIVE 복구 6

데이터베이스가 정상적인 종료 후에 undo datafile 손상

  1. DB 정상적인 종료 후 UNDO 파일 삭제로 장애유발

  2. DB를 재실행 하지만 OPEN 하지 못하고 MOUNT 단계에서 오류발생

  3. undo 데이터파일은 offline 으로 변경 후 DB OPEN

  4. RMAN 실행 후 undo 데이터파일을 RESTORE

  5. 데이터파일 레벨로 UNDO 파일 RECOVER

  6. UNDO 파일 ONLINE 으로 변경

RMAN을 이용한 TIME BASE RECOVERY(불안전 복구)

  1. 새로운 테이블스페이스 생성

  2. 생성된 테이블스페이스 확인

select a.file#, b.name ,a.name, a.status, a.checkpoint_change#
from v$datafile a, v$tablespace b
where a.ts# = b.ts#;

  1. 신규 테이블스페이스를 기반으로한 테이블 생성

  2. 전체 파일 백업

  3. 정책상 이제는 필요 없는 백업과 아카이브파일 삭제
    report obsolete;
    delete obsolete;

  1. 새롭게 백업을 받은 후에는 current한 리두로그 파일을 아카이브로그파일로 생성하는 습관을 가져야한다.
    alter system archive log current;

  2. 신규 테이블스페이스를 기반으로 한 두번째 테이블 생성

  3. 테이블스페이스 삭제
    drop tablespace data_tbs including contents and datafiles;

  4. RMAN 에서 백업정보를 확인해보면 물리적으로 삭제된 데이터파일의 이름은 보여주지 않는다.

  5. timebase recovery 하기 위해서 DB 종료

  6. 복구해야하는 테이블스페이스에 대한 정보는 과거 백업 컨트롤 파일이 가지고 있다. 따라서 과거 백업 컨트롤파일을 restore해야 하기 때문에 DB는 일단 nomount 단계로 실행해야한다.
    startup nomount

  7. 백업 컨트롤파일 restore
    restore controlfile from '/u01/app/oracle/fast_recovery_area/ORA19C/autobackup/2024_09_19/o1_mf_s_1180086756_mgpxgng2_.bkp';

  8. 백업컨트롤파일을 가지고 mount 단계로 변경
    alter database mount;

  9. alert log에서 데이터파일 삭제 시간을 확인 후 time base recover를 수행한다.

  • 단 time base recovery를 하기전 세션의 date 포맷을 변경한다.
2024-09-19T10:07:17.492380+09:00
Deleted file /u01/app/oracle/oradata/ORA19C/data_tbs01.dbf
Completed: drop tablespace data_tbs including contents and datafiles
alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

run {
	set until time '2024-09-19 10:07:00';
    restore database;
    recover database;}

  1. 복구 완료되었으면 DB를 OPEN 하고 복구된 데이터를 확인

  2. DB를 RESETLOGS로 OPEN 하였기 때문에 이전 백업파일 및 아카이브파일은 필요가 없기 때문에 정책상으로 필요없는 파일들 확인
    report obsolete;

  3. 확인 후 삭제 시도
    delete obsolete;

    - 삭제를 진행하다 보면 control파일이 가지고 있는 논리적인 archive 정보와 물리적인 archive 정보가 맞지 않아 경고가 발생한다.

  4. crosscheck를 통해 맞지 않는 archive 파일은 expired 시킨다.
    crosscheck archivelog all;

  5. 그 후 expired 된 archive log 파일 확인

  • 꼭 확인 하기전에 crosscheck를 먼저 진행해야 한다.
    list expired archivelog all;
  1. 확인 후 expired 된 파일 삭제
    delete expired archivelog all;

RMAN을 이용한 TIME BASE RECOVERY

clone DB 생성

  1. 새롭게 전체 파일 백업
    backup database;

  2. 테이블 생성 후 로그스위치 발생으로 아카이브로그 파일 생성

  3. 시간 확인후 생성했던 테이블 삭제

  • 정석적으로는 log miner를 확인해서 시간 확인해야 한다.

  1. clone 디렉터리 생성
    mkdir clone

  2. init파일을 clone DB에 맞게 수정

  3. 아카이브로그 파일들 전체 clone 디렉터리로 복사

  4. 백업 컨트롤 파일 피스 & 데이터파일 피스도 clone 디렉터리로 복사

  5. oracle 환경변수 변경

  6. DB를 clone pfile을 이용하여 nomount 단계까지 실행
    startup pfile='$ORACLE_HOME/dbs/initclone.ora' nomount

  7. RMAN을 auxiliary로 열기

  • DB를 만들때는 auxiliary로 연다. 타겟 DB가 없기 때문이다.
  1. 집합문을 통해 clone DB 생성
  • 백업 피스안에 있는 데이터파일 번호를 작성해야한다.
run{
set newname for datafile 1 to '/home/oracle/clone/system01.dbf';
set newname for datafile 2 to '/home/oracle/clone/undotbs01.dbf';
set newname for datafile 3 to '/home/oracle/clone/sysaux01.dbf';
set newname for datafile 5 to '/home/oracle/clone/example01.dbf';
set newname for datafile 7 to '/home/oracle/clone/users01.dbf';
set newname for tempfile 1 to '/home/oracle/clone/temp01.dbf';

duplicate target database to 'clone'
pfile='$ORACLE_HOME/dbs/initclone.ora'
nofilenamecheck
backup location '/home/oracle/clone'
until time "to_date('2024-09-19 11:22:00','yyyy-mm-dd hh24:mi:ss')"
logfile '/home/oracle/clone/redo01.log' size 50m,
		'/home/oracle/clone/redo02.log' size 50m,
        '/home/oracle/clone/redo03.log' size 50m; }
  1. clone DB 확인
  • 운영DB에는 삭제되었던 테이블이 존재하는걸 확인할 수 있다.

RMAN을 이용한 TIME BASE RECOVERY

clone DB 생성, pfile에 convert하게 파일지정, 복제시 필요없는 테이블스페이스 skip

  1. 새로운 테이블 생성

  2. 생성한 테이블 삭제 후 log miner를 통해 삭제 시간 확인

  3. clone DB 생성할때 current한 log도 분석 대상이기 때문에 archive log파일로 떨어트린다.
    alter system archive log current;

  1. clone DB 생성을 위한 pfile 생성
    create pfile='$ORACLE_HOME/dbs/initclone.ora' from spfile;

  2. 백업 컨트롤파일&데이터파일, 아카이브로그파일을 담을 clone 디렉터리 생성
    mkdir clone

  3. clone pfile 수정

  • 복제 DB 생성시 set newname을 해도 되지만 그 작업이 귀찮을 경우 pfile에서 일괄적으로 설정할 수 있다.
  • 단, 파일들의 위치가 모두 동일해야하며, 파일들의 위치가 다를 경우 이 방법은 사용할 수 없다.
*.compatible='19.0.0'
*.control_files='/home/oracle/clone/control01.ctl'
*.db_name='clone'
*.log_archive_dest_1='location=/home/oracle/clone mandatory'
*.log_archive_format='arch_%t_%s_%r.arc'
*.undo_tablespace='UNDOTBS1'
# 파일들의 위치가 동일하면 해당 방법으로 변경 가능하지만, 파일들의 위치가 다르면 set newname을 해야한다.
DB_FILE_NAME_CONVERT=(/u01/app/oracle/oradata/ORA19C/, /home/oracle/clone/)
LOG_FILE_NAME_CONVERT=(/u01/app/oracle/oradata/ORA19C/, /home/oracle/clone/)
  1. 아카이브로그파일, 백업 컨트롤파일, 데이터파일을 clone 디렉터리로 복사

  1. 새로운 세션창에서 oraenv 환경변수 설정

  2. clone DB를 pfile을 이용해 nomount 단계까지 실행

  3. 아직 target DB가 없기 때문에 RMAN을 auxiliary로 실행

  4. run 집합문을 통해 복제 DB 생성

  • DB 복제할때 스킵해도 되는 테이블스페이스가 있을 경우 skip문을 사용가능하다.
  • pfile에 데이터파일과 로그파일의 위치변경을 미리 해놓았기 때문에 run 구문안에 따로 설정하지 않아도 된다.
  • skip해야하는 대상이 여러개 인 경우 skip tablespace users, tablespace example..
  • 혹은 skip 해야하는 대상이 많은 경우 필수적으로 필요한 테이블스페이스(system, sysaux,undo,temp)를 제외하고 지정하는 방식은 tablespace users 로 지정해도 된다.
run{
duplicate target database to 'clone'
skip tablespace users
pfile='$ORACLE_HOME/dbs/initclone.ora'
nofilenamecheck
backup location '/home/oracle/clone'
until time "to_date('2024-09-19 14:50:00','yyyy-mm-dd hh24:mi:ss')"; }

- default tablespace인 users를 skip하고 DB를 복제생성시 system이 default tablespace가 된다.

  1. 복구한 테이블 확인

  1. SKIP한 테이블스페이스는 존재하지 않는다.

  2. 이후 clone DB에서 import 후 운영DB에 export 해주면 된다.

RMAN을 이용한 scn base recovery

특정한 데이터파일 손상, 아카이브 손상(until scn 복구작업 해야한다.)

  • rman의 백업 시간을 자세히 확인하고 싶을때
    os에서 export NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss' 설정

  1. 백업파일의 scn을 확인후 몇번 시퀀스의 아카이브로그파일부터 필요하지 확인

  2. DB 정상 종료 후 특정 데이터파일 및 특정 아카이브파일 삭제

  3. startup 하지만 특정데이터파일이 없어 오류 발생(mount 단계까지는 실행됨)

  4. rman에서 오류 확인
    list failure

  5. 손상된 데이터파일을 백업파일에서 restore 후 recover을 시도

  • recover 시도 중 아카이브파일이 없어 완전복구 실패했다.
  1. scn을 이용한 불안전 복구 시도
run {
	set until scn=6632865;
    restore database;
    recover database;}

  1. 복구가 완료되면 DB는 RESETLOGS로 OPEN하면 된다.

RMAN을 이용한 ARCHIVE 백업 7

control file, 모든 datafile손상

  1. 신규 테이블 생성

  2. 수동으로 로그스위치 발생

  3. control file, data file 삭제로 장애유발

  4. DB는 비정상적으로 종료

  5. DB는 nomount 단계까지 실행 후 RMAN 실행

  6. 가장 최근에 백업받아놓은 control file을 restore

  • 기존에는 백업받은 위치를 지정해서 restore를 했지만, autobackup으로 지정하면 가장최근에 받아놓은 control file 백업본을 찾아 자동으로 restore 해준다.
    restore controlfile from autobackup;

  1. restore한 백업 control file을 이용해 mount 단계까지 실행
    alter database mount;

  2. 백업받아놓은 데이터파일 restore
    restore database;

  3. redo는 정상적으로 남아있기 때문에 redo를 이용해서 완전복구 recover 수행
    recover database;

  4. 복구가 완료된 후 DB는 RESETLOGS로 OPEN 한다.

  5. RESETLOGS로 DB OPEN 후 이전 백업파일과 아카이브로그파일은 의미가 없기 때문에 삭제 하는걸 권장한다.
    report obsolete;
    delete obsolete;
    crosscheck archivelog all;
    list expired archivelog all;
    delete expired archivelog all;

RMAN을 이용한 ARCHIVE 백업 8

control file, 모든 redo log file손상

  1. 신규 테이블 생성

  1. 로그스위치 발생

  2. 두번째 신규 테이블 생성

  • 현재 current한 리두로그파일에 저장되어있다.

  1. control file, redo log file 삭제로 장애유발

  2. DB 비정상적인 종료 후 RMAN으로 DB를 nomount 단계까지 실행

  3. 가장 최근에 백업받은 control file을 restore 한 후 mount 단계로 변경

  4. redo가 손상된줄 모르고 recover를 하지만 현재 current한 리두가 없기 때문에 오류발생

  5. 살아있는 아카이브로그파일까지는 recover이 가능하기때문에 scn base recovery를 수행 후 DB OPEN은 RESETLOGS로 해야한다.

  6. 복구 데이터를 확인해보면 아카이브로그파일에 저장되어있던 fri 테이블은 살아있지만 current한 리두로그에 저장되어있던 sat 테이블은 손실된걸 확인 할 수 있다.

RMAN을 이용한 ARCHIVE 백업 9

spfile, pfile 손상

  1. DB ID값 확인

    또는
    select dbid,name, log_mode from v$database;

  2. DB 정상 종료

  3. spfile, pfile을 삭제

  4. DB를 startup 해보지만 초기파라미터 파일이 없기때문에 불가능

  1. RMAN 에서는 초기파라미터 파일이 없지만 RMAN에서 제공하는 샘플 메모리를 이용해서 nomount 단계까지는 실행 가능하다.

  2. 이전 확인했던 DBID를 설정 해야한다.

  3. spfile을 restore 할때 from autobackup으로 시도해보지만 오류가 발생 시 수동으로 위치를 설정해주면 spfile을 restore 할 수 있다.

  4. spfile은 원래 위치인 $ORACLE_HOME/dbs에 restore 되었으니 DB를 내린다음 다시 startup 하면 정상적으로 DB가 올라온걸 확인 할 수 있다.

profile
BUMSOO
이전 포스트

RMAN NOARCHIVE 복구 시나리오

다음 포스트

Image Copy

0개의 댓글