2024년 1월 24일 2교시 RMAN을 이용한 장애 복구 시나리오 1

 

<<RMAN 장애 복구 시나리오 1>>

 

 

select a.group#, b.sequence#, a.member, b.bytes/1024/1024MB, b.archived, b.status
from v$logfile a, v$log b
where a.group# = b.group#
order by 1;

리두 정보 확인하기

 

 

커런트한 리두로그 그룹 번호 2 번, 시퀀스 번호 5번

나머지 그룹번호 1, 3 번 (각각 시퀀스 번호 4, 3) 은 인액티브 상태

 

아카이브 확인하기

 

SYS@ora11g> ! ls /home/oracle/arch1
arch_1_10_1158423268.arc  arch_1_3_1158423268.arc
arch_1_11_1158423268.arc  arch_1_4_1158423268.arc
arch_1_1_1158423268.arc   arch_1_5_1158423268.arc
arch_1_12_1158423268.arc  arch_1_6_1158423268.arc
arch_1_13_1158423268.arc  arch_1_7_1158423268.arc
arch_1_14_1158423268.arc  arch_1_8_1158423268.arc
arch_1_2_1158423268.arc   arch_1_9_1158423268.arc

 

 

1. 샘플 테이블 생성하기

 

SYS@ora11g> create table hr.loc_new tablespace users as select * from hr.employees;
Table created.

 

테이블 생성하고

 

SYS@ora11g> select count(*) from hr.loc_new;

  COUNT(*)
----------
       107

 

확인해보기

이 테이블 생성 정보와 조회 정보는 커런트한 리두로그 그룹 (그룹번호 2번) 에 기록되게 된다.

 

2. 로그 스위치 발생시키기 (3번)

 

SYS@ora11g> alter system switch logfile;
System altered.

 

/

/

 

★ ★ ★ ★ ★ 이때 항상 alert log 를 보는 습관을 가지자. ★ ★ ★ ★ ★

 

3. 아카이브 떨어진 것도 확인해보기

 

SYS@ora11g> ! ls /home/oracle/arch1
arch_1_10_1158423268.arc  arch_1_2_1158423268.arc
arch_1_11_1158423268.arc  arch_1_3_1158423268.arc
arch_1_1_1158423268.arc   arch_1_4_1158423268.arc
arch_1_12_1158423268.arc  arch_1_5_1158423268.arc
arch_1_13_1158423268.arc  arch_1_6_1158423268.arc
arch_1_14_1158423268.arc  arch_1_7_1158423268.arc
arch_1_15_1158423268.arc  arch_1_8_1158423268.arc
arch_1_16_1158423268.arc  arch_1_9_1158423268.arc
arch_1_17_1158423268.arc

 

4. 리두 정보 다시 확인하기

 

select a.group#, b.sequence#, a.member, b.bytes/1024/1024MB, b.archived, b.status
from v$logfile a, v$log b
where a.group# = b.group#
order by 1;

 

커런트 리두 바뀌지 않았으며, 여전히 2번 그룹(시퀀스 번호 8번)이고

나머지 2개 (1번 그룹과 3번 그룹) 는 인액티브 상태 - 각각 시퀀스 번호 7번과 6번

 

 

5. 새로 만든 테이블 지워서 장애 유발시키기 위해

저 테이블이 어느 테이블스페이스에 있는지 확인해보기

 

select f.tablespace_name, f.file_name
from dba_extents e, dba_data_files f
where f.file_id = e.file_id
and e.segment_name ='LOC_NEW'
and e.owner = 'HR';

테이블이 어느 테이블스페이스에 있는지 확인:

/u01/app/oracle/oradata/ora11g/users01.dbf (USERS) 라는 테이블스페이스에 있다.

 

 

6. 저 테이블이 있는 테이블스페이스 지워버리기

 

SYS@ora11g> ! rm /u01/app/oracle/oradata/ora11g/users01.dbf

 

SYS@ora11g> ! ls /u01/app/oracle/oradata/ora11g/users01.dbf

