2009년 9월 25일 금요일

ORACLE_020. Making User Managed Backups_Part I

Making User Managed Backups_Part I


Querying V$ Views to Obtain Backup information

 listing Database Files before Backup
 백업을 수행하기 전 어떤 파일을 백업해야 할지 데이터 베이스에 쿼리를 수행하여 확인합니다.

 데이터 파일, 온라인 리두, 콘트롤 파일 출력하기
 
1. SQL*Plus 를 시작하고 V$DATAFILE 뷰를 통해 데이터파일 리스트를 확인합니다.
   SQL> SELECT NAME FROM V$DATAFILE;

  조인 구문을 통해 데이터파일과 연관된 테이블 스페이스도 확인할 수 있습니다.
   SQL> SELECT t.NAME "Table Space", f.NAME "Data File"
          FROM V$TABLESPACE t, V$DATAFILE f
          WHERE t.TS#=f.TS# ORDER BY t.NAME;

 2. V$LOGFILE 뷰를 통해 온라인 리두 로그 파일의 목록을 확인할 수 있습니다.
   SQL> SELECT MEMBER FROM V$LOGFILE;

 3. V$CONTROLFILE 뷰를 통해 콘트롤 파일의 데이터 파일명을 확인 가능 합니다.
   SQL> SELECT NAME FROM V$CONTROLFILE;

 4. ALTER DATABASE BACKUP CONTROLFILE TO 'filename' 구문으로 콘트롤 파일을 백업
   하기로 결정했다면 모든 데이터파일과 온라인 리두 로그 파일을 보관해야 합니다. 이는 현
   데이터베이스 구조가 콘트롤 파일이 만들어졌을때의 구조와는 다를 수 있기 때문입니다.

 Determining Datafile Status for Online Tablespace Backups
 데이터 파일이 현 데이터베이스의 온라인 테이블 스페이스 백업인지 아닌지 확인하기 위해 V$BACKUP 뷰를 확인합니다. 이 뷰는 오직 사용자 관리 백업에서만 효용성을 지닙니다. 오프라인 테이블스페이스 백업이나 RMAN백업과는 상관 없습니다.

 V$BACKUP 뷰는 데이터베이스가 OPEN 상태일따 가장 유용합니다. 또한 인스턴스가 Failure되었을때 참조하기 좋은데 이는 인스턴스 Failure 가 났을 당시 파일의 백업상태를 보여주기 때문입니다. 이 정보들을 이용하여 어떤 테이블 스페이스를 백업 모드로 남겨두어야 할지 결정할 수 있습니다.

 V$BACKUP은 현재 사용하는 콘트롤 파일이 미디어 실패 이후 복구된 것 이라면 쓸모가 없어집니다. 복구되거나 혹은 재생성된 콘트롤 파일에는 V$BACKUP 뷰를 채워줄 어떠한 정보도 가지고 있지 않기 때문입니다. 또한 데이터 파일을 복구하였을 경우, V$BACKUP 뷰에서 이 파일의 STATUS는 최신 버전의 상태가 아닌 오래된 버전의 상태를 나타내게 됩니다. 그러므로 이 뷰는 자칫 복구된 파일들에 대해 오해를 일으킬 수 있습니다.

 다음 예제는, 데이터파일과 그에 해당되는 테이블 스페이스가 백업 모드로 되어 있는지 여부를 출력합니다.

 SQL> SELECT t.name "TB_NAME", d.file# "DF#", d.name "DF_NAME", b.status
        FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
        WHERE d.TS#=t.TS#
        AND b.FILE#=d.FILE#
        AND b.STATUS='ACTIVE';

 STATUS 컬럼이 NOT ACTIVE 로 되어 있으면 이 파일은 현제 백업 모드에 있지 않다는 것을 의미합니다. ALTER TABLESPACE ... BEGIN BACKUP 으로 상태를 바꾸어 줄 수 있습니다.



