RMAN (Recovery Manager)
 : 관리자가 직접 백업을 하고 장애 발생시에 적절한 백업 파일을 찾아 복원 후 복구 하는 전통적인 방식보다 발전된 백업복구 방식
 : 전통적인 백업복구 방식의 주체가 사람 이었다면, RMAN부터는 사람이 RMAN에게 명령하고 백업복구의 주체가 RMAN이다.
 


▶ 전통적인 방법을 충분히 숙지하고 있다면, 전통적인 방법 만으로도 백업복구를 할수 있으나,
   10g 버전부터 본격적으로 사용되고 있는 ASM (Automatic Storage Management) 기반의 백업 및 복구는 RMAN 밖에 할 수 없다.
 




※ RMAN 장점
1. 자주 실행하는 작업을 스크립트로 저장(Recovery Catalog 사용할 경우)
  : 규모가 큰 DB의 경우 백업 수행시 코딩하는 양이 많아짐. 자주 사용하는 백업 명령어들을 스크립트로 저장한후 불러와서 사용 가능
 
2. 증분 블록 레벨 백업 기능 지원
  : 이전 백업받은 내역을 조사해 변경된 블록만 찾아서 백업 수행 가능
    기존 방식의 경우 100M 파일에서 10M 만 변경되엇다고 해도 100M전체를 반복해서 백업해야 했지만, RMAN에서는 10M만 백업 받으면 됨
 



3. 사용되지 않은 블록 건너뛰고 백업 수행
  : 100M 할당된 파일에서 실제 작은 용량만 사용하더라도 전체 100M를 백업받아야 했지만, RMAN의 경우 현재 사용 블록만 찾아서 백업 수행
  : backupset 으로 백업 수행할경우 자동으로 지원
 
4. 백업 수행중 훼손된 블록 감지
  : 일반적인 백업에서는 파일을 백업하던 도중에 훼손된 블록이 있을 경우 장애가 발생하고 백업이 중단됨.
    RMAN 에서는 백업 수행도중 훼손된 블록을 감지해서 마킹해 두고 계속 백업 진행
 
5. 백업된 파일 압축됨
  : 기존의 경우 실제 100M파일을 백업받으려면 해당 용량의 백업공간이 필요했지만, RMAN의 경우 압축되어 저장되기 때문에 더 적은 공간을 필요로함.


 
 
 

※ Recovery Manager 구성도


- Target database (대상서버) : 관리자(DBA)를 대신하여 RMAN 유틸리티가 관리해주는 서버
- 채널 : 백업 파일이 저장되어지는 저장장치 (Disk, MML 등 여러 매체가 있을수 있다)
- Recovery Catalog Server
 
: 백업에 관련된 정보가 저장되는 외부 서버. 해당서버의 Catalog Database에 저장된다.
   : 해당 서버가 없다면, 기본적으로 Target Database의 control file에 기록된다.

 

▶ 전통적인 방식의 절차를 몰라도 RMAN 사용법만 익히면 얼마든지 백업복구를 수행할수 있을만큼 쉽다.
   : 백업복구의 원리를 알아야 문제가 생겼을 때 대처를 할수 있고, 사용상의 한계를 극복할수 있다.


 
 
 



※ RMAN Memory 구조
 : RMAN은 백업복구를 수행할때 기본적으로 PGA를 사용한다.
   공간이 부족할 경우 SGA(Large Pool, Shared pool) 을 사용하여 백업을 수행함.
 



- Input Buffer : 백업 받을 때 사용하는 버퍼
- Output Buffer : 백업피스(백업파일)에 저장하기 위해 사용하는 버퍼
- Backup Set : RMAN으로 백업받으면 만들어지는 백업파일. 기존 백업파일과 다르게 하나의 백업파일에 여러 Data file의 블록이 백업된다.
 
① Data file에서 Input buffer 로 백업 받아야 할 블록을 가져옴
② 여러개의 Input buffer 중 하나가 가득차면 Output Buffer 로 블록을 복사함
   → Output Buffer에는 여러 Data file의 블록이 혼합되어 존재한다.
③ Ouput Buffer 가 가득차게 되면 Backup Set에 내려쓰게 된다.


 
 


※ 참고
Input Buffer 사용내역과 크기 조회 SQL문
 
