2024년 1월 10일 2교시 시나리오 6. 시스템 데이터파일 손상 + 백업본 O + 백업 이후 리두 O / 콜드 백업 실습

★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ 시나리오 6 ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★

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

 

콜드 백업부터 먼저 받자.

 

1. 백업받을 파일들 확인하기

select name from v$datafile;

데이터파일들 확인하기:

 

/u01/app/oracle/oradata/ora11g/system01.dbf
/u01/app/oracle/oradata/ora11g/sysaux01.dbf
/u01/app/oracle/oradata/ora11g/users01.dbf
/u01/app/oracle/oradata/ora11g/example01.dbf
/u01/app/oracle/oradata/ora11g/undotbs01.dbf

 

select name from v$controlfile;

컨트롤파일들 확인하기:

 

/u01/app/oracle/oradata/ora11g/control01.ctl

 

select name from v$tempfile;

temp 파일 확인하기:

 

/u01/app/oracle/oradata/ora11g/temp01.dbf

 

select member from v$logfile;

리두로그 파일 확인하기:

 

/u01/app/oracle/oradata/ora11g/redo01.log
/u01/app/oracle/oradata/ora11g/redo02.log
/u01/app/oracle/oradata/ora11g/redo03.log

 

2. 백업 명령어 모양 만들기

 

select 'cp -av ' || name || ' /home/oracle/backup/noarch/20240110/' from v$datafile union all

select 'cp -av ' || name || ' /home/oracle/backup/noarch/20240110/' from v$controlfile union all

select 'cp -av ' || name || ' /home/oracle/backup/noarch/20240110/' from v$tempfile union all

select 'cp -av ' || member || ' /home/oracle/backup/noarch/20240110/' from v$logfile;

 

얘네를 SQLD (102) 에서 수행하고

 

 

cp -av /u01/app/oracle/oradata/ora11g/system01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/sysaux01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/users01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/example01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/undotbs01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/control01.ctl /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/temp01.dbf /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/redo01.log /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/redo02.log /home/oracle/backup/noarch/20240110/
cp -av /u01/app/oracle/oradata/ora11g/redo03.log /home/oracle/backup/noarch/20240110/

 

나오는 결과들을 복사한 다음

(-av 와 / 사이가 한 칸 떨어져 있어야 수행했을 때 오류가 발생하지 않는다)

 

3. DB 내리고

SQL> shutdown immediate

 

 

4. OS 에서 백업용 디렉토리로 들어가서

cd /home/oracle/backup/noarch/20240110/

 

 

[oracle@oracle 20240110]$ rm *.*

기존 백업파일들 삭제하고 백업 다시 받기

 

 

5. 백업용 파일 만들기

[oracle@oracle 20240110]$ vi backup.sh

vi 편집기로 파일 열어서 sqld 에서 수행한 결과 행들 복사한 다음 파일에 붙여넣고 저장하기

 

이거 절대 원본파일이 있는 위치에서 하면 안되고

백업파일 저장해놓은 디렉토리에서 해야 한다.

 

(Question.  근데 이거 뭐한거야?)

(ANSWER. 우리는 테스트라서 주소가 똑같고 실제로는 파일들의 물리적 주소가 다 다를 텐데

한 번에 취합하기 위해서 위의 방법을 쓴 것)

(와.. 나무야... 너 이런 걸 질문이라고 하다니!)

 

6. 만들어놓은 셸 파일 돌려서 콜드 백업받기

[oracle@oracle 20240110]$ sh backup.sh > backup.log

sh backup.sh > backup.log

만들어놓은 쉘 프로그램을 수행 + 실행 기록을 backup.log 라는 임의의 파일을 만들어서 그 안에 저장

(저 쉘 프로그램을 수행하면: 원본 위치에 있는 파일들이 백업 위치로 옮겨지게 된다.

즉, 원본 파일들이 백업 위치로 지정해놓은 위치에 백업되는 것)

 

(QUESTION. > 는 뭐고 >> 는 뭐였더라?...)

(ANSWER. > 는 > 뒤에 나오는 파일에 쓰기 / write or overwrite,

>> 는 뒤에 나오는 파일에 추가 / append)

