2024년 1월 10일 3교시 시나리오 7. 시스템 데이터파일 손상 + 백업본 O + 리두 X

백업과 언두, 리두는 늘 모니터링하는 습관을 들이도록 하자.

 

★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ 시나리오 7 ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★

시나리오 7 = system tablespace에 속한 데이터 파일 삭제 (백업 이후에 리두 정보가 없을 경우)

 

1. 준비 작업

 

SQL> select * from v$log;

리두로그 정보 확인

 

 

SQL> alter system switch logfile;

로그 스위치 발생시켜서 커런트한 리두 정보 없애버리기

 

/

/

 

SQL> select * from v$log;

리두로그 정보 다시 확인해보기

 

 

2. 시스템 데이터파일 깨뜨려서 장애 유발하기

 

SQL> ! rm /u01/app/oracle/oradata/ora11g/system01.dbf

SQL> ! ls /u01/app/oracle/oradata/ora11g/system01.dbf

 

(중간중간 alert log file 도 확인해주기,

지금은 alert log file 이 전혀 반응이 없는데

이건 alert log file 이 무슨 일이 일어났는지 감지를 못해서 그런 것)

(이야... 나무늘보 이때도 여전했었네...)

 

SQL> alter system checkpoint;

체크포인트 유발시키기

원래는 체크포인트를 유발시키는 순간 DB 가 딱 끊어져야 정상인데

가끔 아무 일도 안일어날 때도 있다.

(뭐...? '가끔'? '가' '끔'?)

 

/

/

 

3. DB 내리기

 

SQL> shutdown immediate

아무리 기다려도 DB 가 안내려와서 수동으로 DB 내림.

그런데 DB가 정상적으로 내려진다...? 시스템 데이터파일이 깨졌는데도?

가끔은 이렇게 오라클이 시스템 테이블스페이스가 깨진 걸 감지를 못할 때도 있다.

 

(아까 수업 중에는 정상적으로 내려갔지만

복습하는 지금은 오류 발생함)

(그리고 가끔은 무슨 가끔... 맨날 그러잖아...)

 

 

SQL> select status from v$instance;

DB 내리고 DB 의 인스턴스 상태를 한번 봐보면:

STATUS
------------
OPEN

 

오픈 상태라고 나온다.

(???

갈수록 태산이네...)

 

SQL> shutdown abort
ORACLE instance shut down.

(immediate 가 안먹히므로 abort 로 끔)

 

아무튼 shutdown immediate 든 shutdown abort 든 DB 내리고

 

4. 다시 DB 올리기

 

SQL> startup

시스템 데이터파일이 없으므로 DB 가 마운트 단계까지만 올라오고 그 이상으로는 올라오지 못한다.

 

SQL> select status from v$instance;

STATUS
------------
MOUNTED

 

5. 원본 위치에 백업본 부어넣기

 

SQL> !

[oracle@oracle ~]$ cp -av backup/noarch/20240110/system01.dbf /u01/app/oracle/oradata/ora11g/

백업본으로 시스템 데이터파일 복구

 

(QUESTION. 근데 이렇게 하면 원래 위치 /u01/app/oracle/oradata/ora11g/에 있는 system01.dbf 파일은

backup/noarch/20240110/system01.dbf 에서 가져온 파일로 덮어씌워지게 돼?

그럼 원본 파일은 사라지고 cp 해온 파일이 원본 파일이 되는 거지?)

(ANSWER. 복사하는 자리에 이름이 같은 파일이 있으면 덮어씌워짐,

없으면 신규 생성)

 

 

그렇지만 저 파일은 말 그대로 백업본을 부어넣은 것일 뿐, 다른 파일들과 싱크가 맞지 않으므로

싱크를 맞춰주는 작업을 해야 한다.

 

6. 시스템 데이터파일 백업본에 리두 부어넣기 system datafile backup restore

(그런데 아까 커런트 리두 그룹을 날려 놨었잖아... 리두로 리커버리가 될 리가 없지...)

 

[oracle@oracle ~]$ exit

 

SQL> recover database;

수행하는 순간 오류 발생

 

ORA-00279: change 1701890 generated at 01/10/2024 11:40:38 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/ORA11G/archivelog/2024_01_10/o1_mf_1_36_%u_.a
rc      ← archive log mode 에서 생성되는 파일인데 우리는 지금 노아카이브 로그 모드야... 그런 게 있을 리가 없잖아...

              그래서 복구 못함.
ORA-00280: change 1701890 for thread 1 is in sequence #36

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

 

복구 어떡할 거냐고 하면서 옵션 여러개가 나오는데 그 중에서

알아서 해달라고 auto 고르면

 

 

auto
ORA-00308: cannot open archived log
'/u01/app/oracle/fast_recovery_area/ORA11G/archivelog/2024_01_10/o1_mf_1_36_%u_.
arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

마지막 백업 이후의 변경 이력정보가 없어서 완전 복구에 실패하게 된다.

 

 

그래서...

 

7. 불완전 복구 : 콜드 백업본 전체를 원본 위치에 부어넣기

 

7-1. DB 내리기

 

SQL> shutdown abort

멀쩡한 복구가 불가능하므로 또 강제로 끄기

 

 

7-2. 모든 데이터 파일, 컨트롤 파일, 리두 파일 리스토어 작업하기

 

[oracle@oracle ~] $ cp -av backup/noarch/20240110/*.* /u01/app/oracle/oradata/ora11g/

백업 파일들이 있는 위치에 있는 모든 파일을 원본 파일 위치로 복구

(백업본을 원본 위치로 부어넣었으므로 DB 는 과거 시간, 즉 백업 시점 시간으로 되돌아갈 수밖에 없다)

 

 

 

7-3. DB 올리기

 

SQL> startup

 

이렇게 하면 DB 가 과거 시간으로 되돌아가게 된다.

마지막 백업받아놓은 시점 이후의 변경 이력 정보들 없으므로 완전 복구 불가능!

 

- 완전 복구가 실패했을 경우 불완전한 복구 방식을 수행한다.

- 모든 데이터파일, 컨트롤파일, 리두로그 파일, 템프 파일의 콜드 백업본을 원본 위치로 부어넣어야 한다.

 

SQL> select * from v$log;

리두로그 정보 확인

 

 

SQL>
select name, checkpoint_change#, status from v$datafile;

체크포인트 정보 확인하기: 싱크는 당연히 다 맞춰져 있다.

(콜드 백업본을 부어넣은 것이니 당연하겠지...)

 

 

SQL> select current_scn from v$database;

current 한 SCN 번호 확인하기

 

 

콜드 백업본의 데이터파일들 SCN 번호는 1701893번인데

커런트 SCN 번호는 1707109 번... 이야... 이거는 못 메꾸지...