set line 200
set pagesize 50
col filename for a50
SQL> select set_count, device_type, filename, buffer_size, buffer_count, open_time, close_time
  2  from v$backup_async_io
  3  order by set_count, type, open_time, close_time;


 
 
 
 
 
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성하기 시작
Recovery Catalog Server 구성하기
 : 복구 카탈로그를 대상 데이터베이스의 control file 이 아닌 별도의 DB에 저장하는 복구 카탈로그 서버를 만들어 관리
 
- 전제조건 -
앞에서 배운 CLONEDB를 이용하여 ORACLE_SID=rcserver 를 생성한다.
이 서버를 Recovery Catalog Server로 활용하려 한다.
참고 : 
2012/02/15 - [Study/Oracle - 백업&복구] - 백업&복구 18 - Clone DB : DB 무정지 상태에서의 복구 

 

※ 참고사항
11g에서 cloneDB를 생성할때 에러가 뜨는 경우가 있다.
컨트롤 파일을 새로 만드는 스크립트를 실행할때(DB NOMOUNT 상태로 올라갈때) 나는 에러이다.
 
○ 에러
SQL> @/home/oracle/rc.sql
ORA-00845: MEMORY_TARGET not supported on this system
CREATE CONTROLFILE SET DATABASE "RCSERVER" RESETLOGS  ARCHIVELOG
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0
 
 
○ 원인
Oracle Database 11g의 새로운 기능 중 AMM(Automatic Memory Management)을 사용하기 위해서
Linux 에서 memory_target, memory_max_size를 세팅 후 Database를 startup할때 해당 에러가 생긴다.
 
▶마운트된 /dev/shm 크기가 memory_target 이나 memory_max_size 에서 지정한 값보다 작거나,
  리눅스의 shared memory가 마운트된 /dev/shm 와 맵핑이 되어 있지 않을 경우발생 할수있다.
 
 
○ 해결방법
1. df 명령어 실행해서 현재 mount 정보 확인해보기
 
① 문제의 원인이 되는 마운트된 /dev/shm 크기를 확인
② /dev/shm의 설정을 변경하기 위해서 umount
③ size 조정 후 mount
   # mount -t tmpfs shmfs -o size=2g /dev/shm
④ 재부팅시 적용위해 /etc/fstab의 내용 수정
# vi /etc/fstab
tmpfs   /dev/shm       tmpfs   size=2g 0 0
:wq!
 
 
2. 오라클 파라미터 파일수정
 : 특이한 경우 위의 조치를 취하더라도, 같은 에러가 나는 경우가 있다.
파라미터 파일을 열어서 해당 부분 주석처리
$ vi initrcserver.ora
#*.memory_target=4196401152
:wq!


 
 
★ 아래 실습 = 헷갈리기 때문에 창 색으로 해당 서버 표시

** rcserver

** rcclient


 
 

** rcserver 에서 작업
 
1. 복구 카탈로그를 저장할 테이블스페이스(rc_tbs01) 생성
 
SQL> select tablespace_name, bytes/1024/1024 MB, file_name
  2  from dba_data_files;

 
TABLESPACE_NAME    MB FILE_NAME
--------------- ----- --------------------------------------------------
EXAMPLE           346 /data/rcserver/example01.dbf
USERS              13 /data/rcserver/users01.dbf
UNDOTBS1           95 /data/rcserver/undotbs01.dbf
SYSAUX            510 /data/rcserver/sysaux01.dbf
SYSTEM            700 /data/rcserver/system01.dbf
 
SQL> select instance_name from v$instance;
 
INSTANCE_NAME
----------------
rcserver
 
SQL> create tablespace rc_tbs01
  2  datafile '/data/rcserver/rc_tbs.dbf' size 10M
  3  autoextend on;

 
Tablespace created.
 
 
 
2. 복구 카탈로그를 관리할 사용자계정(rcuser) 생성 및 권한부여
 
SQL> create user rcuser identified by rcuser
  2  default tablespace rc_tbs01
  3  temporary tablespace temp;

 
User created.
 
SQL> grant connect, resource, recovery_catalog_owner to rcuser;
 
Grant succeeded.
 
SQL> conn rcuser/rcuser
Connected.


 
 
 
 

** rcclient 에서 작업
 