화면에는 나오지 않지만 리다이렉션이 수행된다.

 

(QUESTION. backup.log 는 뭐야?)

(ANSWER. 얘는 방금 만든 놈이야... 셸 파일의 내용 저장하려고...)

(QUESTION. 그리고 왜 셸 파일의 내용을 backup.log 에다 썼어?)

(ANSWER. 셸 파일은 돌려도 실행기록이 안남기 때문에
저 backup.log 라는 임의의 파일을 만들어서 기록을 저장한 것)

 

[oracle@oracle 20240110]$ ls

폴더에 파일이 생성되었는지 확인: 잘 만들어져 있다.

backup.log     example01.dbf  redo03.log    temp01.dbf
backup.sh      redo01.log     sysaux01.dbf  undotbs01.dbf
control01.ctl  redo02.log     system01.dbf  users01.dbf

 

[oracle@oracle 20240110]$ cat backup.log

 

(QUESTION. 이거 뭐한거야?

백업로그의 내용을 읽은 것 같긴 한데 맞아?

(ANSWER. 맞아!)

(QUESTION. 근데 보니까 /u01/app/oracle/oradata/ora11g/에 있는 파일들이 다 백업 위치 20240110 으로 옮겨져 있네?

그런데 왜 cp 명령어는 없어?)

(ANSWER. 얘는 실행 기록만 저장한 거니까... cp 명령어가 보고 싶으면 vi 해서 셸 파일을 열어...)

 

 

 

셸 파일과 로그 파일 지우기

[oracle@oracle 20240110]$ rm backup.*

 

(QUESTION. 이건 뭐한거야?... 나 모르겠어...
.* 은 확장자고 backup 은 확장자 앞의 파일명인가?
그럼 결국 20240110 디렉토리에 있는 백업파일들 다 날려버린 건가?)

(ANSWER. 셸 프로그램과 backup.log 모두 지운 것,

파일 이름은 backup 이고 확장자는 * 모든 확장자인 것들 다 지워버린 것

결국 backup.sh 파일과 backup.log 파일 이렇게 파일 이름이 backup 인 2개의 파일이 지워짐)

 

 

(옵션) 백업파일을 원본 위치에 부어넣기

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

마지막 DB 내리기 전 시점으로 리스토어

 

(QUESTION. 근데 이걸 왜한거야? 아까 셸 파일 이용해서 백업한 거 아냐?

근데 왜 리스토어해...? 힘들게 해놓고?)

(ANSWER. 셸 파일은 원본 자료를 새로운 폴더 20240110 에 백업한 거고

이 작업은 백업파일 위치에 있는 백업파일들을 원본 파일 자리로 복구 시도한 거야...)

 

[oracle@oracle 20240110]$ exit
다시 SQL+ 로 가서

 

7. DB 올리기

SQL> startup

DB 가 정상적으로올라오면 백업본에 아무 문제도 없는 것 (당연하겠지!)

 

 

SQL> select current_scn from v$database;

커런트한 SCN 번호 확인하기

 

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

DB 에 마지막 체크포인트가 발생했을 때의 SCN 번호 확인

 

 

(col name format a50)

 

SQL> select * from v$log;

리두로그 정보 확인하기

 

 

DB 가 정상적으로 떠 있는지, 백업본이 있는지 시나리오 돌려보기 전에 꼭 확인하자.

 

(QUESTION. 응? 아니 잠깐만...

이제서야 시나리오 6을 시작한다고?

그럼 지금까지 뭐한거야?... 위에 했던 작업들은 다 뭐야?)

(ANSWER. 그냥 여러 가지 백업시나리오 보여주신 듯)

 

(와... 나무야... 나 복습중인데 이런 걸 지금까지 질문이라고 하고 다녔단 말야?

나 진짜 친구들한테 얼굴을 못 들겠어...)

 

★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ 시나리오 6 ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★

system tablespace에 속한 데이터 파일 삭제 (백업 이후에 리두 정보가 있을 경우)

 

SQL> select current_scn from v$database;

커런트한 SCN 번호 확인하기

 

 

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

DB 에 마지막 체크포인트가 발생했을 때의 SCN 번호 확인: 1701893

 

 

SQL>

select * from v$log;

로그 정보 확인

(이거 로그 정보 어쨌니... 너...)

 

1. 시스템 테이블스페이스에 속한 데이터파일을 깨뜨려서 장애를 유발시켜 보자.

 

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

 

음... 그런데 alert log file는 이 사태를 아는지 모르는지 꿈쩍도 안하네...?

모르니까 꿈쩍도 안 하겠지. 그럼 친절하게 알려줘야지...

 

SQL> alter system checkpoint;

인위적으로 체크포인트를 유발시키면: 있어야 하는 위치에 시스템 테이블스페이스가 없으므로 에러가 발생한다.

그리고 DB 는 불완전하게 내려가게 된다.

 

(QUESTION. 이건 지가 저절로 불완전하게 내려간 거야?

난 내리지 않았는데?...)

(ANSWER. 메인 파일을 지워버림으로써

지울 때는 아무 일이 일어나지 않지만 체크포인트가 발생하면서 강제로 DB가 종료된 것)

 

그렇지만 유저는 당연히 DB 가 떠있을 것이라 생각하고

 

SQL> select status from v$instance;

DB 상태 확인하는 명령어를 던지면: not connected 되어 있다고 나온다.

 

 

SQL> startup

그래서 DB 를 올리려고 하면: 오류가 발생함.

음... 근데 시스템 데이터파일이 없는 게 크리티컬한 장애가 맞긴 하지만

그래도 마운트 단계까지는 올라와야 정상인데...?

 

혹시나 하는 마음으로 sysdba 로 다시 접속해보기

SQL> conn / as sysdba

Connected to an idle instance.

다시 접속하기: instance 가 idle 되었다는 메시지가 나옴.

 

 

 

 

2. DB 올려보기: 마운트 단계까지는 올라온다.

SQL> startup

 

 

SQL> select status from v$instance;

DB 가 어느 단계까지 올라와 있는지 확인해보기

 

 

SQL> select name, status from v$datafile;

데이터파일의 이름과 상태를 확인해보면:

시스템 테이블스페이스는 system 이라고 나온다.

얘는 절대 offline 모드로 떨어뜨릴 수 없기 때문에 DB 를 내려야만 한다.

 

 

3. 백업본으로 시스템 데이터파일 복구하기

 

SQL> !

OS 로 나가서

[oracle@oracle ora11g]$ cd /home/oracle/backup/noarch/20240110

백업 디렉토리로 가서

 

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

백업 위치에 있는 시스템 데이터파일만 원본 위치로 복구하기

 

 

[oracle@oracle 20240110]$ ls /u01/app/oracle/oradata/ora11g/system01.dbf
/u01/app/oracle/oradata/ora11g/system01.dbf

원본 위치에 파일이 잘 들어갔는지 확인하기

 

 

4. 원본 위치에 파일은 생겼지만 저건 백업본을 부어넣은 것일 뿐,

다른 파일들과의 싱크가 맞지 않으므로 해당 파일에 리두 부어넣어주기

 

SQL> recover tablespace system;

손상된 데이터파일 이름을 알 경우에는 이렇게 리커버해도 되고

 

SQL> recover database;

모를 경우에는 이렇게.

 

Media recovery complete.

리두를 이용한 복구까지 다 완료되었다고 나온다.

(recover = 마지막 백업 시점 이후의 변경 이력 정보를 리두로그 파일에서 찾아서 복구 작업하는 것,

백업 시점의 마지막 체크포인트 SCN 번호를 보고 복구작업을 한다.

 

5. 리커버리 완료되면: DB 열기

 

SQL> alter database open;

Database altered.

 

6. 그 외

 

SQL> select * from v$log;

리두로그 정보 확인

 

 

SQL> select name, status from v$datafile;

데이터파일의 이름과 상태 보기

 

 

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

현재 데이터 파일 헤더에 있는 체크포인트 정보 확인하기

SCN 번호가 모두 일치하는지 확인