1. 2019.01.01 PostgreSQL 백업 및 복원
  2. 2018.11.08 Netbackup 연동 RMAN 복원 테스트

PostgreSQL 백업 및 복원



PostgreSQL 백업 및 복원


 - PostgreSQL 데이터를 백업하는 3가지 방법

 

 1. SQL 덤프

 2. 파일 시스템 레벨 백업

 3. 연속 아카이빙


 

1. SQL 덤프


pg_dump 사용


 덤프 백업


 $ pg_dump dbname > outfile


 - pg_dump 는 최신 버전에서 다시 로드 할 수 있습니다.

 - 32bit -> 64bit 서버로 이동할 수 있는 유일한 방법입니다.

 - 한번에 하나의 데이터베이스만 백업 가능합니다.


 덤프 복원


 $ psql dbname < infile


 - 새로운 환경에서 복원하게 되면 dbname 부분의 들어가는 데이터베이스가 자동으로 생성 되지 않기 때문에, 미리 사용자가 같은 이름의 데이터베이스를 생성 해줘야 합니다.

 - SQL 덤프를 복원하기 전에 덤프된 데이터베이스의 개체를 소유하고 있거나 개체에 대한 권한이 부여된 모든 사용자가 이미 존재해야 합니다.

 - 덤프 복원은 에러가 나도 계속 진행하기 때문에 --set ON_ERROR_STOP=on 옵션을 주면 에러 발생시 psql을 종료하게 할 수 있습니다.

 - pg_dump로 생성된 덤프는 template0에 상대적입니다. 이것은 template1을 통해 추가된 언어, 프로시저 등도 pg_dump에 의해 덤프된다는 것을 의미합니다. 결과적으로 복원시, 커스터마이즈된 template1을 사용하는 경우 template0으로부터 비어있는 데이터베이스를 생성해야 합니다. 

 - 파이프에 쓰거나, 파이프에서 읽어 오는 pg_dump 및 psql의 기능은 데이터베이스를 특정 서버에서 다른 서버로 직접 덤프를 가능하게 합니다.


 $ pg_dump -h host1 dbname | psql -h host2 dbname



pg_dumpall 사용


 - pg_dump는 한 번에 하나의 데이터베이스만 덤프하며, role 또는 테이블스페이스에 대한 정보는 덤프하지 않습니다. 


 백업

 

 $ pg_dumpall > outfile


 복원


 $ psql -f infile postgres


 - 실제로 시작한 기존 데이터베이스 이름을 지정할 수 있지만 비어있는 클러스터로 로딩한 경우 postgres를 일반적으로 사용해야 합니다.

 - 클러스터 차원의 데이터는 pg_dumpall --globals-only 옵션을 사용하여 단독 덤프가 가능합니다.



거대 데이터베이스 처리


 - 일부 운영체제는 거대 pg_dump 출력 파일을 생성할 때 최대 파일 크기 제한이 있습니다. pg_dump는 표준 출력으로 사용할 수 있어, 유닉스 툴로 이런 문제의 가능성을 피할 수 있습니다.


 ◆ 압축 덤프 사용

  

  gzip을 이용한 덤프

  $ pg_dump dbnam | gzip > filename.gz


  리로드

  $ gunzip -c filename.gz | psql dbname


 ◆ split 사용

  

  1GB 단위로 분할 백업

  $ pg_dump dbname | split -b 1024m - filename


  리로드

  $ cat filename* | psql dbname


 ◆ pg_dump의 커스텀 덤프 형식 사용

  

  - 설치된 zlib 압축 라이르러리를 사용하여 PostgreSQL을 시스템에서 빌드한 경우 출력 파일에 쓸 때 커스텀 덤프 형식이 데이터를 압축합니다.

 - 덤프파일 크기는 gzip과 비슷하지만 테이블을 선택적으로 복원할 수 있다는 장점이 있습니다.


  백업

  $ pg_dump -Fc dbname > filename


  복원 : psql이 아닌 pg_restore를 이용해 복원합니다.

  $ pg_restore -d dbname filename


 ◆ pg_dump의 병렬 덤프 기능 사용


  - 거대 데이터베이스의 덤프 속도를 높이기 위하여 병렬 모드를 사용할 수 있습니다.

  - 병렬 덤프는 "디렉토리" 아카이브 형식에 대해서만 지원합니다.

 

 백업

 $ pg_dump -j <number> -F d -f out.dir dbname


 복원

 pg_resote -j 를 이용하여 복원 할 수 있습니다.