3-1. 클라이언트의 tnsnames.ora 수정
 
$ vi /app/oracle/product/11g/network/admin/tnsnames.ora 
rcserver =
        (DESCRIPTION =
                (ADDRESS_LIST =
                        (ADDRESS = (PROTOCOL = TCP)(HOST = server122)(PORT = 1521))
                )
        (CONNECT_DATA =
                (SERVICE_NAME = rcserver)
        )
)

:wq!


 
 
 
 

** rcserver 에서 확인 작업
 : 해당 rcclient의 정보를 추가해준다. 현재는 같은 장치안에서 DB를 생성한 것이기 때문에 따로 설정해 줄 필요는 없음.
참고 : 
2012/02/15 - [Study/Oracle - 백업&복구] - 백업&복구 19 - DB Link

3-2 서버의 listener.ora 수정

 
$ vi /app/oracle/product/11g/network/admin/listener.ora
# listener.ora Network Configuration File: /app/oracle/product/11g/network/admin/listener.ora
# Generated by Oracle configuration tools.
 
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = server122)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )
 
ADR_BASE_LISTENER = /app/oracle

:wq!
 
 
 

※ 참고
11g의 버그인지 모르겠으나 경우에 따라서 리스너의 내용을 다르게 해줘야 RMAN에 접속이 되는 경우가 있다.
 
① 맨아랫줄
ADR_BASE_LISTENER = /app/oracle 부분 제거
 
아니면

② 내용추가 (이름 및 경로는 본인 환경에 맞게 편집)
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = rcserver)
      (ORACLE_HOME = /app/oracle/product/11g)
    )
  )


 
 
 
 
 
 
 
4. rcclient 에서 rcserver로 접속 확인 테스트

** rcserver
 
▶ listener 실행
 
$ lsnrctl start
 
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 21-FEB-2012 16:37:03
 
Copyright (c) 1991, 2010, Oracle.  All rights reserved.
 
Starting /app/oracle/product/11g/bin/tnslsnr: please wait...
 
TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /app/oracle/product/11g/network/admin/listener.ora
Log messages written to /app/oracle/diag/tnslsnr/server122/listener/alert/log.xml
.......중략..........
The listener supports no services
The command completed successfully


 
 
 

** rcclient
 
▶ rcserver쪽으로 접속테스트 수행 (ping 날려보기)
 
$ tnsping rcserver
 
TNS Ping Utility for Linux: Version 11.2.0.2.0 - Production on 21-FEB-2012 16:38:23
 
Copyright (c) 1997, 2010, Oracle.  All rights reserved.
 
Used parameter files:
 
 
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = server122)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = rcserver)))
OK (10 msec)  ← 접속이 잘 되는것 확인완료


 
 
 
 
5. rcclient 서버에 rman 으로 접속하되 recvoery catalog 서버(만들어놓은 rcserver)에 접속
 

** rcclient
 
① rman 접속
 
$ rman target / catalog rcuser/rcuser@rcserver
 
Recovery Manager: Release 11.2.0.2.0 - Production on Tue Feb 21 16:43:02 2012
 
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: TESTDB (DBID=2554588056)
connected to recovery catalog database
 
 
② 복구 카탈로그 생성
 
RMAN> create catalog tablespace rc_tbs01;
 
recovery catalog created


 
 
 
 

** rcserver
 
③ 복구서버(rcserver)에서 rcclient 서버가 등록되었는지 확인
 
$ sqlplus rcuser/rcuser
 
SQL> select * from rc_database;
no rows selected
아직 없음


 
 
 
 

** rcclient
 
④ 등록
 
RMAN> register database;
 
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete


 
 
 

** rcserver
 
⑤ 등록확인해보기
SQL>  select * from rc_database;
 
    DB_KEY  DBINC_KEY       DBID NAME                                          RESETLOGS_CHANGE# RESETLOGS_TI
---------- ---------- ---------- --------------------------------------------- ----------------- ------------
         1          2 2554588056 TESTDB                                                   770463 30-DEC-11
등록완료


 
 
 
⑥ DATAFILE도 확인 (양쪽서버 비교)
 

** rcserver
 
SQL> select db_name, tablespace_name, name "file_name" from rc_datafile;
 