ls: cannot access /u01/app/oracle/oradata/ora11g/users01.dbf: No such file or directory

확인: 그런 테이블스페이스는 없다고 나온다.

 

(alert log 는 전혀 감지를 못하는 채로 있다...

인고의 시간... 대체 언제 감지하는 거야...)

 

7. 테이블 새로 하나 또 생성해보기

 

SYS@ora11g> create table hr.emp_old tablespace users as select * from hr.employees;
Table created.

테이블 생성하고

 

SYS@ora11g> select count(*) from hr.emp_old;

  COUNT(*)
----------
       107

 

테이블 확인해보기

 

(alert log 는 아직도 잠잠하다.)

 

alert log 정보 (드디어 뜸 ㅠㅠ)

###############################################################################

Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_m000_12401.trc:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/u01/app/oracle/oradata/ora11g/users01.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

Wed Jan 24 11:00:27 2024
Checker run found 1 new persistent data failures

###############################################################################

빨리도 감지해 주네... ㅠㅠ 심지어 시간도 저 시간대도 아니야... 훨씬 오래 전이라고...

 

8. RMAN 으로 들어가기

 

SYS@ora11g> !

OS 로 나가서

 

[oracle@oracle ~]$ rman target /

RMAN 켜기

 

9. RMAN 에게 failure 체크해달라고 하기

 

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
128        HIGH     OPEN      24-JAN-24     One or more non-system datafiles are missing
102        HIGH     OPEN      08-JAN-24     One or more non-system datafiles are offline

 

아래는 옛날 거, 위에 나온 게 지금 발생한 failure

 

RMAN> list failure 128 detail;

failure 번호 128번의 내용 디테일하게 보기

 

결과 화면

#############################################################################

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
128        HIGH     OPEN      24-JAN-24     One or more non-system datafiles are missing
  Impact: See impact for individual child failures
  List of child failures for parent failure ID 128
  Failure ID Priority Status    Time Detected Summary
  ---------- -------- --------- ------------- -------
  9325       HIGH     OPEN      24-JAN-24     Datafile 4: '/u01/app/oracle/oradata/ora11g/users01.dbf' is missing
    Impact: Some objects in tablespace USERS might be unavailable

#############################################################################

데이터파일 (파일 번호 4번) 이 깨졌다고 나온다.

 

alert log 에도 같은 내용이 쓰여져 있다.

 

alert log 내용

#############################################################################

Wed Jan 24 11:04:06 2024
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_m000_32702.trc:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/u01/app/oracle/oradata/ora11g/users01.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

#############################################################################

 

10. 백업본 찾아보기

 

RMAN> list backup;

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1       Full    1.26G      DISK        00:00:56     24-JAN-24
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20240124T102114
        Piece Name: /u01/app/oracle/fast_recovery_area/ORA11G/backupset/2024_01_24/o1_mf_nnndf_TAG20240124T102114_lv0sjc3c_.bkp
  List of Datafiles in backup set 1
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 2079021    24-JAN-24 /u01/app/oracle/oradata/ora11g/system01.dbf
  2       Full 2079021    24-JAN-24 /u01/app/oracle/oradata/ora11g/sysaux01.dbf
  4       Full 2079021    24-JAN-24 /u01/app/oracle/oradata/ora11g/users01.dbf
  5       Full 2079021    24-JAN-24 /u01/app/oracle/oradata/ora11g/example01.dbf
  6       Full 2079021    24-JAN-24 /u01/app/oracle/oradata/ora11g/undotbs01.dbf

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
2       Full    9.48M      DISK        00:00:01     24-JAN-24
        BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20240124T102220
        Piece Name: /u01/app/oracle/fast_recovery_area/ORA11G/autobackup/2024_01_24/o1_mf_s_1159093340_lv0slfbg_.bkp
  SPFILE Included: Modification time: 23-JAN-24
  SPFILE db_unique_name: ORA11G
  Control File Included: Ckp SCN: 2079062      Ckp time: 24-JAN-24

 

