Posted by 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 구성 테스트 끝
출처: http://dinggur.tistory.com/178 [아무도없는세계]