Making User-Managed Backups of the Whole Database

 데이터베이스를 Shutdown 시킨후 데이터베이스의 모든 파일을 백업 할 수 있습니다. 전체 백업을 SHUTDOWN ABORT 후, 데이터베이스가 열린상태, 혹은 인스턴스 실패후 하는 것은 좋지 않습니다. 이러한 경우 체크포인트 SCN과 파일이 일치하지 않게 되기 때문입니다.

 ARCHIVELOG MODE나 NOARCHIVELOG MODE중 하나로 운영하고 있다면 전체 백업을 받을 수 있습니다. 다만 NOARCHIVELOG MODE라면 반드시 백업은 일관성을 유지해야 합니다. 이는 백업을 수행하기전에 반드시 데이터베이스를 SHUTDOWN 시켜야 함을 의미합니다.

 전체 데이터베이스 백업에 의해 생긴 데이터 파일은 체크포인트 SCN이 모두 같기때문에 일관성을 가지고 있습니다. 복구작업이 없이 데이터베이스를 모순없이 복원할 수 있습니다. 백업 파일을 복원후 ARCHIVELOG 모드를 사용중이라면 복원시점에 맞게 복구작업을 추가로 수행할 수 있습니다. 또한 ARCHIVELOG 모드를 사용중이라면 일관성에 상관없이 전체 데이터베이스 백업을 받을 수 있습니다.

 콘트롤 파일은 데이터베이스의 복원과 복구에 중요한 역할을 담당합니다. 데이터베이스가 ARCHIVELOG로 운영되고 있다면 ALTER DATABASE BACKUP CONTROLFLE TO 'FILENAME' 구문으로 콘트롤 파일을 백업하길 권장합니다. OS 유틸리티가 닫혀있는 동안 콘트롤 파일과 전체 데이터베이스를 백업했다면 복원시 반드시 이 콘트롤 파일을 사용해야 합니다.



