불완전 복구 - DDL 관련 장애복구(2-2)_ drop table->drop tablespace 명령으로 삭제된 table복구.

불완전 복구 - DDL 관련 장애복구(2-2) 

- drop table->drop tablespace명령으로 삭제된 table 복구. (backup file 있을경우.)

 

[ 백 업 하 기 & 장 애 발 생 ]

1. test2 tablespace 생성.[A]

 

2.db 끄고, 전체 닫힌 백업을 받는다.[B]

 

3. db를 open후, test2 tablespace에 table을 생성해서 값을 입력한다.[C] ->현재리눅스 시간을 조회한다.

 

4. table을 drop한다. [D]**-> D단계로 복구하기로 한다.

 

5. tablespace를 drop한다.

 

[ 해 결 ]

1. db를 종료 후 임시 복구 경로로 필요한 파일을 복사하는데, tablespace를 drop한 경우 복구할 때 주의할 점이 있다.

-> drop table 하기 전 단계로 가는 거지만, drop tablespace도 했으므로, drop tablespace를 했을 경우의 복구 방법을 사용해야 한다.

* recover 명령을 수행하면, control file에 있는 data file과 redo log file의 정보를 보고 복구를 한다. 그런데 drop tablespace 명령어의 경우에는 control file에서 해당 data file을 삭제하므로, drop 한 이후의 control file에는  test tablespace에 대한 정보가 없기 때문에 recover 할 때, 복구 대상에서 test tablespace는 빠지게 된다. 그래서 control file은 이전에 백업한 파일을 사용해서 복구한다.

 

 

 

2. control file의 경로를 변경한다.

 

3. db를 mount로 open후, control file의 변경내용을 조회한다.

 

4. data file의 경로를 변경한다. _아래와 같이 나머지도 동일하게 변경해준다.

 

5. redo log file의 경로를 변경한다.

 

6. drop table 하기 전에 시간을 조회했으므로, 그 시간대로 recover 해주는데, tablespace도 drop됐으므로 using backup controlfile 옵션도 사용해야 한다.

-> drop tablespace의 경우 control file도 backup파일에서 복사해오게 되면, control file과  data file의 SCN이 같게 되므로 recover할 때 두 번호가 같아서 recover를 아예 하지 않게 된다. 그래서 'control file을 새로 만들거나, control file이 백업본일 경우' using backup controlfile 옵션을 이용해서 SCN번호를 무시하고 recover를 계속 진행하도록 한다.

-> recover database until time '시간' using backup controlfile;

-> recover 명령을 내렸을 때 에러와 함께 sequence 번호가 뜨는데, 이 번호는 해당 번호의 archive log file을 찾는데 저 파일이 없어서 에러가 나오는 것이다.  새 터미널창으로 redo log의 상태를 조회하여 해당 sequence 번호의 경로를 입력해준다.

- 새 터미널 창을 하나 더 열어서 redo log의 상태를 조회해서 위에서 본 sequence 번호에 해당하는 redo log file의 경로 확인.

 

7. resetlogs 옵션을 이용해 db를 open한 후, 해당 tablespace가 복구되어있는지 조회한다.