개요
이장은 장애시간 전으로 복구 시킬 필요가 있는 archivelog 모드를 사용하는 데이터베이스 복구 경우에 대해 설명합니다.

불완전 복구
데이터베이스를 이전시점(장애시간 전으로)으로 재구축합니다.

주의: 이 경우는 복구시간 이후에 커밋된 트랜잭션들의 데이터 손실을 초래합니다. 이 데이터는 수동으로 재입력시킬 필요가 있으므로 절대적으로 필요한 경우에만 복구를 수행하십시오.  불완전한 복구는 따라서 어렵고 시간 소모적인 작업이 될 수 있습니다.

불완전 복구 수행

일반적 원인

불완전 복구의 유형
이런 불완전 복구의 유형은 “recover database” 명령을 사용합니다.

Time-Based 복구
이 복구방법은 데이터베이스가 특정 시점으로 모든 변경을 커밋한 후에 종료됩니다. 다음과 같은 경우 이 접근법을 사용하십시오:

Cancel-Based 복구
이 복구 방법은 복구 프롬프트(로그 파일 이름 대신)에서 “Cancel”을 입력함으로써 종료됩니다. 다음과 같은 경우 이 접근법을 사용하십시오:

백업 컨트롤 파일을 이용한 복구
이 복구 방법은 명시한 복구 방법(cancel, time, 또는 change)이 완료되었거나 컨트롤 파일이 복구 되었을 때 종료됩니다. 과거 컨트롤 파일의 복사본이 복구에 사용될 것이라는 것을 “recover database”명령에 명시해야 합니다.
다음과 같은 경우 이 방법을 사용하십시오:

Change-Based 복구
이 복구 방법은 데이터베이스가 모든 변경사항을 특정 시스템 변경 번호(SCN)로 커밋한 후에 종료됩니다. 분산환경에서 데이터베이스 복구 시 이 방법을 사용하십시오.

본 과정에서 이 방법에 대해 더 이상 기술하지 않습니다. 더 자세한 정보가 필요하시면 Oracle8: Distributed Database 과정에 참석하십시오.

Recover 명령
아래 명령이 불완전 복구를 수행하기 위해 사용됩니다:

    recover [automatic] database <Option>

주의

불완전 복구
불완전 복구 (archivelog 모드 데이터베이스만 해당)가 요구되는 장애 발생시 복구하기 위해서는 다음과 같은 것을 갖고 있어야 합니다:

복구 단계
불완전 복구를 위해 위의 요구사항이 만족될 시 복구하기 위해 다음을 수행해야 합니다:

  1. 기존 데이터베이스의 전체 닫힌 백업 수행
  2. 모든 데이터 파일들을 이전 백업(시스템 데이터파일 포함)으로부터 복원될 것이기 때문에 데이터베이스가 먼저 종료되었는지 확인
  3. 데이터베이스를 과거 어느 시점으로 돌리기 위해 모든 데이터 파일 복원
  4. 데이터베이스를 mount 모드로 하고 데이터베이스 복구
  5. “resetlogs” 옵션을 사용하여 데이터베이스를 오픈하고 데이터베이스 문제가 해결  되었는지 확인(해결되지 않았을 때 다시 복구)
  6. 데이터베이스 전체 닫힌 백업 수행
alter database open resetlogs;
한 후에는 사용할 리두 로그 그룹(Current)에만 log sequence number 1 로 재설정되고 나머지 리두 로그 그룹은 모두 임시로 0 으로 설정됩니다. 그러므로 log sequence number 0 은 새롭게 시작하는 log sequence number 라기 보다는 임시로 존재하는 번호입니다.

불완전 복구 지침

Alert Log
복구 동안 진행정보가 alert log 에 저장됩니다. 이 파일은 항상 복구 전후에 검사되어야 합니다. 예를 들어:
             
  $ vi /disk1/BDUMP/alert_DB00.log
    ...
  Media Recovery Log
  ORA-279 … RECOVER database until time ‘1997…
  Tue Dec 09 11:55;13 1997
  ALTER DATABASE RECOVER   CONTINUE DEFAULT
  Media Recovery Log /disk1/archive/arch_34.rdo
  Incomplete recovery done UNTIL CHANGE 309121
  Media Recovery Complete
  Completed: ALTER DATABASE RECOVER CONTINUE DEFAULT
  Tue Dec 09  11:55:13   1997
  alter database open resetlogs
    ...

