recover table의 단점?

recover table의 테스트 시나리오 및 내용은 아래 글을 참고하세요.

참고 : https://bae9086.tistory.com/22

[RMAN]Recover Table

참고 : https://bae9086.tistory.com/491

[Recover Table] 여러 테이블 recover 및 remap 옵션

 

12c 신기술로 나온 기술로 RMAN 명령어를 통하여 특정 테이블의 복구를 위해서 사용하는 방법 중 하나입니다.

 

작동 원리로는 , 자동적으로 임시DB를 생성하고 거기서 테이블을 expdp 해 자동으로 impdp까지 해주는 기능입니다.

 

이기능에 대해서 단점이 어떤게 있을까에 대한 고민을 정리하는 글을 작성하고자 합니다.

 

우선 기본적인 제약사항으로는 

- SYS 스키마에 속하는 테이블과 테이블 파티션은 복구할 수 없습니다.

- SYSTEM 및 SYSAUX테이블스페이스의 테이블 및 테이블 파티션을 복구할 수 없습니다.

 

즉 USERS나 업무 테이블스페이스 같이 SYS관련 테이블스페이스가 아닌 위치에 있는 테이블이 복구가 가능합니다.

테이블이 어느 위치에 있느냐에 따른 제약사항이 있다고 볼 수 있습니다. 하지만 왠만하면 SYS나 SYSTEM 소유로 생성하고 관리하고 있지는 않을 것이기 때문에 큰 단점은 아니라고 생각합니다.

 

두번째 제약사항은 

Standby Database(특히 Physical Standby)에서는 RECOVER TABLE 기능 사용 불가입니다.

 

DG(Data Guard)를 활용하는 구성에서 StandBy DB에서는 해당 기능을 사용하지 못합니다.

원본 DB에서만 가능하다고 볼 수 있습니다.

해당 기능도 제약사항이긴 하지만 큰 단점이라고는 생각되지 않는데요,

 

제가 생각하는 가장 큰 단점은 해당 시점에 전체 데이터베이스의 RMAN 백업이 필요하다는 것과, 복구 위치가 원본 DB가 있는 동일한 서버라면 해당 서버의 리소스를 쓴다는 것입니다. 추가적으로 시점까지의 아카이브 로그도 다 갖추고 있어야합니다.

 

테이블 하나를 복구하기 위해서 전체 DB를 복구한다는 것은 DB가 크면 클수록 활용성이 더더욱 떨어지는 부분이라고 생각합니다.

 

그리고 마지막으로 원본테이블을 안건드리기 위해 REMAP을 활용해서 다른 테이블로 복구할 경우 명명된 NOT NULL 제약조건과 인덱스가 복구되지 않습니다.

 

참고 : https://docs.oracle.com/database/121/BRADV/rcmresind.htm

Recovering Tables and Table Partitions from RMAN Backups