Resetlogs 이전 backup을 이용하여 resetlogs 이후 database 상태로 recovery
------------------------------------------------------------------------

database를 resetlogs option으로 open하게 되면 control file과 data file
header를 변화시키고 online redo log의 모든 redo entry를 무효화시키게
된다. 그래서 resetlogs 이전 시점의 backup을 가지고 현재 상태까지, 또는
resetlogs 이후의 어느 시점까지도 복구가 불가능하여, resetlogs로
database가 open된 이후에는 즉시 db를 full backup받도록 권장된다.

그러나 resetlogs로 open한 후, 즉시 full backup을 받지 못하고 database
를 사용하다가, 다시 fail이 발생하여 현재 시점까지의 복구가 필요한
경우가 있다. 이 문서에서는 그러한 경우, 즉, resetlogs 이전 시점의
backup을 가지고도 resetlogs 이후 시점의 database로의 복구 방법을 설명
한다. 이것은 Oracle7 7.3.3 이상에서만 가능하다.

1. resetlogs가 필요한 경우와 복구를 위한 조건

database를 resetlogs로 open이 필요한 경우는 다음과 같은 경우가 있다.
- incomplete recovery
- using backup control file option을 사용하는 경우
- create control file ... resetlogs 문장을 수행한 경우

이 문서에 설명할 recovery 방법을 사용하게 되는 전제 조건은 다음과
같이 정리할 수 있다.
(1) Oracle version은 7.3.3 이상이다.
(2) resetlogs 수행 이후에는 cold나 hot backup이 존재하지 않는다.
(3) resetlogs 수행 이전의 cold나 hot backup이 존재한다.
(4) resetlogs 수행 이후의 control file은 존재한다.
(5) 현재 시점까지 혹은 recovery하고자 하는 시점까지의 모든 archive
file은 존재한다.


2. recovery 방법

아래와 같은 상황에서 C 시점에서 database crash가 발생한 것을 가정하자.
A B C
-----------|-----------------------|---------------------|----------
datafile과 control file의 resetlogs 수행 현재의 database
backup

먼저 간단히 복구 작업을 설명하면 다음과 같다.

(1) 현재의 control file을 backup을 받아 둔다.
B시점 이후의 control file이면 된다.

(2) resetlogs가 수행되기 이전 즉, A 시점의 datafile과 control file을
restore시킨다. online redo log와 read only datafile은 현재 것을
그대로 둔다.

(3) startup mount

(4) recover database until change
using backup controlfile;
여기에서 resetlogs 직전의 change number는 alertSID.log file에
아래와 같이 명확히 나타난다.

RESETLOGS after incomplete recovery UNTIL CHANGE 5847568231282

(5) shutdown (normal)

(6) 1번 STEP에서 backup받아 둔 현재의 control file을 restore시킨다.
현재, 즉 C시점의 control file이 없는 경우 B와 C시점 사이에 backup
받아 둔 control file을 사용하여도 되며, 그 경우에는 아래의 8번
step에서 using backup controlfile을 첨가하여야 한다.

(7) startup mount;

(8) recover database;
이 때 complete recovery 뿐 아니라 B와 C시점 사이로의 incomplete
recovery도 가능하며, B와 C 사이 시점의 backup controlfile을
이용한 recovery도 가능하다

(9) alter database open;
8번 STEP에서 incomplete나 using bakcup controlfile을 사용한
경우에는 open resetlogs를 하여야 한다.


3. 실제 recovery test 예
실제 test한 예를 정리하면 다음과 같다.

(1) database를 cold backup이나 hot backup을 받는다.
cold backup의 경우에는 datafile, redo log file, control file을,
hot backup의 경우에는 datafile과 control file을 받는다.

(2) db에 batch 작업을 수행하여 archive file이 150 ~ 154번까지
생성되었다.

(3) db crash 경우를 만들기 위해 shutdown abort로 db를 shutdown시킨다.

(4) 1번에서 backup받은 datafile과 control file을 restore한다.
이 때 control file은 restore하지 않아도 된다.

(5) resetlogs로 open할 수 있도록 incomplete recovery나 using backup
controlfile을 사용한다. 이 예에서는 두가지를 모두 사용하였다.
SVRMGR> startup mount
SVRMGR> recover database until cancel using backup controlfile;
SVRMGR> alter database open resetlogs;

(6) 이 때 background_dump_dest의 alertSID.log를 확인해 보면 아래와 같은
message를 확인할 수 있다.

alter database open resetlogs
Wed Nov 3 20:04:30 1999
RESETLOGS after incomplete recovery UNTIL CHANGE 5847568231282

(7) database에 batch 작업을 수행하여 arch1.log ~ arch4.log 화일이
생성되는 것을 확인하였다.

(8) database를 shutdown abort한다.

(9) 현재의 control file을 backup받아둔다.

(10) 1번에서 backup받은 datafile과 control file을 restore한다.
이 때는 5 번과는 달리 반드시 control file을 backup받은 것을
restore하여야 한다.

(11) 다음과 같이 recover한다. 이 때 change number는 7번에서 확인한
번호를 기술한다.
SVRMGR> startup mount;
SVRMGR> recover database until change 5847568231282 using backup
controlfile;

(12) shutdown (normal) 시킨다.

(13) 9번에서 backup받아 두었던 현재의 control file을 restore시킨다.

(14) 다음과 같이 resetlogs 이후 시점을 recovery한다. 이 때 incomplete
recovery도 가능하다.

SVRMGR> startup mount;
SVRMGR> recover database;
SVRMGR> alter database open;


4. 결론

위의 내용을 실제 test해 보면 resetlogs 이후의 시점의 control file이
반드시 필요한 것을 제외하고는 특별히 요구되는 사항이나 복잡한 과정은
필요하지 않다. 그러나 이것은 resetlogs 이후에 backup을 받아두지 않아도
되는 것을 의미하는 것은 아니고, 만일의 경우 backup전 에 발생할 crash를
대비한 복구 방법을 알려주는 것 뿐이다.
위의 내용을 살펴보면 아래 정리한 것과 같은 습관이 필요함을 알 수
있다.

(1) resetlogs 후에는 바로 control file을 backup을 받는다.
(2) resetlogs로 open하기 전에 archive와 online log를 backup 받는다.
resetlogs로 open 후에 log sequence number가 변경되므로 기존의
archive file과 같은 이름으로 archive file이 생성되어 overwrite하는
경우가 발생할 수 있다.
(3) resetlogs 후의 change number를 기록해 둔다.
resetlogs 시점의 change number는 항상 alertSID.log file에 기록되지만
user가 alertSID.log 화일의 과거의 내용을 지우게 되면 change number를
확인할 수 없게 된다.