DB_NAME  TABLESPACE_NAME file_name
-------- --------------- --------------------------------------------------
TESTDB   SYSTEM          /app/oracle/oradata/testdb/system01.dbf
TESTDB   SYSAUX          /app/oracle/oradata/testdb/sysaux01.dbf
TESTDB   UNDOTBS1        /app/oracle/oradata/testdb/undotbs01.dbf
TESTDB   USERS           /app/oracle/oradata/testdb/users01.dbf
TESTDB   EXAMPLE         /app/oracle/oradata/testdb/example01.dbf


 
 

** rcclient
 
SQL>  select tablespace_name, bytes/1024/1024 MB, file_name  from dba_data_files;
 
TABLESPACE_NAME    MB FILE_NAME
--------------- ----- --------------------------------------------------
USERS              13 /app/oracle/oradata/testdb/users01.dbf
UNDOTBS1           95 /app/oracle/oradata/testdb/undotbs01.dbf
SYSAUX            510 /app/oracle/oradata/testdb/sysaux01.dbf
SYSTEM            700 /app/oracle/oradata/testdb/system01.dbf
EXAMPLE           346 /app/oracle/oradata/testdb/example01.dbf
 
▶ 동일함 : rcclient의 내용이 rcserver에 정상적으로 모두 등록완료


 
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성하기 끝
 
 
 
 
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성 테스트 시작
Catalog Server 구성 테스트
 : 장애로 구성 제대로 되었나 테스트 해보기
 
- 장애내용 : rcclient 에서 모든 control file 이 삭제되고 DB 강제종료
                 catalog server를 이용해서 복구하기

 
 
1. rcclient 전체 백업
 
$ rman target / catalog rcuser/rcuser@rcserver
 
RMAN> backup database;
 
Starting backup at 21-FEB-12
starting full resync of recovery catalog
full resync complete
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=43 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/app/oracle/oradata/testdb/system01.dbf
input datafile file number=00002 name=/app/oracle/oradata/testdb/sysaux01.dbf
input datafile file number=00005 name=/app/oracle/oradata/testdb/example01.dbf
input datafile file number=00003 name=/app/oracle/oradata/testdb/undotbs01.dbf
input datafile file number=00004 name=/app/oracle/oradata/testdb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-FEB-12
channel ORA_DISK_1: finished piece 1 at 21-FEB-12
piece handle=/app/oracle/fast_recovery_area/TESTDB/backupset/2012_02_21/o1_mf_nnndf_TAG20120221T171609_7n6npc44_.bkp tag=TAG20120221T171609 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:58
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 21-FEB-12
channel ORA_DISK_1: finished piece 1 at 21-FEB-12
piece handle=/app/oracle/fast_recovery_area/TESTDB/backupset/2012_02_21/o1_mf_ncnnf_TAG20120221T171609_7n6nt235_.bkp tag=TAG20120221T171609 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 21-FEB-12
 
 
 
2. rcclient 모든 컨트롤파일 삭제후 강제종료
SQL> select name from v$controlfile;
 
NAME
---------------------------------------------
/app/oracle/oradata/testdb/control01.ctl
/app/oracle/fast_recovery_area/testdb/control
02.ctl
 
 
SQL> !rm -fr /app/oracle/oradata/testdb/control01.ctl
SQL> !rm /app/oracle/fast_recovery_area/testdb/control02.ctl

 
SQL> shutdown abort;
ORACLE instance shut down.
 
 
SQL> startup
ORACLE instance started.
 
Total System Global Area  422670336 bytes
Fixed Size                  1344616 bytes
Variable Size             255855512 bytes
Database Buffers          159383552 bytes
Redo Buffers                6086656 bytes
ORA-00205: error in identifying control file, check alert log for more info
 
 
 
 
3. rcclient 서버에서 RMAN으로 catalog server에 접속하여 복구
$ rman target / catalog rcuser/rcuser@rcserver
 
RMAN> restore controlfile;
 
Starting restore at 21-FEB-12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=17 device type=DISK
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /app/oracle/fast_recovery_area/TESTDB/backupset/2012_02_21/o1_mf_ncnnf_TAG20120221T171609_7n6nt235_.bkp
channel ORA_DISK_1: piece handle=/app/oracle/fast_recovery_area/TESTDB/backupset/2012_02_21/o1_mf_ncnnf_TAG20120221T171609_7n6nt235_.bkp tag=TAG20120221T171609
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/app/oracle/oradata/testdb/control01.ctl
output file name=/app/oracle/fast_recovery_area/testdb/control02.ctl
Finished restore at 21-FEB-12
 
 
RMAN> alter database mount;
 
