불완전복구는 완전복구와는 달리 현재 시점까지 모두 복구 가능한 것이 아니라, 과거의 장애나기 이전 특정 시점까지만 복구 가능하다.

완전복구에서는 장애난 데이터파일만 복원하여 recover 명령어로 복구를 하면 되는 식이었으나, 불완전복구는 장애난 데이터파일만 복원하지 않고 나머지 데이터파일 모두를 복원한다. 또한 리두로그와 컨트롤파일은 현재시점의 것을 사용해야 한다. 그래야 과거에서 현재 사이 중간의 정상이었던 시점까지 복구 가능하기 때문이다.

◆ 장애 종류



◆ 장애 상황
1일에 전체 풀백업을 받고난 후 4일에 TS_A테이블스페이스의 테이블 하나가 드랍되었다는 것을 인지하였다. 테이블은 3일 12:00:00에 삭제되었다고 한다.


◆ 복구 방법에 대한 고찰
위의 장애 상황에서 테이블이 3일 12:00:00에 삭제되었다고 하면, 3일 11:59:59까지는 해당 테이블이 존재했었다는 것을 알 수 있다.
그러면 DB를 3일 11:59:59 시점으로 돌리면 해당 테이블은 삭제되지 않은 상태로 복구 가능하다.
그러나 이에 주의할 사항은 이것은 현재시점까지 완전히 복구하는 것이 아니라 과거의 장애나기 이전 시점까지 복구하는 불완전 복구라는 사실이다.
장애난 데이터파일은 TS_A테이블스페이스의 a.dbf이다. 이 불완전 복구시 a.dbf만 복원하면 될까? 절대 그럴 수 없다. 이렇게 하면 나중에 DB오픈시 Incarnation 번호가 다르다는 에러를 띄운다.
또한 데이터파일 모두를 복원해야 하는데, 리두로그와 컨트롤파일까지 모두 복원시키면 안된다. 그렇게 되면 현재시점에 대한 정보가 없기 때문에 리두로그와 컨트롤파일은 현재시점의 것을 사용해야 한다.


◆ 복구
1일에 풀백업 받았던 데이터파일 전체를 복원한다. 그러면 4일 현재 데이터파일은 SCN이 100이고, 리두로그와 컨트롤파일은 108일 것이다.

recover 명령으로 3일 테이블이 삭제되기 전 시간까지 복구를 하면 데이터파일의 SCN은 103일 것이다. 여기까지 하면 데이터파일 복구는 완료되었지만, DB를 오픈시키려고 하면 리두로그와 컨트롤파일의 SCN은 108이기 때문에 서로 시점이 맞지 않아 오픈이 안된다. 그래서 오픈시킬 때 resetlogs옵션을 주어 SCN을 맞춰준다. resetlogs옵션을 주면 컨트롤파일 SCN은 복구완료된 데이터파일 SCN인 103으로 동기화시키고, 리두로그파일의 SCN정보는 지워버린다. 그리고 LSN(로그시퀀스번호)는 1로 된다.
이렇게 하면 DB가 복구완료된 상태로 오픈된다.
단, resetlogs로 오픈시키면 리두로그가 초기화가 되었기 때문에 이전에 받아둔 백업은 쓸 수가 없게 된다. 반드시 오픈되면 전체풀백업을 다시 받도록 한다.

그런데 문제는 만약에 해당 시간까지 복구완료했는데 테이블이 없었다면? 다시 불완전복구를 처음부터 수행해야 한다. 그런데 resetlogs로 DB를 오픈시켰기 때문에 리두로그가 초기화되어 로그정보를 쓸 수 없다. 그래서 불완전복구 시에는 복구경로를 다르게 두어 만약 해당 복구시점이 잘못되면 다시 현재 SCN정보를 가져올 수 있도록 하고 있다.
위와 같이 해주면 설령 복구가 잘못 되더라도 다시 현재 시점의 리두로그와 컨트롤파일을 가져오면 되므로 좀 더 안전한 복구작업을 수행할 수 있다.
Posted by 겨울섬
,