Until Time 사용한 불완전 복구
따라서 여러분은 즉각 데이터베이스를 종료하고 복구를 시작합니다. 대략 장애 시점이 알려져 있고 데이터베이스 구조가 11: 44 a.m. 이후에는 변경되지 않았으므로 "Until time" 방법을 사용할 수 있습니다:
 

 단계번호

  설명

1

 데이터베이스가 오픈 상태라면, “normal” 또는 “immediate”옵션을 사용하여 종료하십시오.

2

데이터베이스를 마운트하십시오.

3

백업(가능하다면 가장 최근 것)으로부터 모든 데이터 파일을 복원하십시오.
UNIX> ! cp /disk1/backup/*.dbf /disk1/data/
UNIX> ! cp /disk2/backup/*.dbf /disk2/data/
UNIX>...  
 NT> !copy c:\backup\*.dbf c:\data\
 NT> !copy d:\backup\*.dbf d:\data\
 NT>...

4

아카이브 로그를 복원할 필요가 있을 수도 있습니다. 이용 가능한 충분한 공간이 존재 시 LOG_ARCHIVE_DEST 위치에 저장하거나 위치를 변경하기 위해 SQL “alter system archive log start to<location>” 또는 Server Manager “set  logsource<location>명령”을 사용하십시오.

5

다음과 같이 복구하십시오.
SVRMGR>recover database until time  '1997-12-09:11:44:00';
ORA-00279 : change 148448 ...11/29/97/ 17:04:20
needed for thread
ORA-00289 : suggestion : /disk1/archive/arch_6.rdo
ORA-00280: change 148448 for thread 1 is in sequence #6
Log applied.
...
Media recovery complete.

6

컨트롤 파일 및 리두 로그와 동기화하기 위해 'resetlogs'옵션을 사용하여 데이터베이스를 오프하십시오.
SVRMGR>alter database open resetlogs;
SVRMGR>archive log list;
...
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1

7

전체 닫힌 데이터베이스 백업을 수행하기 전에 존재하는지 확인하기 위해 EMP테이블을 조회하십시오. 다음의 에러를 만난다면:
ORA-00942:table or view does not exist
다음을 사용하여 테이블의 스키마를 찾으십시오.
SVRMGR> select table_name, owner
     2> from dba_tables where table_name = ‘EMP’ ;
TABLE_NAME                OWNER
--------              ---------
EMP                       PETER
1 row selected.

주의: 어떤 행도 검색되지 않았다면 이 테이블은 올바르게 복원되지 않았습니다. 여러분은  더 이전의 시점으로 복구할 필요성이 있을 것입니다. 그렇지 않다면 백업을 수행하십시오.

8

복구가 완료되고 백업이 완료되었을 때 데이터베이스가 사용 가능하게 되었음을 사용자에게 알리고 복구시점(11:44 a. m.)이후에 입력된 모든 데이터는 재입력할 필요가 있다고 사용자에게 알려주십시오.

Until Cancel을 사용한 불완전 복구
디스크 에러를 유발한 EMP 테이블 상의 블록 손상에 관해 염려하고 있습니다. 리두 로그가 동일 디스크 상에 존재하고 있으므로 여러분은 리두 로그의 상태 및 아카이브 로그의 상태를 다음과 같이 조사하기로 결정합니다:

 SVRMGR> select * from v$logfile;
  GROUP#   STAUS   MEMBER
 -------   -----   -------------------
       2           /disk1/data/log2a.rdo
       1           /disk1/data/logla.rdo

 SVRMGR> select  * from v$log;
 G#  ... SEQ#   BYTES MEMBERS ARC STATUS   ...  FIRST_TIME
 --  ... ----  ------ ------- --- -------- ...  --------------
  1  ...   49  153600       1  NO CURRENT  ...  97-12-09:11:55
  2  ...   48  153600       1  NO INACTIVE ...  97-12-09:11:34

Until Cancel을 사용한 불완전 복구(계속)
/disk1/data 디렉토리를 찾은 후에 "log2a.rdo" 리두 로그를 찾을 수 없으며 아카이브가 되어 있지 않음을 알게 되었습니다. 따라서 이 시점까지 복구 할 수 없습니다.
V$LOG_HISTORY 를 조회함으로써 아카이브 로그 시퀀스 48(log1a.rdo)이 존재하지 않음을 확인합니다:

  SVRMGR> select * from v$log_history;
  RECID  STAMP     ... FIRST_CHANGE  FIRST_TIME
  -----  --------- ... ------------  --------------
      1  318531466 ...        88330  97-11-28:12:43
     47  319512880 ...       309067  97-12-09:11:26

이것은 OLTP 시스템임으로 V$LOG의 결과는 "log2a.rdo" 적용 전에 데이터베이스가 복구된다면 추가 10분의 작업이 손실될 것이라는 것을 보여 줍니다. 사용자들은 작업을 잃어버리는 데 대해 불만이지만 복구 가능할 수 있습니다. 따라서 여러분은 다음과 같이 데이터베이스를 복원하기를 시작합니다:

  1. 데이터베이스를 종료합니다.
  2. 이미 유효한 백업을 갖고 있으므로 인스턴스를 마운트합니다.
  3. 가장 최근 백업으로부터 모든 데이터파일을 복원합니다.
  4. 다음과 같이 로그 시퀀스 48 까지 데이터베이스를 복구합니다.

     SVRMGR> recover  database until cancel
     ORA-00279 : change 148448 … 12/02/97 12 :45:20 needed for thread
     ORA-00289 : suggestion  : /disk1/archive/arch_34.rdo
     ORA-00280 : change 148448 for thread 1 is in sequence #34
     Log applied.
      ...
     ORA-00279 : change 309012 … 12/09/97 11 :33:56 needed for thread 1
     ORA-00289 : suggestion  : /disk1/archive/arch_48.rdo
     ORA-00280 : change 309012 for thread 1 is in sequence #48
     Specify log : {<RET>=suggested l filename l AUTO l CANCEL}
     cancel.
     Media recovery cancelled.
  5. "resetlogs" 옵션을 사용하여 데이터베이스를 오픈합니다.
  6. 단순한 Select 문을 수행함으로써  EMP 테이블이 존재하는지 검사합니다.
  7. 복구가 성공적일 때 사용자에게 데이터베이스가 이용가능하게 되었으므로 복구시간(11:34 a.m.)이후에 입력된 모든 데이터는 재입력될 필요가 있음을 알려줍니다.

백업 컨트롤 파일을 사용한 불완전 복구

  1. 수습 DBA가 다음 명령으로 EMP 테이블스페이스를 제거했습니다.
     SQL> drop tablespace emp_ts including contents;
     
  2. 여러분은 즉각 사용자에게 로그 아웃하고 과거 15분 동안 입력한 데이터를 갖고 있기를 요청합니다. 모든 사용자가 로그아웃하고 해당 세션이 종료되기를 기다리는 동안 더 이상 액세스를 막기 위해 데이터베이스를  restricted mode로 둡니다.
     SVRMGR> alter system enable restricted session;
      
  3. 조사하는 동안 지난 밤 백업으로부터 바이너리 컨트롤 파일을 찾아냅니다. 현재의  컨트롤 파일이 대체될 것이기 때문에 요구되는 경우에 데이터베이스 구조 정보를  주의 깊게 수집합니다:
     SVRMGR> selcet * from v$log;
     GROUP# ... SEQ# BYTES  ... ARC STATUS   ... FIRST_TIME
     ------ ... ---- ------ ... --- -------- ... -------------
          1 ... 61   153600 ... NO  CURRENT  ... 97-12-09:11:5
          2 ... 60   153600 ... NO  INACTIVE ... 97-12-09:11:34

     SVRMGR> select tablespace_name, file_name from dba_data_files
          2> where tablespace_name = ‘EMP_TS’;
     TABLESPACE_NAME   FILE_NAME
     ---------------   ----------------------
     EMP_TS            /disk1/data/emp_01.dbf

백업 컨트롤 파일을 이용한 불완전 복구(계속)

  1. 경고 로그를 조사함으로써 에러시간을 확인합니다:
          UNIX> vi /disk1/BDUMP/alert*.log
     or NT> notepad c:\BDUMP\alert_DB00.log
     ...
     Tue Dec  09 11:44:54 1997
     drop tablespace emp_ts including contents
  2. 데이터베이스를 종료하고 컨트롤 파일들을 백업하고 난 뒤 테이블스페이스가 존재했을 때의 모든 데이터 파일과 컨트롤 파일을 복원합니다. 데이터베이스 오픈을 시도한 후에 다음 에러는 리두 로그와 컨트롤 파일이 동기화되지 않았다는 것을  알려주고 있습니다:
     ORA-00314:log 1 of thread 1, expected sequence# doesn’t match
     ORA-00312:online log 1 thread 1: ‘/disk1/data/log1a.rdo’
  3. 임의의 오프라인 데이터 파일이 존재하는지 알기 위해 조사해 보고 그들을   온라인으로 만듭니다. 임의의 오프라인 파일들은 복구 후에 복구가능하지 않게    될 수도 있기 때문입니다.
     SVRMGR> select  *  from  v$recover_file;
     FILE#   ONLINE    ERROR   CHANGE#   TIME
     -----   -------   -----   -------   ---------
         4   OFFLINE            288772   02-DEC-99
     SVRMGR> alter database datafile 4 online;
  4. 다음과 같이 복구를 수행합니다:
     SVRMGR> recover database until time ‘1997-12-09:11:44:00’
          2> using backup controlfile;
     ...
     Media recovery complete.
     
    주의:     “Media recovery complete” 대신에 아래의 에러가 나타나면 데이터 파일이 더 이전의 백업으로부터 복원될 필요가 있거나 더 이상의 복구가 필요(여기서는 가능하지 않음)함을 의미합니다.
     ORA-01152:file 7 was not restored from a sufficiently old backup
     ORA-01110:datafile 7: ‘/disk1/data/newfile01.dbf’
  5. 컨트롤 파일 및 리두 로그와 동기화 시키기 위해 “resetlogs” 옵션을 사용하여 데이터베이스를 오픈합니다.
  6. 단순한 Select 문을 수행함으로써 EMP 테이블이 존재하는지를 검사합니다.
  7. 복구가 성공적일 때 사용자에게 데이터베이스가 사용 가능하게 되었고 11: 44 a.m. 이후 임의의 데이터는 재입력 시킬 필요가 있다고 알려 줍니다.

현재 리두 로그의 손실
다음과 같이 “Current” 온라인 리두 로그가 분실되었을 때 2가지 가능한 복구상황이 있습니다:

데이터베이스가 오픈되어 있으나 “hung”상태
데이터베이스가 오픈되어 있으나 이 파일이 손상되거나 우연히 삭제될 수도 있습니다.

  1. “hung” 데이터베이스 문제를 해결하기 위해 다음 단계들을 사용하십시오:
      SVRMGR> select  * from v$log;
      GROUP# ... SEQ#   BYTES ... ARC  STATUS   ... FIRST_TIME
      ------ ... ----  ------ ... ---  -------- ... --------------
           1 ...   61  153600 ...  NO  CURRENT  ... 97-12-09:11:55
           2 ...   60  153600 ...  NO  INACTIVE ... 97-12-09:11:34
  2. 아래 명령을 사용하여 현재 로그 파일을 삭제합니다.
     SVRMGR> alter database clear unarchived logfile group 1
  3. 데이터베이스는 이제 운영 가능하게 될 것입니다. 로그 파일이 손상 시 겹쳐 써지게 될 것이며 파일 손실 시에는 재생성 될 것이기 때문입니다.
  4. 다음 백업 전에 데이터베이스가 미디어 장애 때문에 다운된다면 복구 정보가 막 삭제되었기 때문에 불완전 복구가 요구될 것입니다. 따라서 즉각 닫힌 전체 백업을 수행해야 합니다.

장애로 인해 닫힌 데이터베이스
데이터베이스가 닫히게 되었다면 미디어 장애가 발생했을 수도 있거나 백그라운드 프로세스가 종료되었을 수도 있습니다. 이 상황을 해결하기 위해 아래 단계들을 사용하십시오.

  1. 데이터베이스를 오픈하려고 시도할 때 다음 메시지를 통해 현재 리두 로그 그룹을 여러분에게 즉각 알려줄 것입니다:
     Database mounted.
     ORA-00313: open failed for members of log group 2 of thread 1
     ORA-00312: online log 2 thread 1 :  ‘/disk1/archive/log2a.rdo’
     ORA-27037: unable to obtain file status
     SVR4 Error:2: No such file or directory
     Additional information : 3
  2. 로그 그룹2가 현재의 로그 그룹이기 때문에 아직 아카이브되지 않았을 것입니다.“clear logfile”명령을 사용하는 것은 다음과 같이 소용없을 것입니다:
     SVRMGR> alter database clear unarchived logfile group 2;
     ORA-01624 : log 2 needed for crash recovery of thread 1
     ORA-00312 : online log 2 thread 1: ‘disk1/archive/log2a.rdo’
  3. 따라서 불완전 복구가 요구됩니다. 우선 다음과 같이 현재 로그 시퀀스 번호를     알아야 합니다.
     SVRMGR > select * from v$log;
     GROUP# ...  SEQ#   BYTES ... ARC  STATUS   ... FIRST_TIME
     ------ ...  ----  ------ ... ---  -------- ... --------------
          1 ...    61  153600 ... NO   CURRENT  ... 97-12-09:11:55
          2 ...    60  153600 ... NO   INACTIVE ... 97-12-09:11:34
  4. 이전 백업으로부터 모든 데이터 파일을 저장하고 리두 로그 61 적용 전에 중단하기  위해 recover until cancel을 사용하십시오.
     SVRMGR> recover  database until cancel
     ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
     ORA-00289 : suggestion  : /disk1/archive/arch_46.rdo
     ORA-00280 : change 309043 for thread 1 is in sequence #46
     Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
     ...
     ORA-00279 : change 309141... 12/09/97 19:50:14 needed for thread 1
     ORA-00289 : suggestion  : /disk1/archive/arch_61.rdo
     ORA-00280 : change 309043 for thread 1 is in sequence #61
     Specify log : {<RET>=suggested |filename | AUTO | CANCEL}
     cancel.
     Media  recovery complete.
  5. "resetlogs" 옵션을 사용하여 데이터베이스를 오픈합니다.
  6. 데이터베이스는 이제 운영 가능하게 될 것인데 임의의 빠진 로그 파일들은 재생성될 것입니다.
    주의 : 미디어 장애 때문에 로그 파일이 다른 디스크상에서 생성될 필요가 있다면 “alter database drop logfile group”이나 수동으로 로그 파일을 생성하기 위해 “alter database add log group”명령을 사용합니다.
  7. 막 불완전 복구를 수행했기 때문에 데이터베이스는 이제 백업되어야 합니다.

이과정 사용 시점
불완전 복구 후 매번 백업을 한다면 이 프로시저는 수행할 필요가 없습니다.  그러나 주 7일 일 24시간 이용 가능해야 하는 대형 데이터베이스는 단축된 복구시간을 요구합니다. 따라서 복구 후에 오픈 데이터베이스 백업이 강행됩니다. 백업이 완료되기 전에 미디어 장애가 발생한다면 이러한 복구방법이 요구될 수 있습니다.

전제조건
이 방법을 사용하기 위해 아래 조건들을 만족해야 합니다:

절차
어느 단계도 생략하지 말고 모든 단계를 수행하십시오.
확신이 없을 때에는 오라클 worldwide  지원 그룹에 연락하십시오.

  1. 현재 데이터베이스 컨트롤 파일을 다른 위치에 복사하십시오.
  2. 최근 “resetlogs” 연산 전의 백업으로 데이터 파일과 컨트롤 파일을 복원하십시오.
  3. 데이터베이스를 마운트하십시오.
  4. 경고 로그(alert log)에서 이전 “resetlogs” 연산 완료 시에 계산된 변경 번호를 찾으십시오.
     ...
     Incomplete recovery done UNTIL CHANGE 309121
     Media Recovery complete
     ...
  5. 위에서 찾은 변경번호까지 데이터베이스를 복구하십시오.
     SVRMGR> recover  database until change 309121  \
          2> using backup controlfile;
     ORA-00279 : change 309043... 12/09/97 14:50:14 needed for thread 1
     ORA-00289 : suggestion  : /home/disk1/user4/ARCHIVE/arch_46.rdo
     ORA-00280 : change 309043 for thread 1 is in sequence #46
     Specify log: {<RET>=suggested | filename |AUTO | CANCEL}
     auto
     ...
     Media recovery complete.
  6. “normal’옵션을 사용하여 데이터베이스를 종료하십시오.
  7. 단계 1에서 명시한 위치로부터 현재 컨트롤 파일을 복원하십시오.
  8. 데이터베이스를 마운트하십시오.
  9. RECOVER DATABASE 명령에서 적절한 옵션을 사용하여 데이터베이스를 복구하십시오.
  10. 데이터베이스를 오픈하십시오.
  11. 복구하고자 했던 데이터를 검증하십시오.
  12. 올바른 로그 시퀀스 번호까지 복구가 되었는지 확인하기 위해 V$LOG를 조사하십시오.
  13. resetlogs를 통한 복구를 방지하기 위해 데이터베이스를 백업하십시오. 

로그시퀀스번호(log sequence number)는 리두로그파일의 그룹을 사용할때 마다 증가합니다. 무한정 증가할 수 있는 것은 아니지만 오라클이 내부적으로 특별한 제한없이 사용할 수 있도록 아주 큰 값으로 max값을 지정했으므로 MAX에 도달될 염려없이 사용하시면 됩니다.

로그시퀀스번호를 초기화하는 것은 데이터베이스를 오픈할 때 RESETLOGS로 오픈하면 초기화되어 로그시퀀스번호는 다시 1부터 시작하게 됩니다.

Tablespace Point-in-Time Recovery(TSPITR)
이 절은 저급 수준의 이해가 아니라 TSPITR 개념에 대한 소개차원으로 설계되어 있습니다. 이 복구방법을 사용하는 때는 거의 없으며 오라클 Worldwide 지원그룹과 관련하여서만 사용되어야 합니다. 백업 및 복구 프로시저를 따른다면 이 방법은 결코 요구되지 않을 것입니다.

TSPITR 사용
이 복구 방법은 사용자 에러가 발생하여 데이터베이스가 과거 특정시점으로 돌려질 수 없는 경우에만 사용될 수 있습니다. 예를 들어:

이 경우에 TSPITR은 해당 테이블스페이스와 그것의 종속물들만 이틀 전의 것으로 되돌리기 위해 요구됩니다.

TSPITR 요구사항
TSPITR 을 사용하기 전에 아래 요구 사항들을 만족해야 합니다:

TSPITR 수행
TSPITR  복구에 대한 더 많은 정보를 보시려면 “Oracle8 : Backup and Recovery Guide”를 참조하십시오. 아래 단계들은 TSPITR 을 위해 요구되어집니다:

  1. TSPITR 수행시 객체들이 손실될 지 결정합니다.
  2. 기본 데이터베이스의 종속성을 찾아 해결합니다.
  3. TSPITR을 위해 기본 데이터베이스를 준비합니다.
  4. clone 데이터베이스를 위해 파라미터 파일을 준비합니다.
  5. TSPITR을 위해 clone 데이터베이스를 준비합니다.
  6. clone 데이터베이스를 복구합니다.
  7. clone 데이터베이스를 오픈합니다.
  8. 익스포트를 위해 clone 데이터베이스를 준비합니다.
  9. clone 데이터베이스를 익스포트합니다.
  10. clone 파일들을 기본 데이터베이스에 복사합니다.
  11. 기본 데이터베이스로 임포트합니다.
  12. 사용을 위해 기본 데이터베이스를 준비합니다.
  13. 기본 데이터베이스의 복구된 테이블스페이스를 백업합니다.

기본 데이타베이스에서 TS_PITR_CHECK 뷰를 통해서 복구해야할 recovery set 를 알아낸 후 기본 데이타베이스에서 TSPITR 을 위한 특정 준비작업을 수행한 후 clone DB를 준비합니다. 이것은 기본 DB를 생성하듯이 일반적인 방법으로 데이타베이스를 생성하는 것이 아닙니다.
다음에서 clone DB 를 생성하는 과정을 간략히 소개하겠습니다.
물론 이전에 기본 데이타베이스에서 미리 수행되어야할 준비과정들이 또 있습니다.

1. clone DB를 위한 파라미터 파일을 만들고 지정된 파라미터를 설정합니다.
2. recovery set 를 기본 데이타베이스와 다른 위치에 restore 합니다.
3. 새로 만든 init.ora 파일로 clone DB를 마운트시킵니다.
4. alter database rename file ......명령으로 restore 된 위치를 인식시킵니다.
5. alter database datafile..... online명령을 수행하여 TSPITR 을 수행할 recovery set tablespace를 온라인시킵니다.

위의 과정을 통해 clone DB가 준비되면 이제 TSPITR 을 수행합니다.이 과정도 상당히 길고 복잡하므로 여기서는 생략하도록 하겠습니다.

두 가지 방식

다음 두 가지 방식으로 TSPITR을 수행할 수 있습니다.

방식

결과

기존의 O/S TSPITR

복제 init.ora 파일 생성, 복제 데이터베이스 마운트 등의 작업을 위한 특수 프로시저를 수행해야 합니다. O/S TSPITR은 사용자가 기본 데이터베이스와 동일한 컴퓨터에 복제 데이터베이스를 둔다고 가정합니다. 이 프로시저에서는 복제 데이터베이스를 복구하는 동안 동일한 컴퓨터에 있는 기본 데이터베이스가 훼손되는 것을 방지하기 위해 오류 검사를 수행합니다.

이동 가능한 테이블스페이스 기능을 사용한 TSPITR

이동 가능한 테이블스페이스를 사용하여 TSPITR을 수행하면 이러한 요구 사항이 완화됩니다. 이 방식은 이동된 테이블스페이스를 사용하여 TSPITR의 마지막 단계를 수행한다는 점에서 표준 O/S TSPITR과는 다릅니다. 이 방식을 사용하려면 COMPATIBLE 초기화 매개변수를 8.1 이상으로 설정해야 합니다.

이동 가능한 테이블스페이스를 사용한 TSPITR 수행

참고: 데이터베이스 간 테이블스페이스 이동 방법에 대한 자세한 내용은 Oracle8i 관리자 설명서 또는 Oracle8i Database Administration 과정을 참조하십시오.

뛰어난 융통성

이동 가능한 테이블스페이스를 사용하는 TSPITR은 기본적으로 O/S TSPITR과 동일한 기능을 제공하지만 다음과 같은 점에서 보다 뛰어난 융통성을 제공합니다.

프로시저

  1. 백업을 복원하여 대상 데이터베이스를 생성합니다. 기본 데이터베이스가 있는 컴퓨터 또는 다른 컴퓨터에서 대상 데이터베이스를 생성합니다.
  2. 특수 복제 데이터베이스 프로시저를 사용하여 대상 데이터베이스를 생성한 경우 모든 복구 집합 및 보조 집합 파일을 온라인 상태로 만듭니다.

    ALTER DATABASE DATAFILE 'datafile_name' ONLINE;

    기본 데이터베이스가 있는 컴퓨터가 아닌 다른 컴퓨터에 대상 데이터베이스를 일반 데이터베이스처럼 생성한 경우 복구 및 보조 집합에 없는 모든 데이터 파일을 오프라인 상태로 만듭니다.

    ALTER DATABASE DATAFILE 'datafile_name' OFFLINE;
     
  3. 대상 데이터베이스를 지정된 시점으로 복구합니다.
  4. RESETLOGS 옵션을 사용하여 대상 데이터베이스를 엽니다.
  5. 복구 집합에 있는 테이블스페이스를 읽기 전용으로 만듭니다.
    ALTER TABLESPACE tablespace_name1 READ ONLY;
    ALTER TABLESPACE tablespace_name2 READ ONLY;
     
  6. EXPORT를 실행하여 이동 가능한 집합을 생성합니다. 모든 테이블스페이스를 복구 집합에 포함합니다.
    exp system/manager TRANSPORT_TABLESPACE=y
            TABLESPACES=(tablespace_name1, tablespace_name2)
     
  7. 기본 데이터베이스에서 복구 집합에 있는 테이블스페이스를 삭제합니다.
    DROP TABLESPACE tablespace_name1;
    DROP TABLESPACE tablespace_name2;
     
  8. 이동된 테이블스페이스의 데이터 파일 및 엑스포트 파일을 기본 데이터베이스에 복사합니다.
  9. IMPORT를 실행하여 이동 가능한 집합을 기본 데이터베이스에 연결합니다.
    imp system/manager TRANSPORT_TABLESPACE=y
            TABLESPACES=(tablespace_name1, tablespace_name2)
     
  10. 필요한 경우 복구된 테이블스페이스를 읽기/쓰기 상태로 만듭니다.
    ALTER TABLESPACE tablespace_name1 READ WRITE;
    ALTER TABLESPACE tablespace_name2 READ WRITE;
     
  11. 기본 데이터베이스에 있는 복구된 테이블스페이스를 백업합니다.
    ALTER TABLESPACE tablespace_name1 BEGIN BACKUP;
    !cp datafile_name backup/datafile_name
    ALTER TABLESPACE tablespace_name1 END BACKUP;
    ALTER TABLESPACE tablespace_name2 BEGIN BACKUP;
    !cp datafile_name backup/datafile_name
    ALTER TABLESPACE tablespace_name2 END BACKUP;


 문맥

 참 조

 파라미터

 BACKGROUND_DUMP_DEST
 NLS_LANG
 NLS_DATE_FORMAT

 동적 성능 뷰

 V$LOG
 V$LOGFILE
 V$LOG_HISTORY
 V$RECOVER_FILE

 데이터 딕셔너리 뷰

 none

 명령어

 ALTER DATABASE OPEN RESETLOGS
 ALTER DATABASE CLEAR UNARCHIVED LOGFLE
 GROUP n
 ALTER DATABASE DATAFILE [OFFLINE|ONLINE
 ALTER SYSTEM ENABLE RESTRICTED SESSION
 ARCHIVE LGO LIST
 RECOVER DATABASE UNTIL [CANCEL |TIME|
 CHANGE]
 RECOVER DATABASE UNTIL TIME [USING  BACKUUP
 CONTROLFILE]
 RMAN-RESET DATABASE
 RMAN-RECOVER DATABASE

  1. CREATE CONTROLFILE 명령에서 RESETLOGS option 을 줄 경우 ALTER DATABASE 명령에서 주어야만 하는 option 은?

    A. RESETLOGS
    B. NORESETLOGS
    답
    O


  2. Database 가 장애가 발생하였다. 불완전 복구를 해야만 하는데 복구되어질 시점을 알수없을 경우 복구방법은?
    A. cancel-based
    B. time-based
    C. change-based
    답
    O


  3. Incomplete Recovery 를 완료하였다 그 다음 작업은?

    SVRMGR> ALTER DATABASE OPEN RESETLOGS

    Full Database Backup 수행

    기존 생성된 Archived Redo Log File 삭제

    A. TRUE
    B. FALSE
    답
    X 정답:A


  4. Incomplete Recovery 를 완료하였다면 database를 open 할 때 반드시 resetlogs option을 사용해야 한다.
    A. TRUE
    B. FALSE
    답
    O


  5. Incomplete Recovery 에 관한 설명 중 옳지 않은 것은?
    A. ARCHIVELOG mode 에서 수행.
    B. 모든 Online Redo Log File 유실.
    C. 손실된 Datafile 만 Restore 후 복구.
    D. 과거 특정시점까지 복구.
    E. Control File 의 Backup 을 이용한 복구.
    F. Archived Redo Log File 의 유실로 Complete Recovery 로 수행하지 못할 경우
    답
    O


  6. Incomplete Recovery 종류는(3 가지)?
    A. Cancel-Base
    B. Time-Base
    C. Change-Base
    D. Stop-Base
    답
    X 정답:ABC


  7. RESETLOGS option 으로 Database 를 open 한후 current log sequence number 는 몇으로 되는가?
    A. 0
    B. 1
    답
    X 정답:B


  8. Recover database using backup controlfile 과 관련하여 다음 중 옳은 것은?
    A. 복구하고자 하는 시점의 Database 구조가 저장된 control file 백업본이 필요하다.
    B. 가장 최근 control file 백업본이 필요하다.
    답
    X 정답:A


  9. alertSID.log file에는 recovery 시에 참조할 수 있는 많은 내용이 기록되는데, 그 file의 생성위치는? (parameter 명을 대문자로 기입하시오.)
    답
    X 정답:BACKGROUND_DUMP_DEST


  10. 다음중 불완전 복구를 해야만 하는 경우는?
    A. 백업 control file 로부터 복구
    B. 사용자 error
    C. User proess error
    D. Instance failure
    답
    X 정답:AB


  11. 다음중 불완전 복구에 대한 설명중 옳은 것은? (multiple choice)
    A. 불완전 복구는 일반적으로 data 유실이 발생한다.
    B. 일반적으로 많이 사용하는 복구 방식이다.
    C. 유실된 data 는 수동으로 재성성 해야한다.
    D. 시간을 절약할수 있는 복구 방식이다.
    답
    X 정답:AC


  12. 다음중 불완전 복구에 대한 설명중 옳지 않은 것은?
    A. 복구하기 위해 archive log file 이 필요하다.
    B. archive log file 수동 또는 자동으로 적용하여 복구 할수 있다.
    C. archive log file 을 자동으로 적용하기 위해 AUTORECOVERY 를 on 으로 setting.
    D. 불완전 복구후 alter database opne resetlogs 로 open 할수 없다.
    답
    O


  13. 불완전 복구를 수행하기 위해서 수행해야할 STARTUP option 은?
    A. MOUNT
    B. NOMOUNT
    C. OPEN
    답
    O


  14. 불완전 복구를 수행하기전 이후에 불완전 복구를 재시도 하기 위해서는 장애가 발생한 상태에서 Database 를 백업할 필요가 있다?
    A. TRUE
    B. FALSE
    답
    O


  15. 불완전 복구후 RESETLOGS 로 database 를 open 한후 해야할 작업은?
    A. instance 를 Restart
    B. full backup 수행
    C. server 를 Restart
    D. database 복구
    답
    X 정답:B