백업 & 복구 26 - RMAN : Catalog server구성 및 복구 간단 테스트

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
 
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성 테스트 끝