11. 문제되는 테이블스페이스 오프라인으로 떨어뜨리기

 

RMAN> sql 'alter tablespace users offline immediate';

sql statement: alter tablespace users offline immediate

 

12. 리스토어

 

RMAN> restore tablespace users;

 

유저가 직접 리스토어했을 때와는 달리

RMAN 은 가장 최근의 백업본도 알아서 찾아주고, 부어넣기도 다 지가 알아서 해준다. (스마트하네!)

 

Starting restore at 24-JAN-24
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=28 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/ora11g/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORA11G/backupset/2024_01_24/o1_mf_nnndf_TAG20240124T102114_lv0sjc3c_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORA11G/backupset/2024_01_24/o1_mf_nnndf_TAG20240124T102114_lv0sjc3c_.bkp tag=TAG20240124T102114
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 24-JAN-24

 

13. 리커버

 

RMAN> recover tablespace users;

 

Starting recover at 24-JAN-24
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 15 is already on disk as file /home/oracle/arch1/arch_1_15_1158423268.arc
archived log for thread 1 with sequence 16 is already on disk as file /home/oracle/arch1/arch_1_16_1158423268.arc
archived log for thread 1 with sequence 17 is already on disk as file /home/oracle/arch1/arch_1_17_1158423268.arc
archived log file name=/home/oracle/arch1/arch_1_15_1158423268.arc thread=1 sequence=15
media recovery complete, elapsed time: 00:00:00
Finished recover at 24-JAN-24

 

와... 옵션 고를 필요도 없이 지가 알아서 리커버리도 다해주네... ♡

스마트해... >.<

 

14. 테이블스페이스 온라인으로 올리기

 

RMAN> sql 'alter tablespace users online';
sql statement: alter tablespace users online

 

15. failure 목록들 확인해보기

 

RMAN> list failure;

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
102        HIGH     OPEN      08-JAN-24     One or more non-system datafiles are offline

 

아까는 102번과 124번 이렇게 2개가 나왔었는데

지금은 124번 failure 가 사라져 있다.

 

16. RMAN 에서 나가기

 

RMAN> exit

Recovery Manager complete.

 

17. 여러 가지 확인 작업

 

17-1. 있어야 할 위치에 데이터파일들이 있는지 확인해보기

 

[oracle@oracle ~]$ cd /u01/app/oracle/fast_recovery_area
[oracle@oracle fast_recovery_area]$ ls
ora11g  ORA11G
[oracle@oracle fast_recovery_area]$ cd ORA11G
[oracle@oracle ORA11G]$ ls
archivelog  autobackup  backupset  onlinelog
[oracle@oracle ORA11G]$ cd autobackup
[oracle@oracle autobackup]$ ls
2024_01_24
[oracle@oracle autobackup]$ cd 2024_01_24
[oracle@oracle 2024_01_24]$ ls
o1_mf_s_1159093340_lv0slfbg_.bkp

 

(QUESTION. 근데 저 이름 긴 파일은 뭐하는 파일이야? 설마 백업파일?

근데 왜 YYYYMMDD 가 안 표시되어 있어?)

(ANSWER. 야 그만 질문해... 1교시에 답변 있어... 그리고 만치에가 그러는데 파일명은 바꾸면 그만이래)

 

17-2. 데이터파일 상태 확인해보기

select file#, name, status from v$datafile;

 

 

17-3. 테이블 확인해보기

 

SYS@ora11g> select count(*) from hr.loc_new;

  COUNT(*)
----------
       107

 

테이블 조회해보기 1

조회되네!

 

SYS@ora11g> select count(*) from hr.emp_old;

  COUNT(*)
----------
       107

 

테이블 조회해보기 2

이것도 조회되네! 완벽 복구됐고만? ♡

역시 RMAN 은 스마트해...♡

 

만치에가 질문 도와줌 ㅠㅠ

고마워요 만치에!