2. 파일 시스템 레벨 백업


 - 시스템 레벨에서 백업을 하는 것인데, 정상적인 백업을 위해서는 반드시 DB를 shutdown 해야 합니다. 복원도 마찬가지.


 tar -cf backup.tar /usr/local/pgsql/data


 - 파일 시스템 백업은 전체 데이터베이스 클러스터의 완전한 백업 및 복원에 대해서만 동작합니다.



 

3. 연속 아카이빙 및 PITR


 - PostgreSQL은 클러스터의 데이터 디렉토리의 pg_xlog/ 서브 디렉토리에 WAL를 항상 유지관리합니다. 이 로그에는 데이터 파일에서 일어난 모든 변경 내용이 기록 됩니다.

 - 복구가 필요한 경우, 파일 시스템 백업을 복원한 이후, 백업된 WAL 파일로부터 리플레이로 시스템을 현재 상태로 불러옵니다. (오라클 Hot backup 복원 후 archive 적용하는 것과 비슷한 개념입니다.)

 - 일반 파일 시스템 백업과 마찬가지로, 전체 데이터베이스 클러스터 복원만 지원합니다.


 베이스 백업


 - pg_base 를 이용한 백업

 

 1) WAL 아카이빙이 활성화 되어 있는지 확인한다.

 2) 슈퍼유저로 데이터베이스에 연결하고 다음 명령을 실행한다.

   SELECT pg_start_backup('label');

   여기서 label은 백업 작업의 식별을 위한 string이다.

   기본적으로 pg_start_backup은 완료 되는데 체크포인트를 수행하기 때문에 시간이 오래걸린다.

   백업을 가능한 빨리 시작하고 싶다면, 다음을 사용하는 것이 좋다.

   SELECT pg_start_backup('label',ture);

   체크포인트를 강제한다.

 3) tar 또는 cpio 같은 편리한 파일 시스템 백업툴을 사용하여 백업을 수행한다.

 4) 슈퍼유저로 데이터베이스에 접속후에 명령을 실행한다.

   SELECT pg_stop_backup();

 5) 백업을 아카이브 하는 중에 WAL 세그먼트가 활성화 되면 백업이 끝이 난다.

 

 ※ 오라클 Hot backup과 동일한 개념으로 보면 됩니다.


 연속 아카이브 백업을 사용한 복구


 1) 서버가 실행중인 경우 서버를 중지한다.

 2) 공간에 여유가 잇는 경우 필요할 때를 대비하여 전체 클러스터 데이터 디렉토리와 테이블스페이스를 임시 위치에 복사한다. 시스템 다운 정에 아카이브되지 않은 로그가 포함되었을 수 있는 클러스터의 pg_xlog 서브디렉토리의 내용을 최소한이라도 따로 저장해두어야 한다.

 3) 사용 중인 클러스터 데이터 디렉토리 아래 및 데이블스페이스의 root 디렉토리 아래의 모든 기본 파일 및 서브 디렉토리를 삭제한다.

 4) 데이터베이스 파일을 파일 시스템 백업으로 부터 복원한다. 올바른 소유권 확인 및 pg_tblspc의 심볼릭 링크가 바른지 확인.

 5) pg_xlog/ 밑에 오래된 파일 시스템 백업에서 온 로그를 삭제한다.

 6) pg_xlog/ 2단계에서 저장된 아카이브되지 않은 WAL 세그먼트 파일이 있을 경우 pg_xlog/에 복사한다.

 7) 클러스터 데이터 디렉토리에서 복구 명령 파일 recovery.conf를 생성한다. pg_hba.conf를 수정하여 복구하는 동안 접속을 막는다.

 8) 서버를 시작한다. 서버가 복구모드로 들어가고 아카이브된 WAL 파일을 통해 읽기가 진행 된다. 복구가 완료 되면 recovery.conf의 이름을 recovey.done 으로 변경하고 다시 복구 모드로 들어가지 않게 바꿔준다.

 9) 데이터베이스의 내용을 확인하고 pg_hba.conf 를 복원하여 사용자 연결을 확인한다.


