개 요
이 장에서는  noarchivelog 또는 archivelog 모드 사용시의 데이터베이스의 복구상황을 다룹니다. 다음 요소들이 데이터베이스 로그 모드 설정 시에 고려되어야 합니다.

미디어 장애
미디어 장애가 발생시 복구하기 위해 유효한 닫힌 데이터베이스 백업이 존재 해야 하는 데 이는 오직 하나의 데이터파일이 손상 또는 분실되었다 할지라도 모든 오라클 파일들이 복구되어야 하기 때문입니다. 다음 파일들을 저장해야 함을 명심하십시오:

  • 모든 데이터파일, 컨트롤 파일 및 리두 로그- 데이터베이스 오픈을 위해 모든 오라클 파일들이 동기화되어야 함을 명심하십시오.
  • 패스워드 또는 파라미터 파일이 손상 또는 손실 시만 이 파일도 필요

주: noarchivelog 모드를 사용하는 데이터베이스의 경우 최근 백업 이후 리두 로그 파일이 재작성되지 않았다면 모든 오라클 파일들을 저장할 필요는 없습니다.

  • 시나리오
    -   데이터베이스에 2개의 리두 로그가 존재합니다.
    -  닫힌 데이터베이스 백업이 로그 시퀀스 144로 받았습니다.
    -  데이터베이스가 로그 시퀀스 145에 있을 시 데이터파일 2는 분실되었습니다.
  • 결과
    로그 시퀀스 144는 재작성되지 않았으므로 단지 데이터파일 2만 저장 가능하고 수동으로 복구될 수 있습니다.

장점 및 단점
noarchivelog 모드로 시험 또는 개발을 위해 데이터베이스 운영을 결정 했을 시 다음과 같은 장단점을 고려하십시오.

장점

단점

현재 특정 데이터파일의 손상이 발견되어 복구가 필요한 시점일 경우, 온라인 리두 로그 파일에 필요한 리두 로그가 모두 존재하는지 확인하기 위해서는 다음과 같은 문장들을 사용할 수 있습니다. 


SQL> SELECT *

  2  > FROM v$recover_file;



FILE#   ONLINE    ERROR    CHANGE#    TIME

-----   --------   --------   ----------   ----------

      2   OFFLINE                        56744   09-MAR-01

위의 결과에 의하면 2번 데이터파일의 최종 SCN이 56744이며 그 이후의 작업에 대해 복구가 필요함을 알 수 있습니다.

이 때, 복구에 필요한 리두 로그 데이터가 온라인 리두 로그 파일에 존재하는지 확인하기 위하여 다음과 같은 문장을 실행해 봅니다.

SQL> SELECT group#, first_change#, status
2 > FROM v$log; 

GROUP#  FIRST_CHANGE#  STATUS

--------  ----------------  ---------

           1                  64887  CURRENT

           2                 56205  INACTIVE

위의 결과에 의하면 리두 로그 그룹 2 에는 SCN 56205 ~ 64886 까지의 리두 로그 정보를 가지고 있으므로 손상된 데이터파일 2번을 복구하기 위해 필요한 모든 리두 로그 정보가 온라인 리두 로그 파일에 존재한다는 것을 알 수 있습니다. 이 경우는 데이터베이스가 Noarchivelog 모드여도 완전복구가 가능합니다.

