장애의 종류
1. 물리적 장애 : File 자체의 장애
2. 논리적 장애 : 사용자 실수로 발생되는 장애( ex; 지워서 안되는 table삭제, DDL, DML )
복구 원리
(상황가정 : SCN# 100일때 백업을 받았음, 쭉 운영하다가 SCN# 108때 ts_a01.dbf 파일장애,
log file group 3개 존재--> logfile 에 106,107,108에 해당되는 작업이 저장되어있겠죠!)
1. SCN# 100일때 받아놓은 백업본을 DB에 복사해옴(RESTORE 작업)
2. 복구시도 (사용한 명령어 : recover datafile '/home/oracle/data/ts_a01.dbf';)
위 명령어를 사용하면 Server process는 control file을 찾아서,
control file내의 datafile의 CNT#와 datafile안의 header에 있는 CNT#를 비교하고,
그 후, datafile내의 header의 stop SCN#와 controlfile의 checkpoint SCN#를 비교하게 됩니다.
3.
여기서 가정한 상황에서는 control file의 SCN은 108, datafile의 SCN은 100이기 때문에, 101~108까지가 없다는 것을 확인했습니다.
101~108에 작업한 파일을 Archive log file이나 Log file에서 찾아서, ts_a01.dbf에 적용하고, 복구를 마무리합니다.
* Archive log mode 에서는 101~105에 해당하는 자료들이 저장되어 있어서, 이 상황에서는 복구가 가능합니다.
* Noarchive log mode에서는 101~105에 해당하는 자료들이 이미 log switch할 때 덮어쓰여저 버려서 복구가 불가능합니다.
(백업을 SCN# 105에 받았었다면, Noarchive log mode라도 복구가 가능합니다.)
복구시 사용하는 명령어들
1. recover database;
---> database전체를 복구시도, 복구시 database가 변하므로 OPEN상태에서는 사용불가, MOUNT에서만 가능
2. recover tablespace name;
---> tablespace를 복구시도, 해당 tablespace만 offline되면 OPEN에서 가능, MOUNT에서도 가능
(OPEN에서 offline이 안되는 tablespace : SYSTEM, UNDO, Default TEMPORARY TBS)
3. recover datafile '____';
---> 해당 datafile을 복구시도, 해당 datafile만 offline되면 OPEN에서 가능, MOUNT에서도 가능
* 장애
데이터 파일에 장애가 나버리고, 그 데이터파일을 어떠한 이유들 때문에 복구를 못하게되면 해당 DB는 OPEN되지 않습니다.
이럴 경우, 장애가 난 데이터파일을 포기하고, 어떻게든 DB를 open시키고 싶을 땐 아래 명령어를 MOUNT에서 수행하면 됩니다.
또한, 나중에 복구될 여지를 남겨놓기 위해서 v$datafile의 status부분을 조회하면, RECOVER이라고 표시가 됩니다.
(RECOVER이라고 표시되어 있으면 현재는 포기한 datafile))
장애유형 :
백업파일이 없고, 모든 Archive log file이 존재할 때 어떠한 datafile이 장애 시 복구
해결방법 : control file에 있는 장애가 있는 datafile정보를 불러와서 새 파일에 그 정보를 적용하고나서, Archive log file의 모든 작업을 새 파일에 적용하고 복구를 마무리 합니다.
복구의 시점에 따른 두가지 유형
1. 완전복구 (Complete Recovery) : 마지막 SCN#까지 모두 복구
2. 불완전복구 (Incomplete Recovery) : DBA가 원하는 시점까지만 복구(until time, until cancel, etc)
불완전 복구를 사용하는 이유 : 장애가 나서 하는 복구모다는, 실수로 drop한 table이나, users, tablespace등등을 살리기 위해서 원하는 시점까지만 database를 되돌리는 것입니다.
* 주의사항 : 원본DB에서 불완전복구를 사용해버리면, 원하는 자료는 살릴 수 있을지 몰라도 불완전복구가 된 시점~현재까지의 자료들은 없던 것이 되어버리므로,
1. cloneDB를 만들어서 자료들을 살리고 import하거나, ( http://gyh214.tistory.com/92 참고 )
2. 파일들을 새로 복사해서 alter database rename으로 원본DB는 건드리지 않고, 임시디렉토리에서 작업해야만 합니다.
1. 물리적 장애 : File 자체의 장애
2. 논리적 장애 : 사용자 실수로 발생되는 장애( ex; 지워서 안되는 table삭제, DDL, DML )
* 자료복구의 중요한 점은 No archivelog냐 Archivelog냐가 아니라,
복구하려는 데이터가 저장되어있느냐(logfile이든, archive file이든)가 중요
복구 원리
(상황가정 : SCN# 100일때 백업을 받았음, 쭉 운영하다가 SCN# 108때 ts_a01.dbf 파일장애,
log file group 3개 존재--> logfile 에 106,107,108에 해당되는 작업이 저장되어있겠죠!)
1. SCN# 100일때 받아놓은 백업본을 DB에 복사해옴(RESTORE 작업)
2. 복구시도 (사용한 명령어 : recover datafile '/home/oracle/data/ts_a01.dbf';)
위 명령어를 사용하면 Server process는 control file을 찾아서,
control file내의 datafile의 CNT#와 datafile안의 header에 있는 CNT#를 비교하고,
그 후, datafile내의 header의 stop SCN#와 controlfile의 checkpoint SCN#를 비교하게 됩니다.
3.
여기서 가정한 상황에서는 control file의 SCN은 108, datafile의 SCN은 100이기 때문에, 101~108까지가 없다는 것을 확인했습니다.
101~108에 작업한 파일을 Archive log file이나 Log file에서 찾아서, ts_a01.dbf에 적용하고, 복구를 마무리합니다.
* Archive log mode 에서는 101~105에 해당하는 자료들이 저장되어 있어서, 이 상황에서는 복구가 가능합니다.
* Noarchive log mode에서는 101~105에 해당하는 자료들이 이미 log switch할 때 덮어쓰여저 버려서 복구가 불가능합니다.
(백업을 SCN# 105에 받았었다면, Noarchive log mode라도 복구가 가능합니다.)
복구시 사용하는 명령어들
1. recover database;
---> database전체를 복구시도, 복구시 database가 변하므로 OPEN상태에서는 사용불가, MOUNT에서만 가능
2. recover tablespace name;
---> tablespace를 복구시도, 해당 tablespace만 offline되면 OPEN에서 가능, MOUNT에서도 가능
(OPEN에서 offline이 안되는 tablespace : SYSTEM, UNDO, Default TEMPORARY TBS)
3. recover datafile '____';
---> 해당 datafile을 복구시도, 해당 datafile만 offline되면 OPEN에서 가능, MOUNT에서도 가능
** 복구시 철칙 : 해당 file을 복구할 때는 무조건 그 파일을 안쓰게 해야합니다.(DML, DDL, 등등 모두), 복구시에는 control file을 참조하므로, NOMOUNT상태에서는 복구시도가 불가능
* 장애
데이터 파일에 장애가 나버리고, 그 데이터파일을 어떠한 이유들 때문에 복구를 못하게되면 해당 DB는 OPEN되지 않습니다.
이럴 경우, 장애가 난 데이터파일을 포기하고, 어떻게든 DB를 open시키고 싶을 땐 아래 명령어를 MOUNT에서 수행하면 됩니다.
alter database datafile '/home/oracle/disk1/ts_a01.dbf' offline drop;(위 명령어를 수행하면, control file안에 해당 datafile을 '사용안함'이라고 표시를 합니다., 해당 datafile삭제는 하지 않습니다.
또한, 나중에 복구될 여지를 남겨놓기 위해서 v$datafile의 status부분을 조회하면, RECOVER이라고 표시가 됩니다.
(RECOVER이라고 표시되어 있으면 현재는 포기한 datafile))
장애유형 :
백업파일이 없고, 모든 Archive log file이 존재할 때 어떠한 datafile이 장애 시 복구
해결방법 : control file에 있는 장애가 있는 datafile정보를 불러와서 새 파일에 그 정보를 적용하고나서, Archive log file의 모든 작업을 새 파일에 적용하고 복구를 마무리 합니다.
SQL> alter database create datafile '/home/oracle/data/ts_a01.dbf' 2 as '/temp/ts_a01.dbf'; <------ 새 파일에 정보를 예전 파일의 정보를 적용합니다.(control file이 변경되겠죠) -------------------------------------------------------------------- -------------------------------------------------------------------- SQL> recover datafile '/temp/ts_a01.dbf'; Media recovery complete
복구의 시점에 따른 두가지 유형
1. 완전복구 (Complete Recovery) : 마지막 SCN#까지 모두 복구
2. 불완전복구 (Incomplete Recovery) : DBA가 원하는 시점까지만 복구(until time, until cancel, etc)
불완전 복구를 사용하는 이유 : 장애가 나서 하는 복구모다는, 실수로 drop한 table이나, users, tablespace등등을 살리기 위해서 원하는 시점까지만 database를 되돌리는 것입니다.
* 주의사항 : 원본DB에서 불완전복구를 사용해버리면, 원하는 자료는 살릴 수 있을지 몰라도 불완전복구가 된 시점~현재까지의 자료들은 없던 것이 되어버리므로,
1. cloneDB를 만들어서 자료들을 살리고 import하거나, ( http://gyh214.tistory.com/92 참고 )
2. 파일들을 새로 복사해서 alter database rename으로 원본DB는 건드리지 않고, 임시디렉토리에서 작업해야만 합니다.