※ recovery.conf


 예제 파일. /usr/pgsql-9.6/share/recovery.conf.sample을 이용하여 만들수 있다.


 아카이브 복구 설정


 restore_command (string)

  - WAL 파일 시리즈의 아카이브된 세그먼트의 검색을 실행하는 로컬 쉘 명령.

  - 아카이브 복구에 필요하지만 스트리밍 복제의 경우는 옵션.

  - string의 %f 는 아카이브에서 검색할 파일 이름으로 교체되고, %p 는 서버의 복사 대상 경로로 교체된다.

 

    restore_command = 'cp /data/pgsql/archvie/%f "%p"'


 archive_cleanup_command (string)

  -모든 restartingpoint에서 실행되는 쉘 명령을 지정한다.

  - 스탠바이 서버에서 더 이상 필요로 하지 않는 오래된 아카이브 WAL 파일을 클린업하는 메카니즘을 제공하는 것.

  - %r 은 마지막 유효 재시작 지점이 있는 파일의 이름으로 교체된다.

  

   archive_cleanup_command = 'pg_archivecleanup /data/pgsql/archive %r'


 recovery_end_command (string)

  - 복구 종료 시에 한 번만 실행되는 쉘 명령을 지정한다. 이 매개변수는 옵션이다.


복구 타깃 설정


recovery_target = 'immediate'

  - 온라인 백업에서 복원하는 경우 이것은 백업이 종료된 지점을 의미한다.

  - 현재 다른 매개변수는 없다.


recovery_target_name (string)

  - 이 매개변수는 지명된 복원 지점(pg_create_restore_point()를 사용하여 생성)을 복구가 진행되는 지점으로 지정.


recovery_target_time (timestamp)

  - 이 매개변수는 타임스탬프를 복구가 진행되는 지점으로 지정한다.

  - 정밀한 정지 지점은 recovery_target_inclusive의 영향도 받는다


recovery_target_xid (string)

  - 트랜잭션 ID를 복구가 진행되는 지점으로 지정한다.

  - 복구되는 트랜잭션은 지정된 것 이전에 커밋된 트랜잭션이다.


다음 옵션은 복구 타깃을 추가로 지정하며, 타깃에 도달 했을때, 발생하는 것에 영향을 끼친다.


recovery_target_inclusive (boolean)

  - 지정된 복구 타깃 직후에 중지 할 것인지, 직전에 중지 할 것인지 지정한다.

  - 기본값은 ture.


recovery_target_timeline (string)

  - 특정한 타임라인으로의 복구를 지정한다.

  - 기본값은 베이스 백업을 가져왔을 때 현재였던 동일한 타임라인을 따라 복구하는 것이다.

  - 이것을 lastest로 설정하면 아카이브의 최신 타임라인으로 복구 되며, 스탠바이 서버에 유용하다.

 







Netbackup 연동 RMAN 복원 테스트

현업에서는 서버를 관리하는데 있어서 대부분 백업 솔루션이 들업갑니다.


중소규모의 회사나 서버가 몇대 없는 회사의 경우, RMAN 스크립트를 만들어서 crontab 이나 작업스케줄러에 등록하여 백업을 받기도 하지만, 대규모의 기업이나 많은 수의 서버를 가진 업체의 경우 Netbackup 같은 백업 솔루션이 들어갑니다.


백업 솔루션은 Netbackup만 있는 것은 아니고 많은 회사들이 출시한 다양한 제품이 있지만, 국내에서 가장 많이 사용하는 백업 솔루션은 Netbackup 입니다. 백업 솔루션은 Acronis 같은 제품도 있고, 다양하게 있습니다.


Netbackup 같은 백업 솔루션은 단순 DB 백업 뿐 아니라 서버 자체를 백업 한다거나 다른 어플리케이션 백업도 가능합니다.

그렇기 때문에 Netbackup 엔지니어들은 Netbackup 설치나 OS 복구 정도는 할 수 있습니다. 


하지만, 오라클은 DB를 Netbackup을 이용해서 백업 할 줄 알아도, DB를 복구 하는 방법을 모르는 경우가 대부분 입니다. Netbackup을 다루는 회사마다 복구 메뉴얼이 있고, 메뉴얼 대로 복구 하는 경우가 많지만, 왜 그렇게 복구를 해야 하는지?, 복구하다 막혔을때 어떻게 해야 하는지 모르는 경우가 많아 DB 엔지니어나 DBA의 도움을 필요로 합니다. Netbackup 엔지니어들은 오라클을 집중적으로 공부한 경우가 많지 않기 때문이죠.


백업 계약이라는 것은 백업만 해주는게 아니고 장애시 복구가 포함 되는 것인데 백업 엔지니어가 DBA가 없으면 복구를 못하는 경운가 많다는 것이죠. 개인적으로 봤을때는 말이 안되는 상황이라고 봅니다. 업체측에서 restore 까지만 계약 되어 있다고 하는 경우도 있는데, 일반적으로 백업 복구는 recovery 후 시스템 정상화까지가 복구입니다. 