그런데 만약 [v$log의 MIN(first_change#)] > [v$recover_file의 change#]인 경우는 복구에 필요한 리두 로그 정보가 이미 덮어쓰여진 것이므로 데이터베이스의 복구가 불가능하게 됩니다.


미디어장애로부터 복구 (Noarchivelog 모드)

  1. 디스크 2가 손상되어 데이터파일 2가 손실되었습니다.
     
  2. 가장 최근의 백업이 로그 시퀀스 144에서 취해졌고 현재 로그 시퀀스는 146  이기 때문에 데이터파일을 복구할 수가 없는데 이는 리두 로그 144가 덮어써지기 때문입니다.(복구가 시도될 때 이사실을 확인할 수 있습니다.)
    따라서, 데이터베이스를 종료하고 모든 오라클 파일들을 저장하십시오.

       SVRMGR> shutdown abort;

    파일을 복원하기 위해:
       UNIX  >     !  cp  /disk1/backup/*  / disk1/data/
       NT    > ! copy  \disk1\backup\*.* \disk1\data
  3. 복사가 작성되었을 때 인스턴스를 다시 시작합니다:
       SVRMGR> connect / as sysdba;
       SVRMGR> startup pfile = initDB00.ora;
  4. 가장 최근 백업 시점 이후의 데이터를 재입력할 필요가 있다고 사용자에게 통보하십시오.

다른 위치에 파일 저장

  1. 컨트롤 파일이 다른 위치로 복원될 파라미터 파일을 갱신하십시오.
  2. 데이터파일 또는 리두 로그가 다른 위치 또는 다른 이름으로 복원 시 다음을 수행하십시오:
    -  인스턴스를 마운트하십시오.
    -  새로운 파일 위치를 가진 컨트롤 파일을 갱신하기 위해 “alter database”명령을 사용하십시오.

       SVRMGR> alter database rename file
            2>      ‘/disk1/data/user_01.dbf‘
            3>  to ‘/disk2/data/user_01.dbf‘ ;

주: UNIX 환경 하에서는 “alter database rename”명령을 사용하기 전에 파일들이 새로운 위치에 존재해야 합니다.

완전한 복구
archivelog 모드를 사용하는 데이터베이스에서 미디어 장애가 발생하여 장애 시점까지 완전하게 복구하기 위해 다음의 것들을 갖고 있어야 합니다:

복구 단계
완전한 복구를 위해 위의 모든 요구사항을 만족할 시 복구를 위해 다음 단계를 따르십시오:

  1. 덮어쓸 파일들이 복구동안 오픈되지 않도록 보장하십시오. 파일의 상태를 확인하기 위해 V$DATAFILE 및 V$TABLESPACE 뷰를 조회하십시오.
  2. 백업본으로부터 손실되었거나 손상된 파일만 복원하도록 유의 하십시오. 모든  파일을 복원 시 여러분의 데이터베이스는 과거 어느 시점으로 돌아갈 것 입니다. 온라인 리두 로그 파일을 복원하지 않도록 유의하십시오.
  3. 데이터베이스를 마운트 또는 오픈 모드로 돌리십시오.
  4. recover 명령을 사용하여 데이터베이스를 복구하십시오.
  5.  

장점 및 단점
다음 사항은 데이터베이스를 archivelog 모드로 실행시의 장점들과 단점들 입니다:

장점

단점
최근 백업 시점에서 현재 시점까지의 모든 아카이브로그를 갖고 있어야 합니다. 하나라도 없으면 완전한 복구를 수행할 수 없는데 이는 모든 아카이브들은 순차적으로 적용할 필요가 있기 때문입니다. 즉, 아카이브로그 144 다음에 145 그 다음에 146 등으로 적용해야 합니다.

완전 복구 방법
완전 복구를 수행 시 4가지의 다른 방법이 있습니다.

방법 1: 닫힌 데이터베이스 복구
이 복구 방법은 일반적으로 다음과 같은 경우 “recover database” 또는 “recover datafile” 명령을 사용합니다:

방법 2: 초기에 오픈 상태로 오픈 데이터베이스 복구
이 복구 방법은 일반적으로 다음과 같은 경우에 사용됩니다:

방법 3: 초기에 닫힌 상태로 오픈 데이터베이스 복구
이 복구 방법은 일반적으로 다음과 같은 경우 사용됩니다:

방법 4: 백업 없이 데이터파일 복구
이 복구 방법은 일반적으로 다음과 같은 경우 사용됩니다:

주: 복구동안 모든 아카이브 로그 파일들은 디스크상에 존재하며 오라클에 이용 가능할 필요가 있습니다. 만약 백업 테이프에 있다면 이것들을 먼저 복원해야 합니다.

Recover 구문
데이터베이스를 복구하기 위해 아래 명령들 중 하나가 사용될 수 있습니다:

주: “alter database” 는 “recover”명령 앞에 위치할 수 있습니다.

아카이브 로그 파일을 이용한 복구
복구 동안 데이터파일을 재구축하기 위해 필요한 아카이브 및 리두로그 파일들을 오라클은 수동으로 또는 자동적으로 적용할 수 있습니다. 리두 로그 파일 적용 전에 오라클은 적용할 로그파일 이름을 제시합니다.

아카이브를 다른 위치에 복원
만약 아카이브 로그가 LOG_ARCHIVE_DEST 디렉토리에 저장되지 않는 경우
오라클은 복구 전이나 복구 동안 다음 방법에 의해 통보 받을 필요가 있습니다.

자동적으로 리두로그 파일 적용

  1. 미디어 복구 시작 전에 다음 Server Manager 문장을 사용:
      SVRMGR > set autorecovery on
  2. 리두로그 파일 요청 프롬프트시 auto를 입력:
      SVRMGR > recover datafile 4;
      ORA-00279: change 308810...12/02/97/ 17:00:14 needed for thread 1
      ORA-00289: suggestion : /disk1/archive/arch_35.rdo
      ORA-00280: change 308810 for thread 1 is in sequence #35
      Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
      AUTO
      Log applied.
         ...
  3. 복구 명령에서 “automatic” 옵션 사용:
      SVRMGR  > recover automatic datafile 4;
      Media recovery complete. 

복구가 필요한 데이터파일 찾기
복구가 필요한 데이터파일 찾아서 복구가 필요 시 V$RECOVER_FILE 뷰를 사용하십시오.

  SVRMGR> select * from v$recover_file:
  FILE#  ONLINE   ERROR  CHANGE#   TIME
  -----  -------  -----  -------   ---------
      2  OFFLINE          288772   02-DEC-97

적용할 아카이브 로그 찾기
아카이브 로그 파일들을 찾기 위해 모든 아카이브에 대해 V$ARCHIVED_LOG 뷰를 사용하거나 복구동안 필요한 아카이브에 대해서는 V$RECOVERY_LOG 뷰를 사용합니다.
  SVRMGR> select * from v$recovery_log;
  THREAD#   SEQUENCE#  TIME        ARCHIVE_NAME
  -------   ---------  ---------   --------------------------
        1          34  02-DEC-97   /disk1/archive/arch_34.rdo
        ...           
        1          43  04-DEC-97   /disk1/archive/arch_43.rdo
        1          44  04-DEC-97   /disk1/archive/arch_44.rdo

  SVRMGR> recover datafile 2;
  ORA-00279 :  change 288772...12/02/97 15:32:29 needed for thread 1
  ORA-00289 :  suggestion : /disk1/archive/arch_34.rdo
  ORA-00280 :  change 288772 for thread 1 is in sequence #34
  Specify log :  {<RET>=suggested | filename | AUTO | CANCEL}

위 정보에서 34이후의 아카이브 로그들이 데이터 파일 2를 완전히 복구하기 위해 요구되어 집니다.

복구 방법
네 가지 방법 각각에 대해 데이터베이스 복구를 어떻게 하는지 이제 알아보기로 합니다.

완전 복구: 방법 1 (Closed Database)
손상된 블록은 데이터파일 2가 저장되어 있는 디스크 2에서 발견되었습니다. 잘 문서화 되어 있는 데이터베이스 레코드로부터 데이터파일 2가 시스템 테이블스페이스에 속하는 파일 중의 하나라는 것을 알았습니다. 따라서 방법 1이 아래와 같이 사용되어야 합니다:

  1. 백업으로부터 파일 복원(이용 가능할 시 가장 최근 것):
      UNIX>     !cp /disk1/backup/df2.dbf /disk2/data/
      NT> !copy c:\backup\df2.dbf d:\data\
  2. mount 모드로 인스턴스 기동 및 데이터파일 복구:
      SVRMGR> startup mount pfile=initDB00.ora
      or SVRMGR> recover datafile ‘\disk2\data\df2.dbf’;
      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.
     
  3. 장애 발생 시점으로 데이터파일을 복원하기 위해 모든 필요한 아카이브 로그 및 리두 로그가 적용됩니다.
  4. 복구가 완료될 시 모든 데이터파일들은 동기화 됩니다. 데이터베이스를 오픈합니다.
      SVRMGR> alter database open;

추후, 사용자에게 데이터베이스가 이용가능하며 시스템 장애 전의 커밋 안된 데이터는 재입력해야 한다고 알려 줍니다.

주

완전 복구: 방법 2 (오픈 데이터베이스, 초기 오픈)
수습중인 DBA가, 미디어 장애가 아니라  우연하게 운영체제 명령을 사용함으로써 데이터파일 2를 제거해 버렸다고 합니다. 데이터베이스는 현재 오픈되어 있으므로 데이터파일이 어느 테이블스페이스에 속하는지를 알기 위해 다음 명령을 사용합니다:

  SQL> select file_id f#, file_name,
    2> tablespace_name tablespace, status
    3> from dba_data_files;
   F#      FILE_NAME                 TABLESPACE    STATUS
   ----    ------------------------- ----------    ---------
      1    /disk1/data/system_01.dbf SYSTEM        AVAILABLE
      2    /disk2/data/df2.dbf       USER_DATA     AVAILABLE
      3    /disk1/data/rbs01.dbf     RBS           AVAILABLE
   ...

  1. 데이터파일이 시스템 또는 롤백 세그먼트 데이터파일이 아니므로 방법 2를 사용할 수 있습니다. 데이터파일 2를 오프라인으로 할 필요가 있는지 결정합니다(이 경우 오라클은 이 파일을 이미 오프라인 상태로 만들었습니다).
     SQL> select d.file# f#, d.name, d.status, h.status
       2> from v$datafile d, v$datafile_header h
       3> where d.file# = h.file#;
     F#   D.NAME                      D.STATUS   H.STATUS
     ---- -------------------------   --------   --------
        1 /disk1/data/system_01.dbf   SYSTEM     ONLINE
        2 /disk2/data/df2.dbf         RECOVER    OFFLINE
        3 /disk1/data/rbs_01.dbf      ONLINE     ONLINE
     ...
  2. 이 파일이 오프라인 상태이기 때문에 이 파일은 이제 성공적으로 복원될 수 있습니다.
      UNIX >     !cp /disk1/backup/df2.dbf /disk2/data/
      NT > !copy c:\backup\df2.dbf d:\data\
  3. 복원된 데이터파일에 아카이브와 리두로그를 적용하기 위해서 “recover” 또는 “alter database recover” 명령을 사용합니다.
      SVRMGR> recover datafile `/disk2/backup/df2.dbf`;
      or SVRMGR> recover tablespace USER_DATA;
  4. 복구가 완료되었을 때 모든 데이터파일은 동기화되며 데이터파일은 다음 명령을 사용함으로써  온라인 상태로 만듭니다.
      SVRMGR> alter database datafile
           2>      `/disk2/data/df2.dbf` online;
      or SVRMGR> alter tablespace USER_DATA online;

주

완전 복구: 방법 3 (Open Database, initialially closed)
조사를 해보니, 미디어 장애는 다행히도 디스크 2만 포함하는 디스크 컨트롤러의 장애로 결정을 내렸습니다. 데이터파일 2는 시스템 또는 롤백 세그먼트 데이터파일이 아니며 사용자로 하여금 월말 보고서 작업을 방해하지도 않습니다.

  1. 데이터베이스를 마운트하십시오. 데이터파일 2가 오픈될 수 없기  때문에 데이터베이스는 오픈되지 않을 것입니다.
      SVRMGR > startup mount pfile=$HOME/initDB00.ora
      Database mounted.
    만약 이 파일이 속하는 테이블스페이스 번호를 모른다면
      SVRMGR > select d.file#, d.ts#, h.tablespace_name, d.name,
            2> h.error
            3> from v$datafile d, v$datafile_header h
            4> where d.file# = h.file#;
      FILE# TS#  TABLESPACE  NAME                     ERROR
      ----- ---  ----------  ------------------------ --------------
          1   0  SYSTEM      /disk1/data/system01.dbf
          2   1              /disk2/data/df2.dbf      FILE NOT FOUND
          3   2  RBS         /disk1/data/rbs01.dbf
      ...
  2. 데이터파일이 오프라인이 아니라면 데이터베이스는 오픈되지 않을 것입니다. 따라서 이 파일은 오프라인이 되어야 합니다. V$DATAFILE을 조회해 본 결과 이 파일이 온라인 상태임을 알았습니다. 아래 명령이 사용되어야 합니다.
       SVRMGR> alter database datafile
            2>   `/disk2/data/df2.dbf` offline;
    주: “alter tablespace” 명령은 데이터베이스가 아직 오픈되지 않았기 때문에 여기서는  사용할 수 없습니다.
  3. 데이터베이스가 이제 오픈될 수 있습니다.
       SVRMGR > alter database open;
  4. 이제 사용자들이 시스템을 액세스할 수 있기 때문에 이 파일을 복원합니다. 손상된 디스크 2에는 복원할 수 없기 때문에 디스크 3에 복원합니다.
      UNIX >     !cp /disk1/backup/df2.dbf /disk3/data/
      NT > !copy c:\backup\df2.dbf e:\data\

    오라클은 이제 새로운 파일 위치에 관해 통보를 받아야 합니다.
     SVRMGR> alter database rename file `/disk2/data/df2.dbf`
          2> to `/disk3/data/df2.dbf`;

    데이터베이스가 오픈되고 테이블스페이스 복구가 요구될 때 이 데이터파일을 소유하고 있는 테이블스페이스의 이름을 알기 위해 다음 명령을 사용합니다:
     SQL> select file_id f#, file_name,
       2> tablespace_name tablespace, status
       3> from dba_data_files;
        F# FILE_NAME                 TABLESPACE STATUS
       --  ------------------------- ---------- --------
        1  /disk1/data/system_01.dbf SYSTEM     AVAILABLE
        2  /disk3/data/df2.dbf       USER_DATA  AVAILABLE
        3  /disk1/data/rbs01.dbf     RBS        AVAILABLE
  5. 복원된 데이터파일에 아카이브 및 리두 로그 적용을 개시하기 위해 “recover” 또는 “alter database recover” 명령을 사용하십시오.
      SVRMGR> recover datafile `/disk3/data/df2.dbf`;
      or SVRMGR> recover tablespace USER_DATA;
  6. 복구가 완료되었을 때 모든 데이터파일은 동기화됩니다. 데이터파일을 온라인으로 돌리십시오.
      SVRMGR> alter database datafile
           2>   `/disk3/data/df2.dbf` online;
      or SVRMGR> alter tablespace USER_DATA online;
  7. 사용자들에게 데이터베이스가 이용가능하고 시스템 장애 전의 커밋이 안된 데이터는 재입력하라고 통보하십시오.

완전 복구: 방법 4 (백업 없는 데이터파일의 손실)
데이터파일 7(디스크 1에 존재)이 손실되었기에 즉각 백업 테이프를 복원해야 합니다. 그러나 복원 중에 해당 파일이 백업되지 않았다는 에러를 만납니다. 어떤 DBA가 이틀 전에 TABLE_DATA라는 테이블스페이스를 생성하고 나서 백업 전략에 그 테이블스페이스 안의 중요한 사용자 데이터를 포함하지 않았던 것을 발견했습니다. 데이터파일 7은 시스템 또는 롤백 세그먼트 데이터파일이 아니고 과거 이틀 동안의 모든 아카이브 로그를 갖고 있으므로 방법 4가 최대의 선택입니다.

  1. 데이터베이스가 close 되었다면 데이터베이스를 마운트하고 데이터파일(백업 없음)을 오프라인으로 하고 데이터베이스를 오픈하십시오. 이렇게 함으로써 TABLE_DATA 테이블스페이스가 필요 없는 사용자들이 계속해서 시스템을 사용할 수 있도록 해 줍니다. 데이터베이스가 오픈되어 있다면 데이터파일만 오프라인으로 만드십시오. 하나의 데이터파일만 포함하고 있기 때문에 이 테이블스페이스를 오프라인으로 해도 될 것입니다.

    주: 존재하지 않는 파일에 쓰기를 시도하는 체크포인트를 피하기 위해 immediate  옵션이 포함되어야 합니다.

     SVRMGR> alter tablespace TABLE_DATA offline immediate;
     Statement Processed.

    백업의 상태를 점검하기위해 V$RECOVER_FILE을 검색함으로써  복구 상태를 확인합니다.
      SVRMGR> select * from v$recover_file;
      FILE#  ONLINE   ERROR           CHANGE#  TIME
      -----  -------  --------------  -------  -----
          7  OFFLINE  FILE NOT FOUND        0
  2. 여러분은 이제 이 파일을 재생성할 필요가 있습니다.
      SVRMGR> alter database create datafile ‘/disk2/DATA/df7.dbf’
                    as ‘/disk1/DATA/df7.dbf‘;
      Statement processed.
      SVRMGR> select * from v$recover_file;
      FILE#  ONLINE   ERROR           CHANGE#  TIME
      -----  -------  --------------  -------  ---------
          7  OFFLINE                   248621  01-DEC-97
  3. 재생성된 데이터파일에 아카이브와 리두 로그 적용을 개시하기위해 “recover” 또는 “alter database recover” 명령을 사용하십시오.
      SVRMGR> recover tablespace TABLE_DATA;
  4. 장애 시점으로 데이터파일을 가져오기 위해 모든 필요한 아카이브 로그  및 리두 로그가 적용됩니다.
  5. 모든 데이터파일은 이제 동기화 됩니다.
  6. 복구가 완료되면 데이터파일을 온라인으로 만드십시오. (우리는 단 하나의 데이터파일을 온라인 상태로 만들 수 있습니다. 데이터파일 대신에 step1에서  테이블스페이스를 사용하고 있다는 것을 기억하십시오.)
      SVRMGR> alter tablespace TABLE_DATA online;

모든 데이터가 이제 복구 되었습니다. 백업 전략에 이 파일을 포함시키고 해당 테이블스페이스가 다시 사용 가능한 상태가 되었다고 통보하십시오.

Open Database Backup" 동안 장애
오픈 데이터베이스 백업 동안 시스템이 다운될 수 있고 전원이 나갈 수도 있으며 데이터베이스 종료 등이 발생할 수 있습니다. 이런 일이 발생시

"Backup Mode"에서 데이터파일의 복구
이 시나리오로 복구하기 위해 다음과 같은 두 가지 방법이 있습니다.

문제점
"alter tablespace" 명령은 데이터베이스가 오픈될 때까지 사용될 수 없으며 데이터베이스는 파일들이 동기화되어 오프라인이 될 때까지 오픈될 수 없습니다. 파일들을 오프라인으로 하는 것은 소용이 없는데 이는 "alter tablespace end backup"이 오프라인 상태인 데이터파일에 대해 수행될 수 없기 때문입니다.

해답
어떤 파일이 복구될 필요가 있는지 없는지 확인할 수 없거나 또한 파일이 “hot backup” 모드에 있다면 다음과 같이 V$BACKUP 뷰를 조회합니다.
  SVRMGR> select * from v$backup;
  FILE#   STATUS       CHANGE#   TIME
  -----   ----------   -------   ---------
      1   NOT ACTIVE         0
      2   ACTIVE        228596   30-NOV-97
      3   NOT ACTIVE         0
      4   NOT ACTIVE         0

이것은 파일 2가 현재 “hot backup” 모드에 있음을 의미합니다. 헤더를 풀기(unfreeze)위해 단순히 다음 명령을 사용합니다.
  SVRMGR> alter database datafile 2 end backup;
  Statement processed.  
  SVRMGR> select * from v$backup;
  FILE#   STATUS       CHANGE#   TIME
  -----   ----------   -------   ---------
      1   NOT ACTIVE         0      
      2   NOT ACTIVE    228596   30-NOV-97
         ...

이제 사용자를 위해 데이터베이스를 오픈합니다.
  SVRMGR> alter database open;

손상된 리두 로그 제거
온라인 리두 로그 파일이 데이터베이스가 오픈되어 있는 동안 손상되었다면 “alter database clear logfile” 명령을 사용하여 데이터베이스를 종료할 필요 없이 이 파일들을 생성 또는 제거할 수 있습니다.

“Alter database clear unarchived logfile” 명령
이 명령은 다음과 같이 리두 로그를 삭제하는 게 불가능한 두 가지 경우를 극복해 줍니다:

이 명령은 또한 데이터베이스가 오픈되어 있는 동안 손상된 로그파일을 재생성하거나 손상된 로그 파일을 제거하기 위한 효율적인 방법을 제공해 줍니다.

주

오프라인 데이터파일에 의해 요구되는 로그 제거
오프라인 데이터파일이 복구를 위해 로그를 요구한다 할지라도 리두 로그 파일을 제거하기 위해 “alter database clear logfile... unrecoverable datafile” 명령을 사용하십시오. 이런 경우는 드물지만 발생시 다음과 같은 두 가지 접근 방법이 있습니다:

주

비활성화 리두 로그의 손실
리두 로그가 손실되거나 손상된다면 장애 직전 시점으로 복구가 불가능할 수도 있습니다. 그러나 다음과 같은 경우에는 아무런 데이터도 손실되지 않습니다:

복구 필요성 결정
당신은 데이터베이스를 생성하는데 4 시간을 보내 왔고 데이터베이스를 archivelog 모드로 운영하기로 결정하였습니다. DBA의 업무에 충실하기 위해 시스템의 아카이브 로그 생성을 시험해 보고자 결정합니다. 로그를 수동으로 전환하기 위해 “alter system” 명령을 사용합니다. 이 경우 다음 에러 메세지를 받습니다:
   SVRMGR> alter system switch logfile;
   ORA-00470: LGWR process terminated with error 

백그라운드 프로세스가 비정상적으로 종료되고 인스턴스가 종료되었다는 사실을 즉각 깨달았습니다. 백업은 갖고 있지 않고 데이터베이스를 재생성하기 위해 추가의 4 시간을 보내기를 원치 않습니다. 따라서 여러분은 인스턴스를 다음과 같이 재개 시킵니다.
   SVRMGR> startup pfile=$HOME/initDB00.ora
   ORACLE instance started.
   ...
   ORA-00313: open failed for members of log group 1 of thread 1
   ORA-00312: online log 1 thread 1: `/disk2/DATA/log1a.rdo`

리두 로그 상황의 심각성을 결정하기위해 V$LOG를 조회하고 다음과 같은 3가지 중요 사실을 알게 되었습니다.
   SVRMGR> select * from v$log;
   GROUP#  THREAD#... BYTES  MEMBERS  ARC  STATUS   FIRST_CHAN
   ------  -------   ------  -------  ---  -------  ----------
       1         1   153600        1  YES  UNUSED            0
       2         1   153600        1  NO   CURRENT      248720

당신은 운영체제 파일을 찾으려고 시도합니다. 그러나 이 파일이 존재하지 않습니다. 어떠한 정보도 손실되지 않았으므로 (오직 로그 파일만) 어떠한 복구도 요구되지 않습니다.
--- 오직 로그 파일이 재생성 되어야 합니다. 

리두 로그 재생성
데이터베이스는 리두 로그가 재생성될 때까지 오픈되지 않을 수도 있습니다. 이 상황을 다음 명령을 사용함으로써 조속히 해결할 수 있습니다:

  1. 파일이 이전에 위치했던 장소를 찾습니다:
      SVRMGR> select * from v$logfile;
      GROUP#  STATUS  MEMBER
      ------  ------  ------------------------
           2          /disk1/DATA/log2a.rdo
           1  STALE   /disk1/DATA/log1a.rdo
  2. 항상 적어도 2개의 로그 그룹이 존재해야 하므로 로그 그룹을 삭제할 수   없습니다:
      SVRMGR> alter database drop logfile group 1;
      alter database drop logfile group 1
      *
      ORA-01567: dropping log 1 would leave less than 2 log files ...
      ORA-00312: online log 1 thread 1: `/disk1/DATA/log1a.rdo`
      
    따라서, 다음과 같이 다른 하나의 임시 그룹을 생성해야 합니다:
      SVRMGR> alter database add logfile group 3
            > `/disk1/DATA/log3a.rdo` size 150k;
      Statement processed.
  3. 해당 로그 그룹을 이제 삭제하십시오:
      SVRMGR> alter database drop logfile group 1;
      Statement processed.
  4. 로그를 재생성 하십시오.
      SVRMGR> alter database add logfile group 1;
            > `/disk1/DATA/log1a.rdo` size 150k;
      Statement processed.
  5. 기타 로그 그룹을 삭제하십시오.
      SVRMGR> alter database drop logfile group 3;
      Statement processed.
  6. 그 다음에 이 파일을 운영체제로부터 물리적으로 제거하십시오.
      $ rm /disk1/DATA/log3a.rdo
  7. 데이터베이스를 오픈하십시오.
      SVRMGR> alter database open;
  8. 즉시 모든 리두 로그를 다중화 하십시오. 이것은 데이터 손실의  가능성을 줄여 줄 것입니다.

온라인 리두 로그 제거
두개의 로그 그룹이 같은 크기일 때 단계 2에서 7은 다음과 같은 2개의 단일 명령으로 묶을 수 있습니다.
 SVRMGR> !cp /disk1/DATA/log2a.rdo /disk1/DATA/log1a.rdo
 SVRMGR> alter database clear logfile `/disk1/DATA/log1a.rdo`;

복구 상태 정보
미디어 복구를 수행하고 있는 서버 프로세스와 사용자에게 상태 정보를 제공하고 있는 다음과 같은 2개의 데이터베이스 뷰들이 있습니다:

주: 이 뷰들에 대한 정보는 “alter database recover” 명령 수행 시 서버 프로세스의 PGA에 존재합니다. 따라서 어떤 다른 세션도 복구 정보를 볼 수 없습니다.

복구 상태 예
데이터파일 2를 손실한 이전 예에서 이제 다음과 같이 복구 정보를 조회하는 동안 복구 명령을 수행할 것입니다.

  SVRMGR> alter database recover datafile 2;
  alter database recover datafile 2
  *
  ORA-00279: change 148448...11/29/97/ 17:04:20 needed for thread 1
  ORA-00289: suggestion : /disk1/archive/arch_6.rdo
  ORA-00280: change 148448 for thread 1 is in sequence #6

  SVRMGR> select * from v$recovery_status;
  RECOVERY   THREAD  SEQ_NEEDED  SCN_NEEDED  TIME_NEED  PREV_LOG
  ---------  ------  ----------  ----------  ---------  --------
  29-NOV-97       1           6  0           29-NOV-97  NONE
  1 row selected.

  SVRMGR> select * from v$recovery_file_status;
  FILENUM  FILENAME               STATUS
  -------  ---------------------  ---------------
        6  /disk1/data/df2.dbf    IN RECOVERY
  1 row selected.

다음과 같이 실제 복구를 수행합니다.
 SVRMGR> alter database recover
      2> automatic logfile `/disk1/archive/arch_6.rdo`;
 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.
 SVRMGR> select * from v$recovery_status;
 RECOVERY   THREAD  SEQ_NEEDED  SCN_NEEDED  TIME_NEED  PREV_LOG
 --------   ------  ----------  ----------  ---------  --------
 0 rows selected.
 SVRMGR> select * from v$recovery_file_status;
 FILENUM  FILENAME   STATUS
 -------  --------   ------
 0 rows selected.

X 정답:D


O


X 정답:ABC


O


X 정답:D


O


O