Making Consistent Whole Database Backups

 데이터베이스의 일관성을 보장하기 위해 NORMAL, IMMEDIATE, TRANSACTIONAL 옵션을 이용하여 데이터베이스를 SHUTDOWN 시키기 바랍니다.

    *NOARCHIVELOG 상태라면 인스턴스가 실패하거나 ABORT 로 SHUTDOWN 시킨 후에는
    전체 백업을 받지 마십시요!

 일관성을 유지한 전체 데이터베이스 백업 절차
  1. 데이터베이스가 OPEN 상태이면 SHUTDOWN 시킵니다.
    SQL>shutdown normal
    SQL>shutdown immediate
    SQL>shutdown transactional

  2. OS명령어를 이용하여 콘트롤 파일을 포함한 모든 데이터 파일을 복사합니다. (예)
    % cp /disk1/oracle/dbs/*.dbf /disk2/backup

  3. 데이터베이스를 재기동 합니다.
    SQL>STARTUP



Making User Managed Backups of Offline Tablespace and Datafiles

 테이블스페이스가 OFFLINE 상태라면 모든 데이터 파일 혹은 각각 개별적인 테이블스페이스의 데이터파일을 백업할 수 있습니다. 테이블 스페이스를 ONLINE/OFFLINE 시키려면 DBA 권한, 혹은 MANAGE TABLESPACE 시스템 권한이 요구됩니다.

 오프라인 테이블 스페이스를 백업하는 절차
 1. 테이블스페이스를 백업하기 전 DBA_DATA_FILES 뷰를 이용해 테이블 스페이스의 데이터
  파일을 확인합니다.
  SQL>SELECT TABLESPACE_NAME, FILE_NAME
        FROM SYS.DBA_DATA_FILES
        WHERE TABLESPACE_NAME='users';

 2. NORMAL로 테이블스페이스를 OFFLINE가능하면 그렇게 하십시요. NORMAIL로 OFFLINE
  시키면 후에 ONLINE 시킬시 추가적인 테이블 스페이스 복구작업이 필요하지 않게 됩니다.
   SQL>ALTER TABLESPACE user OFFLINE NORMAL;

  NORMAL로 OFFLINE 시키면 테이블스페이스가 가진 모든 데이터 파일이 OFFLINE 됩니다.

 3. OFFLINE된 데이터 파일을 백업하십시요. OS 명령을 이용하면 됩니다.
  % cp /disk1/oracle/dbs/user.dbf /disk2/backup/user.dbf.backup (예)

 4. OFFLINE된 테이블 스페이스를 ONLINE 시킵니다.
  SQL>ALTER TABLESPACE user ONLINE;

 5. 백업한 테이블스페이스로 후에 복구작업을 하기 위해 아카이빙 되지 않은 리두로그를
  아카이빙 합니다.
  SQL>ALTER SYSTEM ARCHIVE LOG CURRENT;



Making User-Managed Backups of Online Tablespaces and Datafiles
 
 Making User-Managed Backups of Online Read/Write Tablespace
 데이터베이스가 오픈상태이고 테이블스페이스가 온라인일 경우에서의 사용자 백업을 받기 위해서는 테이블 스페이스를 반드시 백업 모드로 전환시켜 주어야 합니다. ALTER TABLESPACE BEGIN BACKUP구문은 테이블 스페이스를 백업모드로 전환시켜 줍니다.

 테이블스페이스가 백업모드로 들어가면 오라클은 더이상 데이터 파일에 체크포인트를 기록하지 않습니다. OS의 백업 유틸리티 동안 많은 순간에 부분적인 업데이트가 일어날 수 있기 때문에, 오라클은 백업 모드에서 리두 스트림에 모든 바뀐 데이터 블록을 카피합니다. ALTER TABLESPACE END BACKUP 혹은 ALTER DATABASE END BACKUP 구문으로 백업 모드를 빠져나오게 되면 데이터파일의 헤더에 현재 데이터 베이스의 체크포인트를 기록합니다.

 이 방법으로 백업 데이터 파일을 복원하면 데이터파일 헤더는 온라인 테이블스페이스 백업 전의 가장 최근의 체크포인트가 기록됩니다. (백업하는 동안의 체크포인트가 아닙니다.) 결과적으로 오라클은 복구하기 위해 리두 파일을 요구하게 됩니다. 리두 로그 파일은 데이타파일을 복원하고 일관성을 유지하기 위한 모든 변화에 대한 정보를 가지고 있습니다.

 운영중에 온라인 READ/WRITE 테이블 스페이스 복원하기
 1. DBA_DATA_FILES 뷰를 통해 백업할 테이블 스페이스와 데이터파일을 확인합니다.
  SQL>SELECT TABLESPACE_NAME, FILE_NAME
        FROM SYS.DBA_DATA_FILES
        WHERE TABLESPACE_NAME='users';

 2. 해당 테이블 스페이스를 백업모드로 만듭니다.
   SQL>ALTER TABLESPACE users BEGIN BACKUP;

 3. OS명령을 통해 해당 테이블스페이스의 데이터 파일을 백업합니다.

  % cp /oracle/dbs/tbs_21.dbf /oracle/backup/tbs_21.dbf.backup

 4. 백업이 끝났으면 ALTER TABLESPACE END BACKUP 구문을 통해 백업 모드에서 빠저 나
   옵니다.
  SQL>ALTER TABLESPACE users END BACKUP;

 5. 로그를 아카이브 합니다!
  SQL>ALTER SYSTEM ARCHIVE LOG CURRENT;



Making Multiple User-Managed Backups of
                                          Online Read/Write Tablespaces

 Backing Up Online Tablespace in Parallel
 백업할 테이블 스페이스를 백업 모드로 전환합니다. 여러명의 사용자가 이 테이블스페이스를 업데이트 한다면 온라인 리두 로그가 매우 커질 수 있음에 유의하십시요. 왜냐하면 리두 로그는 각각의 데이터 블록에 대한 변화를 기록해 놓아야 하기 때문입니다.

 온라인 테이블 스페이스 백업하기 (In Parallel)
 1. 백업할 테이블 스페이스를 백업 모드로 전환합니다.
  SQL> ALTER TABLESPACE ts1 BEGIN BACKUP;
  SQL> ALTER TABLESPACE ts2 BEGIN BACKUP;

 2. OS 명령어로 각각의 테이블 스페이스가 포함하고 있는 데이터 파일을 백업합니다.
  % cp /oracle/dbs/tbs_* /oracle/backup/

 3. 백업 모드에서 빠저 나옵니다.
  SQL> ALTER TABLESPACE ts1 END BACKUP;
  SQL> ALTER TABLESPACE ts2 END BACKUP;

 4. 로그를 아카이빙 시킵니다.
  SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

 Backing Up Online Tablespace Serially
 한번에 하나의 온라인 테이블 스페이스를 백업할 수 있습니다. 이 방법은 ALTER TABLESPACE BEGIN/END BACKUP 구문 사이의 소요되는 시간이 짧기 때문에 권장되는 방법 입니다. 온라인 백업이 수행되는 동안 모든 데이터블럭에 대한 변경사항이 리두로그에 기록이 되므로 리두 로그 파일이 커질 수 있습니다.

 온라인 테이블 스페이스를 백업하기 (In Serial)
 1. 백업할 온라인 테이블 스페이스를 백업 모드로 둡니다.
  SQL> ALTER TABLESPACE ts1 BEGIN BACKUP;

 2. OS명령어로 테이블 스페이스가 포함하고 있는 데이터 파일을 백업합니다.
  % cp /oracle/dbs/tbs1.dbf /oracle/backup/

 3. 백업 모드에서 빠저나옵니다.
  SQL> ALTER TABLESPACE ts1 END BACKUP;

 4. 또다른 백업할 테이블이 있으면 1-3번을 반복합니다.

 5. 로그를 아카이빙 시킵니다.
  SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;



Ending a Backup After an Instance Failure or SHUTDOWN ABORT

 About Instance Failures When Tablespaces are in Backup Mode
 다음과 같은 상황은 테이블 스페이스 백업이 실패하거나 불완전하게 종료될 수 있습니다.

  - 백업이 끝났지만 ALTER TABLESPACE END BACKUP 을 수행하지 않은 경우
  - 백업이 끝나기 전에 인스턴스 실패, 혹은 SHUTDOWN ABORT 를 한 경우

 언제든지 장애복구는 필요합니다. (인스턴스 복구가 아닙니다. 이 경우는 이미 데이타 파일이 열린 경우 입니다.) 데이터파일이 백업 모드에 있을때 데이터파일을 열려고 시도할 경우 시스템은 이 데이터 파일이 백업본으로부터 복원된 파일이라 간주합니다. 따라서 오라클은 복구 명령이 떨어지기 전까지 데이터베이스를 오픈하지 않습니다. (혹은 데이터 파일이 백업 모드에서 벗어나기 전 까지 이거나 말이죠.)

 예를들어 위 상황에서 데이터베이스에 STARTUP 명령을 내리면 다음과 같은 에러 메세지를 뿌립니다.

  ORA-01113: file 12 needs media recovery
  ORA-01110: data file 12: '/oracle/dbs/tbs_41.f'

 만약 오라클이 여러개의 테이블 스페이스에 대한 데이터 파일이 미디어 복구를 카르키면 테이블 스페이스에 대한 온라인 백업의 끝을 선언해 주지 않았기 때문입니다. 따라서 ALTER DATABASE END BACKUP 구문을 입력하면 모든 데이터 파일에 대한 백업 모드에서 빠저나오게 해 줍니다.

 높은 가능성을 가진 상황들중 하나인 어떤 DBA도 모니터링을 하지 않는 상황에서 (예를들어 매우 이른 아침) 사용자 개입이 요구되어집니다. 그러므로 다음과 같은 복구 스크립트를 짜놓습니다.

  1. 데이터베이스 마운트
  2. ALTER DATABASE END BACKUP 구문 수행
  3. ALTER DATABASE OPEN 구문으로 자동으로 시스템 가동

 ALTER DATABASE END BACKUP 구문이 포함된 자동 스크립트는 특별히 다음과 같은 상황에서 굉장히 유용합니다.

  - Oracle Real Application Clusters 하의 모든 노드 환경설정 실패
  - Cold Failover Cluster 의 한개의 노드 실패

 테이블 스페이스가 백업 모드로 있음으로서 발생하는 시스템 실패후 다음 대안을 통해서 해결할 수 있습니다.

  - 데이터베이스를 복구하여 모두 END BACKUP 구문을 입력하지 않는 방법
  - 데이터베이스를 마운트 상태로 하여 ALTER TABLESPACE ..END BACKUP을 통해 각각의
   테이블 스페이스를 백업모드에서 빠저나오는 방법

 Ending Backup Mode with the ALTER DATABASE END BACKUP Statement
 여전히 여러개의 테이블 스페이스가 백업 모드로 존재할때 ALTER DATABASE END BACKUP 구문을 이용할 수 있습니다. 이 구문의 주 목적은 DBA가 자리에 없을때 복구 스크립트를 이용하여 시스템을 재시작 할 수 있게 함 입니다. 또한 다음 과정을 통해 직접 수행할 수 있습니다.

 테이블스페이스를 백업 모드에서 빠저나오게 하기
 1. 마운트 까지만 데이터베이스를 유지합니다. 오픈하지는 않습니다.
  SQL>STARTUP MOUNT

 2. V$BACKUP 뷰를 확인하여 백업 모드에 있는 테이블 스페이스를 확인합니다.
  SQL>SELECT * FROM V$BACKUP WHERE STATUS='ACTIVE';

 3. 많은 수의 테이블 스페이스가 백업 모드라면 다음 구문을 입력합니다.
  SQL>ALTER DATABASE END BACKUP;

  이 구문은 마운트 상태에서는 가능하지만 오픈 상태에서는 불가능 합니다. 오픈상태에선
  ALTER TABLESPACE .. END BACKUP 구문을 일일이 입력해 주어야 합니다.

 Ending Bakcup Mode with the RECOVER Command
 ALTER DATABASE END BACKUP 구문은 온라인 백업실패시 사용할 수 있는 유일한 방법은 아닙니다. RECOVER 명령을 통해서도 가능합니다. 이 방법은 다른 누군가가 백업본을 복원했는지 확실치 않을때 매우 유용하게 사용할 수 있습니다. 만약 누군가가 실로 백업을 복원하였다면 RECOVER 명령은 백업본을 업데이트 합니다. 오직 해당 파일이 CURRENT 인 경우에만 ALTER DATABASE END BACKUP, ALTER TABLESPACE END BACKUP 구문을 이용하십시요.

 RECOVER 명령으로 백업모드 끝내기
 1. 마운트 상태로 돌입합니다
  SQL>STARTUP MOUNT

 2. 일반적인 방법으로 데이터베이스를 복구합니다.
  SQL>RECOVER DATABASE

 3. V$BACKUP 구문을 통해 ACTIVE 상태인 데이터 파일이 없는지 확인합니다.
  SQL>SELECT * FROM V$BACKUP WHERE STATUS='ACTIVE';



Making User-managed Backups of Read-Only Tablespace

 온라인 읽기 전용 테이블 스페이스를 백업할때 온라인 데이터파일을 간단히 백업할 수 있습니다. 테이블 스페이스를 백업 모드로 둘 필요도 없습니다. 시스템이 데이터파일을 변경하는 것을 허락하지 않기 때문입니다.

 읽기 전용 테이블 스페이스들이 독립적이라면 (그래서 추가적으로 OS 명령어를 통해 백업을 수행중이라면) 수송 테이블(transportable tablespace)을 이용하여 테이블스페이스의 메타데이타를 추출할 수 있습니다. 미디어 에러나 사용자 에러(읽기 전용 테이블 스페이스에서 테이블이 드롭된 경우) 테이블 스페이스를 데이터베이스로 다시 전송할 수 있습니다.

 오픈 데이터베이스에서 읽기 전용 테이블스페이스 백업하기
 1. DBA_TABLESPACES뷰를 통해 읽기 전용 테이블을 확인합니다.
  SQL>SELECT TABLESPACE_NAME, STATUS
        FROM DBA_TABLESPACES
        WHERE STATUS='READ ONLY';

 2. 읽기 전용 테이블 스페이스를 백업하기 전에 DBA_DATA_FILES 뷰를 통해 테이블스페이
  스의 데이터 파일 확인합니다.
  SQL>SELECT TABLESPACE_NAME, FILE_NAME
       FROM SYS.DBA_DATA_FILES
       WHERE TABLESPACE_NAME='HISTORY';

 3. OS명령어로 데이터파일을 백업합니다.
  % cp /oracle/dbs/tbs_hist*.f /backup

 4. 선택적으로, 읽기 전용 테이블의 메타 데이터를 추출합니다. 전송 테이블을 사용함으로서 미디어 실패나 사용자 에러의 경우 빠르게 데이터 파일을 복원할 수 있고, 메타데이터를 임포트 할 수 있습니다.
  % exp TRANSPORT_TABLESPACE=y TABLESPACE=(history) FILE=/backup/tbs_hist.dmp


Making User-Managed Backups of Undo Tablespace

 9i버전 이전에는 언두 스페이스의 관리는 롤백 세그먼트에 기반하였습니다. 이 방법은 Manual undo management mode 라 불리었습니다. 9i 부터 데이터 베이스를 Auto undo management mode 상태로 둘 수 있습니다. 이 방법은 롤백 세그먼트를 데이터셋에 정적으로 분배하는 방식 대신에 하나의 언두 테이블스페이스에 언두 공간을 할당하는 방식입니다.

 언두 테이블스페이스를 백업하는 방법은 읽기/쓰기 테이블 스페이스의 백업 방법과 동일합니다. 자동 언두 테이블스페이스는 복구와 읽기 일관성에 있어서 매우 중요하기 때문에 수동 언두 테이블스페이스 모드로 수행중일때 롤백 세그먼트를 포함한 테이블 스페이스를 백업하는 것 처럼 자주 백업을 하는게 좋습니다.

 데이터베이스가 운영중일때 언두 테이블스페이스를 잃게 되고 백업본이 없다면 커밋(commit) 되지 않은 오브젝트에 쿼리를 수행시 에러 메세지를 보게 될 것 입니다. 또한 인스턴스 실패가 발생시, 커밋되지 않은 트렌젝션을 다시 원래값으로 되돌릴 수 없게 됩니다.

- Continue

댓글 없음:

댓글 쓰기