DBA와 백업 엔지니어가 협력해야 하는게 맞고, 서로서로 좋은게 좋은것이지만, 기본적으로 혼자 복구 할 줄 알아야 한다고 생각합니다. 어떤 회사는 들어가보면 DB는 있는데 DBA도 없고, DB 유지보수 계약도 없는 경우도 많거든요.




시나리오


● RAC 2노드 (ASM) -> Single DB (ASM Standalone)


 - RAC는 라이센스도 비싸고, 장비 세팅이나 준비사항이 많습니다. 

   그렇기 때문에 DR서버를 구축하거나 복구를 위한 테스트 서버를 RAC로 구축하는것은 낭비입니다.

 - 오라클 DB의 버전은 동일하게 맞춥니다. 원본이 11.2.0.4 라면 복구도 11.2.0.4

 - 파일 시스템은 일반 파일시스템이나 Raw Device 이어도 상관 없지만, 복구 과정 중에 Rename 작업이 필요하며, 

   ASM의 경우는 Rename 작업이 필요가 없습니다.

 - Netbackup에서 원본 서버의 RMAN 백업과 Archive 파일을 백업 받습니다.

 - 복구 서버에도 Netbackup 에이전트를 설치하고, RMAN의 저장 경로를 Netbackup으로 인식 시켜줍니다.



1. pfile 설정


 - pfile을 Netbackup에 있는 RMAN 백업에서 내려 받아도 상관 없지만, 그냥 원본에서 spfile을 pfile로 백업해서 드래그로 긁어 오는게 편합니다.


 원본서버

 SQL> create pfile='init<SID>.ora' from spfile;


 $ORACLE_HOME/dbs 밑에 가면 init<SID>.ora 파일이 생성 되어 있는데, 복구서버의 동일한 디렉토리에 복사해 주거나, vi로 만들어서 안의 내용을 복사해서 붙여 넣습니다.


rac2.__db_cache_size=1526726656

rac1.__db_cache_size=1459617792

rac2.__java_pool_size=16777216

rac1.__java_pool_size=16777216

rac2.__large_pool_size=33554432

rac1.__large_pool_size=33554432

rac1.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac2.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac2.__pga_aggregate_target=1258291200

rac1.__pga_aggregate_target=1342177280

rac2.__sga_target=2097152000

rac1.__sga_target=2013265920

rac2.__shared_io_pool_size=0

rac1.__shared_io_pool_size=0

rac2.__shared_pool_size=486539264

rac1.__shared_pool_size=469762048

rac2.__streams_pool_size=0

rac1.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/rac/adump'

*.audit_trail='db'

*.cluster_database=true

*.compatible='11.2.0.4.0'

*.control_files='+DATA/rac/controlfile/current.260.923661671','+RECO/rac/controlfile/current.256.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='rac'

*.db_recovery_file_dest='+RECO'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=racXDB)'

rac1.instance_number=1

rac2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_rac_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

*.remote_listener='rac-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

rac2.thread=2

rac1.thread=1

rac2.undo_tablespace='UNDOTBS2'

rac1.undo_tablespace='UNDOTBS1'

 


파라미터 파일을 수정해야 합니다.

rac 관련되 부분을 삭제 혹은 주석 처리하고, cluster_database는 ture에서 false로 변경해 줍니다.


수정 후


rac.__db_cache_size=1459617792

rac.__java_pool_size=16777216

rac.__large_pool_size=33554432

rac.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac.__pga_aggregate_target=1342177280

rac.__sga_target=2013265920

rac.__shared_io_pool_size=0

rac.__shared_pool_size=469762048

rac.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/rac/adump'

*.audit_trail='db'

*.cluster_database=false

*.compatible='11.2.0.4.0'

*.control_files='+DATA/rac/controlfile/current.260.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='rac'

*.db_recovery_file_dest='+DATA'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=racXDB)'

rac.instance_number=1

#rac2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_rac_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

#*.remote_listener='rac-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

#rac2.thread=2

rac.thread=1

#rac2.undo_tablespace='UNDOTBS2'

rac.undo_tablespace='UNDOTBS1'


수정하고 diag 경로를 생성하고, archive 경로가 맞는지 확인해줍니다.


$ mkdir -p /app/oracle/admin/rac/adump

$ mkdir -p /archive

# chown oracle.oinstall /archive