database mounted
releasedchannel: ORA_DISK_1
 
 
RMAN> alter database open resetlogs;
 
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 02/21/2012 17:24:23
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/app/oracle/oradata/testdb/system01.dbf'
에러 : Data file 에러로 복구가 안됨. DB 비정상종료(shutdown abort) 때문임.
 
 
RMAN> recover database;  → 복구 시작
 
Starting recover at 21-FEB-12
Starting implicit crosscheck backup at 21-FEB-12
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=17 device type=DISK
Crosschecked 1 objects
Finished implicit crosscheck backup at 21-FEB-12
 
Starting implicit crosscheck copy at 21-FEB-12
using channel ORA_DISK_1
Finished implicit crosscheck copy at 21-FEB-12
 
searching for all files in the recovery area
cataloging files...
cataloging done
 
List of Cataloged Files
=======================
File Name: /app/oracle/fast_recovery_area/TESTDB/backupset/2012_02_21/o1_mf_ncnnf_TAG20120221T171609_7n6nt235_.bkp
 
using channel ORA_DISK_1
 
starting media recovery
 
archived log for thread 1 with sequence 15 is already on disk as file /app/oracle/oradata/testdb/redo03.log
archived log file name=/app/oracle/oradata/testdb/redo03.log thread=1 sequence=15
media recovery complete, elapsed time: 00:00:01
Finished recover at 21-FEB-12
 
 
 
 
RMAN> alter database open resetlogs;  → 컨트롤파일이 삭제되었기 때문에 resetlogs로 open 해야함
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
복구 완료
 
 
 
SQL> select status from v$instance;
 
STATUS
--------
OPEN
 
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성 테스트 끝
 

Posted by 딩구르

댓글을 달아 주세요

  1. Favicon of http://cyworld.com/bc83 BlogIcon Hare 2012.02.22 01:01  댓글주소  수정/삭제  댓글쓰기

    으아 형 정리 정말 빠르다...ㅋ 난 아직 실습 정리 안했는데 내일 아침에 해야지 ㅠㅠ

  2. Favicon of http://gyh214.tistory.com BlogIcon 에몽이 2012.02.22 11:12  댓글주소  수정/삭제  댓글쓰기

    실습해봤는데, controlfile이 restore될 수 있는 경우는, 다른 DB에 rman catalog를 생성한 경우밖에 없더라구요.
    자기 DB에 rman catalog생성해서 운영한 경우는, controlfile에 backup 정보가 다 저장되어 버려서 control file이 삭제되어 버리면
    restore controlfile; 실행해도 복구불능

    • Favicon of https://dinggur.tistory.com BlogIcon 딩구르 2012.02.22 23:33 신고  댓글주소  수정/삭제

      아. 아까 낮에는 경황없이 봐서 무슨소리인가 했는데..
      차분히 보니까 무슨 소리를 하는 건 줄 알겠다.

      위에 실습중에, 컨트롤 파일 다 날려먹고 복구 하는 상황을 이야기 한 거구나.

      catalog DB 에서 백업된 정보 가지고 와서 컨트롤 파일 살릴때는 문제없이 복구 되지만, Recovery Catalog Server 없이 Target DB에 있는 컨트롤파일에 백업내용 저장된 상태에서 그게 날아가 버리면...
      갈길을 잃고 헤매다가 복구 못하고 실패해 버리는 거구나!!

      마...맞지? ㅋ

  3. Favicon of http://gyh214.tistory.com BlogIcon 에몽이 2012.02.23 11:39  댓글주소  수정/삭제  댓글쓰기

    네 ㅎㅎ
    catalog 정보가 control file과 함께 날라가 버려서 실패!

  4. lee 2017.06.12 17:57  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 오라클 증분백업 rman 검색중에 글쓴이분 글 검색해서 질문있어서 글 남기게 됬습니다!!

    질문 드리고싶은데 혹시 이메일 알려 주실수 있나요??