수정이 완료 되면 DB가 nomount 상태까지 올라갑니다.


$ sqlplus / as sysdba

SQL> startup nomount;


그러면 DB쪽은 Restore 준비가 끝난 상태입니다.



2. Netbackup 에서 Controlfile 내려 받기


 - DB가 nomount 상태가 되면 Netbackup 에이전트 설치 및 Netbackup RMAN 연동이 가능합니다. (Netbackup 엔지니어 작업)

 - Netbackup과 RMAN이 연결되면, RMAN에서 list backup 명령시 백업 파일들이 나옵니다.


RMAN> 


RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';

SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';

RESTORE CONTROLFILE FROM 'ctrl_dracDB_udnrljheg_s439_p1_t928630224';

RELEASE CHANNEL ch00;

}


빨간색으로 된 부분은 콘트롤 파일의 백업인데, 백업마다 이름이 다르고, 서버마다 다르니 맞는 걸 찾아서 복원하면 됩니다.


콘트롤 파일이 복원디면 DB mount가 가능해집니다.


RMAN> alter database mount;



3. Restore


 - controlfile이 복원되면 restore가 가능해집니다.

 - ASM의 경우 datafile의 끝에 랜덤 숫자로 고유번호가 붙는데, 원본 DB와 복구DB의 번호가 다릅니다.

 - Restore 시 바뀐 번호로 자동 적용됩니다.


restore 명령을 실행 해봅니다.


RMAN>


RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';

SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';

RESTORE DATABASE;                                   

RELEASE CHANNEL ch00;

}


그러면 진행 상황이 나오며, restore가 진행됩니다.


Starting restore at 23-OCT-16

using channel ORA_DISK_1


channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DATA/rac/datafile/system.256.923661571

channel ORA_DISK_1: restoring datafile 00002 to +DATA/rac/datafile/sysaux.257.923661571

channel ORA_DISK_1: restoring datafile 00003 to +DATA/rac/datafile/undotbs1.258.923661573

channel ORA_DISK_1: restoring datafile 00004 to +DATA/rac/datafile/users.259.923661573

channel ORA_DISK_1: restoring datafile 00005 to +DATA/rac/datafile/example.264.923661707

channel ORA_DISK_1: restoring datafile 00006 to +DATA/rac/datafile/undotbs2.265.923661973

channel ORA_DISK_1: restoring datafile 00007 to +DATA/rac/datafile/test01.269.924548909

channel ORA_DISK_1: reading from backup piece /work/rman/0qrijlsp_1_1_20161017.bkp

channel ORA_DISK_1: piece handle=/work/rman/0qrijlsp_1_1_20161017.bkp tag=TAG20161017T161729

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:18:05

Finished restore at 23-OCT-16


RMAN>



4. Recovery


 - recover database 명령을 날려보면 필요한 archive log 파일 리스트가 나옵니다.


RMAN> recover database;


Starting recover at 23-OCT-16
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=473
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=239
channel ORA_DISK_1: reading from backup piece /work/rman/0srijm73_1_1_20161017.bkp
channel ORA_DISK_1: ORA-19870: error while restoring backup piece /work/rman/0srijm73_1_1_20161017.bkp
ORA-19504: failed to create file "/archive/arch_rac_2_473_923661675.arc"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Additional information: 1

failover to previous backup
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 10/23/2016 17:28:31
RMAN-20506: no backup of archived log found
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 239 and starting SCN of 4539696 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 473 and starting SCN of 4539693 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 238 and starting SCN of 4539695 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 472 and starting SCN of 4539692 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 237 and starting SCN of 4539694 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 471 and starting SCN of 4539691 found to restore

thread 1은 1번 노드, thread 2는 2번 노드의 아카이브 파일입니다.
빨간색으로 된 부분에서 sequence 넘버를 잘 보면 맨 위에가 최신이고, 아래쪽이 오래된 시퀀스 넘버입니다.
해당 시퀀스 번호를 가진 아카이브 로그가 필요하다는 뜻 입니다.

그러면 Netbackup에서 아카이브 로그를 복구 합니다.

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';
RESTORE ARCHIVELOG FROM SEQUENCE 237 UNTIL SEQUENCE 239 THREAD 1;
RESTORE ARCHIVELOG FROM SEQUENCE 471 UNTIL SEQUENCE 473 THREAD 2;
RELEASE CHANNEL ch00;
}


그 후에

RMAN> recover database;

RMAN> alter database open resetlogs; 

하면 완료가 됩니다.