O10g bak rec_15

http://www.ggola.com 장 경 상

8. Backup and Recovery............................................................................8-3

8.1. Flash Backup and Recovery......................................................8-4

8.1.1. 개요.......................................................................................8-4

8.1.2. Flash Recovery Area.............................................................8-4

8.1.2.1........................................................Flash Recovery Area 속성

8-4

8.1.2.2........................................................Flash Recovery Area 설정

8-5

8.1.3. Backup Files and Flash Recovery Area.................................8-5

8.1.3.1.................................................................................Files의 위치

8-5

8.1.3.2................................Flash Recovery Area정보와 Views의 변화

8-15

8.1.3.3...................................................Control Flash Recovery Area

8-16

8.2. Recovery and Incremental Backup..........................................8-21

8.2.1. 개요.....................................................................................8-21

8.2.2. Incremental Backup............................................................8-21

8.2.2.1............................................................Changed Block Backup

8-21

8.2.2.2.........................................................Fast Incremental Backup

8-21

8.2.3. Example.............................................................................8-22

8.3. RMAN and Backup...................................................................8-32

8.3.1. Backup Management..........................................................8-32

8.3.1.1...............................................................................Backup 전략

8-32

8.3.1.2................................................................Compressed Backup

8-33

8.3.1.3...........................................................Duration and Throttling

8-36

8.3.1.4....................................................................Copy and As Copy

8-39

8.3.2. Catalog Control..................................................................8-39

8.3.2.1...........................................................Add and Delete Catalog

8-39

[email protected] 1


8.3.2.2............................................................Management Using em

8-43

8.3.3. Backup and Copy...............................................................8-44

8.3.3.1.............................................................................................개요

8-44

8.3.3.2...........................................................Example for Tablespace

8-45

8.3.3.3...............................................Controlfile and Controlfilecopy

8-47

8.4. RMAN and Recovery................................................................8-50

8.4.1. Backup and Fast Recovery..................................................8-50

8.4.1.1................................................................................Full Backup

8-50

8.4.1.2............................................................................Fast Recovery

8-51

8.4.2. TSPITR(TableSpace Point-In-Time Recovery).......................8-51

8.4.2.1.....................................................................TSPITR and RMAN

8-51

8.4.2.2..........................................................................TSPITR and em

8-63

8.4.2.3.........................................................TSPITR and RMAN의 한계

8-66

8.4.3. New Resetlogs Open..........................................................8-67

8.4.3.1..........................................Oracle10g의 Resetlogs Open 변화

8-67

8.4.3.2...............................................................Resetlogs 정보와 확인

8-68

8.4.4. Recovery and Drop.............................................................8-70

8.4.4.1............................RMAN Recovery Datafile Without Backups

8-70

8.4.4.2.......................................................RMAN and Drop Database

8-74

8.5. Others.....................................................................................8-81

8.5.1. Database Begin Backup.....................................................8-81

8.5.1.1.............................................................................................개요

8-81

[email protected] 2


8.5.1.2........................................................................Command Limit

8-81

8.5.1.3................................................Online Backup Mode Example

8-82

8.5.2. RMAN 추가 정보...................................................................8-85

8.5.3. Backup 검증........................................................................8-86

[email protected] 3


8. Backup and Recovery

Oracle10g는 backup and recovery 부분도 self-managing database의 일환으로

소개하고 있다. 물론, 관리 시스템의 매우 중요한 축을 이루는 backup and recovery

를 빼 놓을 수는 없겠으나 사실 이번 장의 주요내용은 기능적인 것들이다.

앞서 chapter 6에서 다루었던 “flash recovery area”에 대한 backup and recovery

차원에서의 개념과 새로운 개념의 backup 유형과 사용법 등을 알아볼 것이다.

[email protected] 4


8.1. Flash Backup and Recovery

8.1.1.개요전통적인 “backup and recovery”는 정기적으로 datafiles과 log files을 backup받고

필요할 때에 restore를 하여 redo log를 적용하는 것을 뜻한다. 즉, 이를 달리

표현하자면 아니 약점을 부각하여 이 의미를 살펴보면 backup되는 media의 성능에

따라 그리고 restore할 files의 size및 redo log에 적용할 files의 수에 따라 그

작업시간은 매우 의존적이며 경우에 따라 전체 작업시간이 너무 느리다고 느낄 수

있다는 의미도 된다. 따라서 oracle10g가 제공하는 flash backup and recovery는

tape보다 훨씬 빠르고 비용도 싸지고 있는(tape에 비해 더 경제적일 수도 있다) disk의

“flash recovery area” 설정을 통해 훨씬 빠른 data access및 recovery 시간을

보장한다.

CF. 사실 우리는 앞서 chapter 6에서 flashback database를 소개하면서 대부분의

기능에 대하여 이미 알아본 바 있다. 잘 모르겠다면 우선 chapter 6의 해당 부분을

다시 한번 살펴보자.

8.1.2.Flash Recovery Area

8.1.2.1. Flash Recovery Area 속성Flash backup and recovery를 위해 사용되는 disk상의 backup 공간인 flash

recovery area는 다음과 같은 속성을 갖는다.

1. 이 area는 여러 database가 공유해서 사용할 수 있다.

2. 이 area는 directory, file system등이 될 수도 있고 향후(chapter 9)에 설명할

ASM disk group일 수도 있다.

3. 모든 종류의 recovery에 필요한 files backup을 통합하여 저장한다. 즉, flashback

logs가 저장되는 것은 물론이고 control files, archived log files, redo log files이

저장될 수 있으며 control file의 autobackup, backup as copy를 통한 data files

copy 그리고 RMAN으로 backup을 하거나 recovery를 위해 archive log files을

restore하는 default location으로 사용된다.

4. files이 flash recovery area에 쓰여질 때 space가 부족하게 되면 (obsolete files

list에서)이미 backup이 된 files이나 더 이상 의미가 없는 files이 지워지고 write가

재개된다. 그러나 이 때에 지울만한 files이 없어도 flash recovery area로 설정한

최대 size만큼은 write가 진행된다. 물론, 이 area에 공간이 부족하다면 alerts가

발생되며 그 기준은 warning 85%, critical 97%로 oracle 내부적으로 설정되어 있다.

이는 바꿀 수 없으며 이미 앞서 chapter 7에서 alert 기능을 설명할 때 out-of-box

server alert 부분에서 설명한 바 있다.

[email protected] 5


5. flash recovery area가 설정되어 있으면 RMAN을 통해 backup files을 할 때 굳이

이름을 지정할 필요가 없으며 이 경우 자동으로 backup files을 OMF를 통해 naming

하여 default 위치인 flash recovery area에 위치시킨다.

8.1.2.2. Flash Recovery Area 설정이미 chapter 6에서 살펴보았지만 flash recovery area는 oracle10g의 new

parameters인 db_recovery_file_dest_size와 db_recovery_file_dest를 설정하면

된다. 물론, 이 값은 “alter system set “command로 dynamic하게 바꿀 수도 있다.

RAC환경이라면 모든 nodes의 이들 parameters는 동일한 값을 가져야 하며 data

guard도 지원한다.

이 작업을 em에서 확인하고 수행하고 싶다면 “Maintenance Configure Recovery

Settings(Backup/Recovery)” 화면에서 하단의 “Flash Recovery Area”를 보면

된다. 아래 그림을 확인해 보라.

이 부분에서 원하는 값으로 설정 및 변경을 할 수 있다. 이는 물론 관련 parameters가

dynamic parameter이기 때문에 가능한 것이다.

8.1.3.Backup Files and Flash Recovery Area

8.1.3.1. Files의 위치앞서 언급한 여러 종류의 files과 flash recovery area가 어떻게 결합되는가 알아보자.

이미 chapter 6에서 flashback database를 설명하면서 flashback log에 대해서는

살펴보았으니 그 외의 files을 확인해 보자.

1. archived log files : 이 files이 flash recovery area에 생성 되려면 두 가지 방식이

가능하다. 그 첫 번째는 parameter “log_archive_dest_n” parameter에 flash

[email protected] 6

그림 8-1

Flash Recovery Area 설정


recovery area를 추가적으로 설정을 하던지 아니면 아예 log_archive_dest_n

parameter를 설정하지 않음으로써 flash recovery area를 default archive

destination으로 사용하는 방법이다. 다음은 그 두 번째 방법의 실제 예이다. 사실 이

방법은 눈에 보이지는 않아도 oracle 내부적으로 log_archive_dest_10의 값을

db_recovery_file_dest의 값으로 설정한다고 한다. 먼저 parameters 설정을

확인하자.

[NEWSVC]LIRACLE:/app/oracle/temp> vi ../admin/NEWSVC/pfile/initNEWSVC.ora

......

......

......

......

## Archive

#log_archive_dest_1 = 'LOCATION=/app/oracle/oradata/arch/NEWSVC'

log_archive_format = arch_%t_%s_%r.arc

#log_archive_start = true

##flashback database configuration

db_recovery_file_dest_size = 5G

db_recovery_file_dest = '/app/oracle/flash_recovery_area'

db_flashback_retention_target = 1440 # 1 day

......

......

......

~

~

~

~

~:wq

[NEWSVC]LIRACLE:/app/oracle/temp>

현재 parameter 설정을 db_recovery_file_dest_size는 5G로 늘리고

log_archive_dest_1는 주석으로 처리하여 현재 archive destination이 설정되지

않은 상태이다.

이제 database를 restart하면서 start 전, 후의 archive log list를 통해 그 변화를

[email protected] 7


확인하자.

[NEWSVC]LIRACLE:/app/oracle/temp> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Wed Sep 21 11:06:15 2005

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Production

With the Partitioning, OLAP and Data Mining options

SYS> archive log list

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /app/oracle/oradata/arch/NEWSVC

Oldest online log sequence 107

Next log sequence to archive 109

Current log sequence 109

SYS> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS> startup

ORACLE instance started.

Total System Global Area 473956352 bytes

Fixed Size 779736 bytes

Variable Size 136583720 bytes

Database Buffers 331350016 bytes

Redo Buffers 5242880 bytes

Database mounted.

Database opened.

SYS> archive log list

Database log mode Archive Mode

[email protected] 8


Automatic archival Enabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 107

Next log sequence to archive 109

Current log sequence 109

위 결과를 통해 archive destination이 db_recovery_file_dest를 사용한다는 의미인

“USE_DB_RECOVERY_FILE_DEST”로 변경되었음이 확인된다.

다음은 log switch를 통해 실제 archive log가 어떻게 쌓이고 있는지를 확인하자.

SYS> alter system switch logfile;

System altered.


System altered.


System altered.

SYS> exit

Disconnected from Oracle Database 10g Enterprise Edition Release

10.1.0.4.0 - Production


[NEWSVC]LIRACLE:/app/oracle/temp> cd ../flash*

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area> cd NEW*

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> ls -l

total 8

drwxr-x--- 3 oracle dba 4096 Sep 21 11:10 archivelog

drwxr-x--- 2 oracle dba 4096 Sep 14 11:23 flashback

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> cd archivelog

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/archivelog> ls -

l

[email protected] 9


total 4

drwxr-x--- 2 oracle dba 4096 Sep 21 11:18 2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/archivelog> cd

2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/archivelog/2005_09_21>

ls -ltr

total 30744

-rw-r----- 1 oracle dba 1024 Sep 21 11:18

o1_mf_1_110_1m1jrctc_.arc


o1_mf_1_109_1m1jrbz1_.arc


o1_mf_1_111_1m1jrjtb_.arc

위 결과를 보면 정상적으로 flash recovery area안에서 archive를 위한 directory

와해당 날짜 directory가 만들어지고 필요한 archive log files이 생성되고 있음을 알

수 있다. 특이한 점은 앞서 parameter를 설정할 때 사용한 log_archive_format이

사용되지 않았다는 것이다.

CF. 만일 첫 번째 방법인 log_archive_dest_n에 flash recovery area를 사용하고

싶다면 아마도 다음과 같은 설정이 가능할 것이다.

log_archive_dest_1 = 'LOCATION=/app/oracle/oradata/arch/NEWSVC'

log_archive_dest_2 = ' LOCATION=USE_DB_RECOVERY_FILE_DEST'

2. control files과 online redo log files : 이들 files은 보통 OMF로 database를

생성하고자 할 때(또는 file 이름을 지정하지 않는 경우) 그 생성위치가 flash

recovery area와 관련이 있을 수 있다. 다음은 initial parameters의 설정 여부에

따른 files의 생성 위치를 설명해주는 표이다. 먼저 간략히 설명하면

db_create_online_log_dest_n가 설정되면 control and redo log files은 이

위치에만 생성된다. 그러나 이 parameter가 설정되지 않은 상태에서

db_create_file_dest, db_recovery_file_dest가 설정되면 이 두 위치에 생성되며

각각 primary, secondary control files 그리고 first, second redo log member가

위치한다. 만일 db_recovery_file_dest만 설정되면 모두 이 위치에만 생성된다. 물론,

아무 parameter도 설정되어 있지 않다면 OS default 위치에 생성될 것이다.

Parameters / Files Control & Redo Log Files

설 정 ② ①, ③ ③ NO

[email protected] 10

표 8-1

Parameter와 File관계


(NO ②) (NO ①, ②) parameter

① db_create_file_dest X O 1st X

OS default②

db_create_online_log_dest_n

O X X

③ db_recovery_file_dest X O 2nd O

사실 이런 내용들을 실제로 테스트하는 것은 간단하다. 위 각각의 case별로

parameter를 설정한 후 “create database”명령을 사용해보면 되기 때문이다.

물론, 이 규칙(우선순위)이 OMF의 “create database” command를 통해서 자동으로

적용이 되기도 하지만 “create controlfile, alter database”와 같은 command에도

적용될 수 있다. 예를 들면 다음과 같다.

SQL> alter database add (standby) logfile…

위 명령을 사용하면서 file의 이름을 지정하지 않은 경우에도 위 우선순위가 적용된다.

SQL> create controlfile…

위 명령을 사용하면서 control_files parameter를 설정하지 않은 경우도 위

우선순위가 적용된다.

3. control file autobackup 및 default RMAN operation : 이와 관련된 files 즉,

RMAN을 통해 backup(혹은 restore archive log files)을 할 경우의 default

location과 이 때 설정에 따라 자동으로 backup이 될 수 있는 control file

autobackup의 결과 files이 flash recovery area에 생성될 수 있다. 그 실제 예를

확인해 보자.

먼저, 테스트를 위해 작은 용량의 tablespace를 생성한 후 해당 datafile의 id를

기억하자.

SYSTEM> create tablespace fra_tbs datafile

2 '/app/oracle/oradata/NEWSVC/fra_tbs01.dbf' size 10M;

Tablespace created.

SYSTEM> select file_id from dba_data_files

2 where tablespace_name = 'FRA_TBS';

FILE_ID

-----------



21

이제 RMAN으로 연결하여 제대로 테스트를 하기 위해(현재 테스트중인 database는

oracle9i에서 upgrade한 것임으로) channel device와 snapshot controlfile name

을 초기화 하자.

[NEWSVC]LIRACLE:/app/oracle/temp> rman target /

Recovery Manager: Release 10.1.0.4.0 - Production


connected to target database: NEWSVC (DBID=3941507194)

RMAN> configure channel device type disk clear;

old RMAN configuration parameters:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT

'/app/oracle/backup/rman/newsvc_%U.bak';

old RMAN configuration parameters are successfully deleted

RMAN> configure snapshot controlfile name clear;

RMAN configuration parameters are successfully reset to default value

다음으로 자동으로 control file을 backup하기 위한 설정과 optimization 설정을 진행

한 후 특정 datafile backup을 실시하자.

RMAN> configure controlfile autobackup on;

using target database controlfile instead of recovery catalog

new RMAN configuration parameters:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

new RMAN configuration parameters are successfully stored

RMAN> configure backup optimization on;




CONFIGURE BACKUP OPTIMIZATION ON;


RMAN> backup datafile 21;

Starting backup at 21-SEP-05

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00021 name=/app/oracle/oradata/NEWSVC/fra_tbs01.dbf

channel ORA_DISK_1: starting piece 1 at 21-SEP-05

channel ORA_DISK_1: finished piece 1 at 21-SEP-05

piece

handle=/app/oracle/flash_recovery_area/NEWSVC/backupset/2005_09_21/

o1_mf_nnndf_TAG20050921T145554_1m1xhc76_.bkp comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 21-SEP-05

Starting Control File Autobackup at 21-SEP-05

piece

handle=/app/oracle/flash_recovery_area/NEWSVC/autobackup/2005_09_21/

o1_mf_n_569602556_1m1xhgvb_.bkp comment=NONE

Finished Control File Autobackup at 21-SEP-05

RMAN> exit

Recovery Manager complete.

이제 flash recovery area에 backup 및 auto controlfile backup이 어떤 구조로 또

제대로 생성이 되었는지를 확인하자.

[NEWSVC]LIRACLE:/app/oracle/temp> cd ../flash_recovery_area/NEWSVC

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> ls -ltr

total 16





drwxr-x--- 3 oracle dba 4096 Sep 21 14:21 backupset

drwxr-x--- 3 oracle dba 4096 Sep 21 14:55 autobackup

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> cd backupset

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/backupset> ls

2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/backupset> cd 2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/backupset/2005_09_21> ls

o1_mf_nnndf_TAG20050921T145554_1m1xhc76_.bkp

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/backupset/2005_09_21> cd ..

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/backupset> cd ../autobackup

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/autobackup> ls

2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/autobackup> cd 2005_09_21

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/autobackup/2005_09_21> ls

o1_mf_n_569602556_1m1xhgvb_.bkp

위 내용을 보면 flash recovery area 안에서 종류별 directory와 현재 날짜 directory

가 생성되고 각각에 해당 backup file과 control file autobackup이 이루어진 것을

확인할 수 있다.

CF. 이 경우(control file autobackup이 진행될 때) 여러분이 spfile을 사용하고

있다면 control file backup이 이루어짐과 동시에 spfile backup이 이루어 진다.

4. data file copy(backup as copy) : 이 copy로 생성되는 copy images가 default

로 flash recovery area에 생성된다.





RMAN> backup as copy datafile 21;





allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=530 devtype=DISK

channel ORA_DISK_1: starting datafile copy


output

filename=/app/oracle/flash_recovery_area/NEWSVC/datafile/o1_mf_fra_tbs_1

m21cg24_.dbf tag=TAG20050921T160205 recid=2 stamp=5

69606526

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01



piece


o1_mf_n_569606527_1m21cjqp_.bkp comment=NONE


RMAN> exit


이제 datafile이 제대로 copy되었는지 확인해 보자.

[NEWSVC]LIRACLE:/app/oracle/temp> cd ../flash*/NEWSVC

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> ls -ltr

total 20



drwxr-x--- 3 oracle dba 4096 Sep 21 14:21 backupset

drwxr-x--- 3 oracle dba 4096 Sep 21 14:55 autobackup

drwxr-x--- 2 oracle dba 4096 Sep 21 16:02 datafile

[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC> cd datafile



[NEWSVC]LIRACLE:/app/oracle/flash_recovery_area/NEWSVC/datafile> ls -l

total 10264

-rw-r----- 1 oracle dba 10493952 Sep 21 16:02 o1_mf_fra_tbs_1m21cg24_.dbf

위 결과를 보면 역시 flash recovery area 위치에 적절한 이름의 datafile directory가

생성되고 그 안에 backup as copy로 copy한 datafile이 생성되었음을 확인할 수 있다.

결론적으로 이런 files과 flash recovery area의 관계를 잘 활용하면 database관리의

차원에서 매우 효율적일 수 있다. 예를 들어 OMF를 사용하고 flash recovery area에

recovery관련 files을 모두 배치시키게 되면 database관리를 최대한 단순화 시킬 수

있을 것이다. 물론, flash recovery area를 사용하는 것을 oracle이 권장하기도

하지만 database의 관리방향변화를 생각해보면 향후 OMF와 flash recovery area의

(그 이름이 어떻게 바뀌든 상관없이 기능면에서) 복합적인 사용이 일반화 되지 않을까

하는 것이 필자의 개인적인 생각이다.

CF. 위에서 설명한 내용을 종합해 볼 때 여러분이 예측할 수 있는 flash recovery area

즉, parameter “db_recovery_file_dest_size”의 최대 크기는 지금 위에서 예시한

내용들의 최대 크기의 합까지 될 수 있다.

8.1.3.2. Flash Recovery Area정보와 Views의 변화지금 설명하고 있는 flash recovery area는 oracle10g의 새로운 개념임으로 당연히

관련 views에서도 변화가 있다. 즉, 위에서 이야기 하고 있는 files의 위치가 flash

recovery area에 속하는가 아닌가를 판단하기 위해 oracle10g는 새로운 column

“is_recovery_dest_file”를 제공한다. 이 값이 “YES”면 flash recovery area에

속하고 있음을 “NO”면 그렇지 않음을 나타낸다. 아래의 예는 앞서 RMAN으로 copy한

datafile의 copy정보를 확인하는 것이다.

SYSTEM> select name, is_recovery_dest_file

2 from v$datafile_copy

3 where file# = 21;

NAME IS_

------------------------------------------------------------------------------------------------------------------

---

/app/oracle/flash_recovery_area/NEWSVC/datafile/o1_mf_fra_tbs_1m21cg24_.dbf

YES



다음은 위 관련 files의 flash recovery area 사용여부를 판단하는 column의

추가여부를 간단하게 보여주고 있다.

SYSTEM> desc v$controlfile

Name Null? Type

----------------------------------------- -------- ------------------------

STATUS VARCHAR2(7)

NAME VARCHAR2(513)

IS_RECOVERY_DEST_FILE VARCHAR2(3)

SYSTEM> desc v$logfile

Name Null? Type

----------------------------------------- -------- ------------------------

GROUP# NUMBER

STATUS VARCHAR2(7)

TYPE VARCHAR2(7)

MEMBER VARCHAR2(513)


SYSTEM> desc v$archived_log

Name Null? Type

----------------------------------------- -------- ------------------------

RECID NUMBER

STAMP NUMBER

NAME VARCHAR2(513)

DEST_ID NUMBER

………

………

………

ACTIVATION# NUMBER


COMPRESSED VARCHAR2(3)

FAL VARCHAR2(3)

SYSTEM> desc v$backup_piece

Name Null? Type



----------------------------------------- -------- ------------------------

RECID NUMBER

STAMP NUMBER

SET_STAMP NUMBER

SET_COUNT NUMBER

………

………

………

DELETED VARCHAR2(3)

BYTES NUMBER


RMAN_STATUS_RECID NUMBER

RMAN_STATUS_STAMP NUMBER

COMPRESSED VARCHAR2(3)

8.1.3.3. Control Flash Recovery Area

현재 RMAN configuration을 em database control에서 확인해보자.

“Maintenance Configure Backup Settings(Backup/Recovery)”을 보면 화면

중앙의 “Disk Backup Location”을 지정하여 disk backup의 위치를 정할 수 있다.

또한 em database control을 통해 flash recovery area를 모두 backup할 수도

있다. 이는 “Maintenance Schedule Backup(Backup/Recovery)”에서 중앙의

“Backup Strategy”를 “Customized”로 선택한 후 “All Recovery Files on Disk”를

선택하면 flash recovery area를 포함한 모든 recovery files을 backup할 수 있다.


표 8-2

Disk Backup 위치설정


CF. RMAN의 command로 flash recovery area를 backup하기 위해 다음과 같은

명령들을 사용할 수 있다.

RMAN> backup recovery area;

이 명령은 이전에 backup되지 않은 flash recovery area의 files을 backup한다.

RMAN> backup recovery files;

이 명령은 이전에 backup되지 않은 모든 recovery files을 backup한다.

다음은 현재 flash recovery area에 대한 정보를 view를 통해 확인하는 방법이다.

SYSTEM> col name for a35

SYSTEM> select * from v$recovery_file_dest;

SYSTEM> select name, space_limit limit, space_used used,

2 space_reclaimable reclaim, number_of_files files


그림 8-3

Backup 스케쥴 설정


3 from v$recovery_file_dest;

NAME LIMIT USED RECLAIM FILES

------------------------------------------------ -------------- ---------------- -----------------

---------------

/app/oracle/flash_recovery_area 2147483648 581595648 10928128

136

위 정보는 현재 flash recovery area의 위치 할당된 size, 현재 사용량, 앞서 flash

recovery area 속성에서 설명한 space 부족 시 처리에 의해 삭제된 files size 그리고

현재 존재하는 files의 수를 보여준다.



OCP point

==============================================

=================

1. flash recovery area 위치설정과 size결정

2. flash recovery area로 관리하는 files의 종류

3. db_create_file_dest, db_create_online_log_dest_n, db_recovery_file_dest과

controlfile, redo log file의 관계

참조

==============================================

=================

RMAN : o8 73p, o8i 172p, o9i 470p

channel : o8 83p

control file autobackup : o9i 468p



8.2. Recovery and Incremental Backup

8.2.1.개요Oracle10g는 이제 datafile의 image copy에 대하여 incremental backup본을

이용하여 recovery를 할 수 있다. 즉, datafile image copies에 변경된 blocks을

update함으로써 recovery시 incremental backup을 사용한다는 것이다. 이는

incremental backup이 datafiles에 발생하는 각 blocks의 SCN을 read하여 이전의

incremental backup SCN과 비교한 후 그 값이 같거나 크면 해당 blocks을 copy

함으로써 backup이 이루어지기 때문이다. 다시 말해, 이 기능은 database recovery

가 필요한 경우 recovery시점을 기준으로 마지막 incremental backup 이후의

archive log만 적용하면 되기 때문에 전체적인 recovery 시간을 상당히 줄여준다는

강점이 있다.

CF. incremental restore를 진행한 후에 full image copy를 수행할 필요도 없다.

8.2.2.Incremental Backup

8.2.2.1. Changed Block Backup

Incremental backup은 datafiles, tablespace 혹은 database를 대상으로 RMAN을

통해 만들 수 있다. Recovery시 RMAN은 restored files을 check하여 incremental

backup본의 사용가능성을 확인하고 가능하다면 archive log대신 가장 빠른 방법인 이

incremental backup본을 활용한다. Recovery가 필요한 모든 변경내역에 대하여

개별적으로 archive log를 적용하는 방식 보다는 block level로 처리하는 것이 훨씬 더

빠르기 때문이다. 따라서 incremental backup을 수행할 때에는 아주 작은 부분의

변경이라도 모두 incremental backup에 포함 되어야 하기 때문에 incremental

backup이 발생하는 동안 대상 datafile은 모두 다 read되어야 한다. 물론, 그 read

시간도 부담이라면 부담이 될 수도 있다. 아니 oracle은 그 시간이 부담이 되는

시간이라고 판단한 것 같다. 왜냐하면 oracle10g부터는 change tracking file이라는

새로운 개념을 제시하고 있기 때문이다.

8.2.2.2. Fast Incremental Backup

Oracle10g는 새로운 type의 file인 change tracking file을 소개하고 있다. 이 file을

사용하면 incremental backup을 수행하는 동안 datafile을 다 read할 필요가 없다.

즉, backup시간을 더 빠르게 할 수 있는 이른바 “Fast Incremental Backup”이

가능해지는 것이다. 이 file은 새로운 background process인 CTWR (change

tracking writer)에 의해 write된다. 이 change tracking file의 최소 size는 10MB

이며 새로운 space가 필요할 때 마다 10MB씩 증가된다. 이는 마치 SGA에서 redo



generation을 하듯이 CTWR에 의해 file로 write된다. 따라서 이 기능을 통해

database backup을 하는 동안 변경된 blocks의 물리적인 위치를 추적할 수 있고

해당 blocks만 read하여 incremental backup이 가능하게 된다.

CF. 단, 이 block change를 기록하는 기능은 oracle10g가 default로 제공하지는 않기

때문에 필요하다면 직접 enable해야 한다.

Fast incremental backup을 enable하기 위해서는 다음과 같은 SQL 또는 em을

통해서 할 수 있다.

1. SQL 상에서

SQL> alter database {enable|disable} block change tracking [using file

‘…’];

CF. alter database rename file command를 통해 위에서 만든 change tracking

file의 이름도 바꿀 수 있지만 이 때에 database는 반드시 mount 상태이어야 한다.

(control file을 update하게 된다). 만일, file이름을 지정하지 않으면 OMF rule에

의해 자동으로 생성된다.

2. em 상에서

“Maintenance Configure Backup Settings(Backup/Recovery) Policy”

화면에서 “Enable block change tracking for faster incremental backups”를

선택하면된다.

8.2.3.Example

다음은 위에서 설명한 내역들을 간단하게 구현해 본 예제이다. 먼저, 앞서 테스트를

위해 만들었던 tablespace 'FRA_TBS'를 대상으로 table을 생성하여 backup을


그림 8-4

Backup 정책설정


수행한다.

SQL 창 :

SCOTT> create table x_data ( x_col number) tablespace fra_tbs;

Table created.

SCOTT> begin

2 for i in 1..10000 loop

3 insert into x_data values (i);

4 end loop;

5 commit;

6 end;

7 /

PL/SQL procedure successfully completed.

Backup 창 : (주의 아래 결과에서 현재 최초 backup 시점이 27-SEP-05라는 것을

기억하자. 이는 나중에 backup 확인을 위해 사용할 것이다)





RMAN> backup tablespace fra_tbs;









input datafile fno=00021

name=/app/oracle/oradata/NEWSVC/fra_tbs01.dbf



piece


o1_mf_nnndf_TAG20050927T173419_1ml10dbq_.bkp comment=NONE




piece

handle=/app/oracle/flash_recovery_area/NEWSVC/autobackup/2005_09_27

/o1_mf_n_570130468_1ml10vcz_.bkp comment=NONE


이제 다시 한번 data를 생성한 후 다시 backup을 해보자. 이 과정을 두 번

반복함으로써 보다 정확한 테스트를 할 것이다.

SQL 창 :

SCOTT> begin



4 end loop;

5 commit;

6 end;

7 /


Backup 창 :

RMAN> backup incremental level 1

2> tablespace fra_tbs;





channel ORA_DISK_1: starting incremental level 1 datafile backupset





piece


o1_mf_nnnd1_TAG20050927T175627_1ml29yqg_.bkp comment=NONE




piece


o1_mf_n_570131793_1ml2b6cv_.bkp comment=NONE


SQL 창 :

SCOTT> begin



4 end loop;

5 commit;

6 end;

7 /


Backup 창 :












piece


o1_mf_nnnd1_TAG20050927T175938_1ml2hvbn_.bkp comment=NONE




piece


o1_mf_n_570131980_1ml2hy00_.bkp comment=NONE


이제 fast incremental backup을 적용해 보자.

SQL 창 :

SYS> conn scott/tiger

Connected.

SCOTT> conn system/manager

Connected.

SYSTEM> alter database enable block change tracking;

alter database enable block change tracking

*

ERROR at line 1:

ORA-19773: must specify change tracking file name

SYSTEM> alter database enable block change tracking

2 using file '/app/oracle/flash_recovery_area/NEWSVC/tracking/trc.dbf';

Database altered.

SYSTEM> !ls -ltr /app/oracle/flash_recovery_area/NEWSVC/tracking



total 11348

-rw-r----- 1 oracle dba 11600384 Sep 28 11:19 trc.dbf

위 예는 tracking file을 만들어 database를 block change tracking이 가능하도록

설정한 것이다. 만일, 여러분이 OMF를 사용하고 있다면 위에서 error가 발생한 file

이름을 지정하지 않은 SQL은 아무 문제없이 성공했을 것이다.

이제 이 file에 write를 담당하는 background process “CTWR”이 제대로

구동되었는지는 다음과 같이 확인하면 된다.

SYSTEM> !ps -ef | grep ora_c

oracle 8745 1 0 10:23 ? 00:00:00 ora_ckpt_NEWSVC

oracle 8751 1 0 10:23 ? 00:00:00 ora_cjq0_NEWSVC

oracle 11120 1 0 11:08 ? 00:00:00 ora_ctwr_NEWSVC

oracle 13714 13710 0 13:01 pts/0 00:00:00 /bin/bash -c ps -ef | grep

ora_c

oracle 13716 13714 0 13:01 pts/0 00:00:00 grep ora_c

이제 계속 테스트를 진행하고 있는 동일한 data 생성 작업과 backup 작업을 다시

수행해 보자.

SQL 창 :

SYSTEM> conn scott/tiger

Connected.

SCOTT> begin



4 end loop;

5 commit;

6 end;

7 /


Backup 창 :












piece


o1_mf_nnnd1_TAG20050928T122101_1mn30yl4_.bkp comment=NONE




piece


o1_mf_n_570198066_1mn314yy_.bkp comment=NONE


이제 앞서 기본 incremental backup때와 마찬가지로 같은 과정을 반복해보자. 앞서도

잠깐 언급을 했었지만 change tracking file을 만들게 되면 새로운 oracle

background process “CTWR”에 의해 write된다고 했다. 따라서 위에서 block

change tracking 설정을 한 후 너무 빨리 작업을 진행하면 미쳐 CTWR에 의해

change tracking file에 write가 발생하지 않았을 수도 있음으로 한번 더 동일한

작업을 진행해보자는 것이다.

SQL 창 :

SCOTT> begin



4 end loop;

5 commit;

6 end;

7 /




Backup 창 :










piece


o1_mf_nnnd1_TAG20050928T122241_1mn3428h_.bkp comment=NONE




piece


o1_mf_n_570198163_1mn3456d_.bkp comment=NONE


다음은 block change tracking을 확인해보는 과정이다. 먼저, 현재 설정된 block

change tracking의 정보는 다음과 같이 볼 수 있다.

SCOTT> conn system/manager

Connected.

SYSTEM> select * from v$block_change_tracking;

STATUS FILENAME BYTES

-------------- --------------------------------------------------------------------------------------

-------------

ENABLED /app/oracle/flash_recovery_area/NEWSVC/tracking/trc.dbf



11599872

다음으로 앞서 여러 차례의 incremental backup과 block change tracking과의

관계를 확인해 보자. 앞서 최초 backup을 수행할 때에(incremental backup전에

수행한 tablespace backup) 그 시점이 “27-SEP-05”이였음을 확인한 바 있다. 이

날짜와 backup된 tablespace의 datafile id를 기준으로 backup 정보를 조회해 보자.

CF. 현재 테스트를 진행하면서 기본 incremental backup은 27일, change tracking

file의 생성은 28일에 한 것임으로 다음의 예를 이해할 때 헛갈리지 말자.

SYSTEM> select incremental_change# ic#, used_change_tracking track,

2 datafile_blocks df_blks, blocks cp_blks, blocks_read rd_blks

3 from v$backup_datafile

4 where file# = 21 and to_char(completion_time, 'YYYY-MM-DD') >=

'2005-09-27'

5 order by completion_time;

IC# TRA DF_BLKS CP_BLKS RD_BLKS

--------------- ------ -------------- ------------ --------------

0 NO 1280 29 1280

9725734841 NO 1280 40 1280

9726192250 NO 1280 21 1280

9726192411 NO 1280 22 1280

9726251183 YES 1280 20 128

SYSTEM> exit




[NEWSVC]LIRACLE:/app/oracle/temp> cd ..

[NEWSVC]LIRACLE:/app/oracle>

위 결과를 보면 최초에는 image copy로 incremental이 없었고 전체 datafile의

block 1280에 대하여 20개에서 40개까지의 block 내역을 backup하였음을

보여준다. 그리고 마지막에 block change tracking이 적용되어서 block reads가

나머지 4회는 전체 block read 1280이었지만 마지막에는 128(10% read) blocks만



read하여 backup을 성공했다. 즉, block change tracking이 적용되면 datafile이

크면 클수록 그 backup 성능이 좋아질 것이라고 충분히 예측할 수 있다.

CF. 위 결과를 보면 동일한 data 생성 작업을 4회 실시하기는 하였지만 block에

들어가는 rows의 수는 충분히 편차가 있을 수 있음으로 그 blocks column의 값은 각

backup 시점마다 차이를 보여주고 있다. 이는 곧 backup되는 file의 size와 연관이

있을 수 밖에 없다. 다음의 결과 file의 size와 위 blocks 값의 비례가 일치함을 확인해

보라.

[NEWSVC]LIRACLE:/app/oracle> ls -ltr ./flash_recovery_area/NEWSVC/backupset/2005_09_27

total 828


o1_mf_nnndf_TAG20050927T173419_1ml10dbq_.bkp


o1_mf_nnnd1_TAG20050927T175627_1ml29yqg_.bkp


o1_mf_nnnd1_TAG20050927T175938_1ml2hvbn_.bkp

[NEWSVC]LIRACLE:/app/oracle> ls -ltr ./flash_recovery_area/NEWSVC/backupset/2005_09_28

total 408


o1_mf_nnnd1_TAG20050928T122101_1mn30yl4_.bkp


o1_mf_nnnd1_TAG20050928T122241_1mn3428h_.bkp

OCP point

==============================================

=================

1. change tracking file의 의미

2. block change tracking의 oracle10g default 값

3. block change tracking을 사용하는 목적



8.3. RMAN and Backup

8.3.1.Backup Management

8.3.1.1. Backup 전략Oracle em의 database control은 사용자의 편의를 위해 oracle이 제안하는 backup

전략을 제시하고 있다. 즉, oracle이 제안하는 전략을 선택하면 빠르고 쉽게 backup

전략을 완료할 수 있다는 것이다.

“Maintenance Schedule Backup(Backup/Recovery)”에서 다음과 같은 화면을

볼 수 있다. 여기서 좌측 상단에 있는 “List Box“에서 “Oracle-suggested”를

선택하거나 “Customized”를 선택할 수 있다. “Customized”는 말 그대로 DBA가

전략을 세우는 것이지만 “Oracle-suggested”를 선택하면 기본 backup 전략을 쉽게

세울 수 있게 되는 것이다.

여기서 host username/password를 입력하고 “Next”를 선택하면 다음과 같은

화면으로 이동한다.


그림 8-5

Backup 전략설정


위 화면은 단계별로 backup 전력을 세우는 과정의 첫 번째 단계를 보여주고 있다.

필요하다면 계속해서 “Next”를 통해 oracle이 제안하는 backup전략을 완료할 수 있을

것이다.

CF. 이 전략을 채택하게 되면 우선 최초 backup으로 full backup을 실시하게 된다.

그리고 매일 incremental backup을 수행하게 되는데 disk backup 본은 database

crash 발생시 하루 전까지의 full database recovery 및 point-in-time을 보장할 수

있도록 유지된다.

8.3.1.2. Compressed Backup

Backup and Recovery 전략을 세우는데 있어서 storage 정책 즉, backup data의

양을 판단하고 보관주기 등을 설정하는 것은 매우 중요한 일이다. 특히나 요즘처럼

대용량 데이터베이스 환경에서 backup의 space는 중요한 고려사항이 될 터이다.

Oracle10g는 일정부분 이런 어려움을 도와주고자 compress 개념을 도입한 binary

compression을 지원한다. 그야말로 backup과 동시에 압축을 하겠다는 의미가

되겠다. 물론, 압축을 통한 space의 절약만큼 압축작업을 수행하는 CPU 부담이라는

trade-off는 감수해야 할 것이다.

1. initial parameter compatibility 10.0.0 이상 이어야 한다.

2. image copies가 아닌 backupset만을 compress할 수 있다.

3. 만일, compress option을 미리 설정해 놓고 싶다면 configure device type

command를 사용하여 다음과 같이 하면 된다.

RMAN> configure device type disk backup type to compressed backupset;

4. compressed backups을 restore하는 것은 특별한 option을 필요로 하지 않는다.


그림 8-6

Backup 전략설정


간단한 compressed backupset을 만들어 보자. 먼저 정상적인 backupset의 생성을

위해 tablespace system의 정보를 확인한 후 compress backup을 구현해보자.

SQL 창 :

SYSTEM> select bytes+8192 from dba_data_files

2 where tablespace_name = 'SYSTEM';

BYTES+8192

-----------------

555753472

RMAN 창 :

테스트를 위해 임시로 사용할 channel을 먼저 설정하자.

RMAN> configure channel device type disk format '/app/oracle/temp/%U';


CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/app/oracle/temp/%U';


이제 두 가지 형태의 backupset, 전통적인 backupset과 compressed backupset을

생성하자. Backupset의 생성이 끝나면 channel을 clear하여 원래의 상태로 되돌린다.

RMAN> backup as backupset tablespace system;







name=/app/oracle/oradata/NEWSVC/systemNEWSVC01.dbf



piece handle=/app/oracle/temp/1mgvugvr_1_1 comment=NONE






piece


o1_mf_n_570377432_1msl6fb0_.bkp comment=NONE


RMAN> backup as compressed backupset tablespace system;



channel ORA_DISK_1: starting compressed full datafile backupset






piece handle=/app/oracle/temp/1ogvui27_1_1 comment=NONE




piece


o1_mf_n_570378526_1msm8n4w_.bkp comment=NONE


RMAN> configure channel device type disk clear;



CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/app/oracle/temp/%U';

old RMAN configuration parameters are successfully deleted

위에서 생성된 두 backupset과 원래의 system tablespace를 구성하고 있는

datafile의 size를 확인하면 다음과 같다.



[NEWSVC]LIRACLE:/app/oracle/temp> ls -ltr 1mgvugvr_1_1 1ogvui27_1_1

-rw-r----- 1 oracle dba 452313088 Sep 30 14:09 1mgvugvr_1_1

-rw-r----- 1 oracle dba 94126080 Sep 30 14:28 1ogvui27_1_1

[NEWSVC]LIRACLE:/app/oracle/temp> cd ../oradata/NEWSVC/

[NEWSVC]LIRACLE:/app/oracle/oradata/NEWSVC> ls -l system*

-rw-r----- 1 oracle dba 555753472 Sep 30 14:54 systemNEWSVC01.dbf

위에서 보듯 원래의 size보다 backupset이 더 작고(image copy였다면 똑

같았겠지만backupset을 구성할 때는 필요한 blocks만 받으면 된다) 압축된

backupset은 datafile보다 83%이상, 같은 backupset에 비해 79%이상 작아졌음을

알 수 있다.

CF. 물론, tablespace의 data유형에 따라(text가 주류이면 매우 좋은 압축률을 보일

것이다) 매우 다르기는 하지만 oracle은 적어도 2 ~ 4배까지 압축률을 높일 수 있다고

한다.

다른 것과 마찬가지로 이 기능도 em database control에서 “Maintenance

Configure Backup Settings(Backup/Recovery)”을 통해 사용할 수 있다. 중앙의

“Disk Backup Type”을 확인하라.

8.3.1.3. Duration and Throttling

중단 없는 database system을 운영하는 경우 즉, 24시간 365일 운영이 되어야 하는

database system의 경우에는 어쩔 수 없이 backup으로 인해 database 운영성능에

영향을 주는 문제도 그냥 넘길 부분이 아닐 수 있다. 그렇다고 backup을 포기할 수도

없고. 물론, 요즘은 disk level의 고급 기술을 통해 disk-to-disk backup을 진행하여


그림 8-7

Compressed Backup 설정


그 위험성을 줄이는 경우도 있지만 모두가 고가의 시스템구성을 하라고 강요할 수도

없는 것이 아닌가.

이러한 운영시스템에 부담을 최소화하는 전략은 항상 제기될 수 밖에 없는 문제이다.

Oracle이 RMAN을 사용하면서 이런 부담을 줄여주기 위해 제공하는 기능으로

oracle10g 이전에는 초당, file당 RMAN channel이 read하는 양을 조절하는 기법을

소개한 바 있다. 이번에 oracle10g는 더 나아가 작업 시간을 설정하는 기능을

제공함으로써 운영 시스템에 대한 부담을 최소화할 수 있는 환경을 만들어주고 있다.

이는 backup command에 추가되는 option을 통해 이루어 진다. 다음의 형식을 보자.

RMAN> backup … duration <hour>:<minute> [partial] [minimize {time|

load}]

1. partial : 이 partial을 지정하게 되면 지정된 시간 안에 backup이 다 끝나지 않아도

error를 발생시키지 않는다. 그러나 partial을 지정하지 않고(default) 지정된 시간

안에 backup이 완료되지 않으면 backup은 취소되고 RMAN은 error와 함께

종료된다. 하지만 backup이 중단되면 이 option의 지정과 상관없이 이미 완료된

backup sets은 catalog에 기록되고 진행 중 이었던 backup sets은 다시 start되어야

한다.

2. minimize time : 가능한 지정된 시간에 backup이 완료되도록 backup을 빠른

속도로 진행한다.

3. minimize load : 이는 지정된 시간에 backup이 수행되는지를 스스로 monitoring

하면서 그 속도를 줄이도록 한다. 단, tape의 경우 가능한 빨리 backup이 되어야 하기

때문에 이 option이 사용될 수 없다.

CF. 이 option으로 인해 이전 version의 RATE, READRATE option은 obsolete

되었다. Oracle10g는 위 duration option을 어떻게 달성할 것인가를 설정하는

minimize time, load option을 압박한다는 의미로 “throttling” option이라 부른다.

다음의 예는 이 duration, throttling option의 설정과 작업 시간을 직접 확인해보는

예이다. 그런데 실제로 minimize load option은 시간이 오래 걸리기 때문에 아래의

예를 눈으로만 확인을 하던지 아니면 여러분은 각자 duration을 몇 분 단위로 줄여서

직접 해보기 바란다. 두 차례의 backup의 결과에서 “elapsed time”을 눈 여겨 보고 그

시간과 duration을 비교해 보자. 테스트는 1시간 5분을 duration으로 사용할 것이다.

먼저, minimize time으로 해보자.



RMAN> backup duration 1:05 minimize time tablespace tools;

Starting backup at 06-OCT-05






input datafile fno=00010 name=/app/oracle/oradata/NEWSVC/tool.dbf

channel ORA_DISK_1: starting piece 1 at 06-OCT-05

channel ORA_DISK_1: finished piece 1 at 06-OCT-05

piece


o1_mf_nnndf_TAG20051006T152439_1n9js7x6_.bkp comment=NONE


Finished backup at 06-OCT-05

Starting Control File Autobackup at 06-OCT-05

piece


o1_mf_n_570986694_1n9jssks_.bkp comment=NONE

Finished Control File Autobackup at 06-OCT-05

위 작업 시간을(elapsed time) 보면 15초 만에 tools tablespace가 backup되었음을

알 수 있다.

다음은 minimize load로 동일한 backup을 수행해보자.

RMAN> backup duration 1:05 minimize load tablespace tools;










piece


o1_mf_nnndf_TAG20051006T152749_1n9jz5g5_.bkp comment=NONE


channel ORA_DISK_1: throttle time: 1:60:43



piece


o1_mf_n_570990560_1n9nllmc_.bkp comment=NONE


이번에는 총 1시간 1분 31초가 걸렸다. 즉, duration을 거의 맞추고 있는 것이다.

8.3.1.4. Copy and As Copy

Orcle10g는 과거 RMAN에서 사용하던 copy를 대신하여 보다 확장된 기능을 하는

“backup as copy”를 사용하도록 권고하고 있다. 따라서 copy command를 통해

image copy를 위해 일일이 datafiles을 copy하는 불편함을 줄일 수 있게 되었고

과거와 달리 backup set으로부터 필요한 restore를 위해 RMAN을 사용하지 않고

copy image를 그대로 사용할 수 있도록 할 수도 있게 되었다.

1. new command “copy”를 사용하여 image copies를 생성 및 backup sets생성의

예

RMAN> backup as copy database;

RMAN> backup as backupset database;

2. 만일 backups을 항상 image copy형태로 유지하고자 한다면 다음과 같은 설정을

통해 default backup의 action을 image copy로 할 수 있도록 변경이 가능하다.

RMAN> configure device type disk backup type to copy;

필요에 의해 원상태로 복구하는 것은(default) 다음과 같이 한다.

RMAN> configure device type disk clear;

CF. 그러나 backups의 image copy는 그 대상이 disk인 경우에 한한다. Tape은

backup sets으로 저장되어야 한다. 위 예도 device type을 분명히 disk로 한정하고

있음을 주목하자.



8.3.2.Catalog Control

8.3.2.1. Add and Delete Catalog

Oracle10g는 catalog command를 통해 다른 형태로 만들어진 backup copy본을

catalog에 추가하여 사용할 수 있다. 이는 직접 만들어 놓은 image copy(begin

backup – OS copy – end backup)나 backup본을 직접 OS상에서 copy를 해놓았던

것이나 다 가능하다. 아래의 예는 이 두 가지 유형의 copies가 어떻게 catalog와

연동이 될 수 있는지 확인해본 것이다.

먼저 manual backup(사용자 직접작업)을 해보자.

SYSTEM> select file_name from dba_data_files

2 where tablespace_name = 'FRA_TBS';

FILE_NAME

--------------------------------------------------------------------------------

/app/oracle/oradata/NEWSVC/fra_tbs01.dbf

SYSTEM> alter tablespace fra_tbs begin backup;

Tablespace altered.

SYSTEM> !cp /app/oracle/oradata/NEWSVC/fra_tbs01.dbf /app/oracle/temp/

SYSTEM> alter tablespace fra_tbs end backup;

Tablespace altered.

SYSTEM> !ls -l /app/oracle/temp/fra_tbs01.dbf

-rw-r----- 1 oracle dba 10493952 Sep 28 17:33 /app/oracle/temp/fra_tbs01.dbf

SYSTEM> exit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 -

Production


[NEWSVC]LIRACLE:/app/oracle/temp>



다음은 기존의 RMAN copies를 OS상에서 copy하여 이름을 변경한 경우이다. 즉,

필요에 의해 특정 copies를 다른 곳에 보관하고 있다가 사용할 경우이다.

[NEWSVC]LIRACLE:/app/oracle/temp> cd ..

[NEWSVC]LIRACLE:/app/oracle> mkdir interim

[NEWSVC]LIRACLE:/app/oracle> cd interim

[NEWSVC]LIRACLE:/app/oracle/interim> cp

../flash_recovery_area/NEWSVC/backupset/2005_09_27/*.bkp ./

[NEWSVC]LIRACLE:/app/oracle/interim> ls

o1_mf_nnnd1_TAG20050927T175627_1ml29yqg_.bkp

o1_mf_nnndf_TAG20050927T173419_1ml10dbq_.bkp

o1_mf_nnnd1_TAG20050927T175938_1ml2hvbn_.bkp

[NEWSVC]LIRACLE:/app/oracle/interim> mv

o1_mf_nnndf_TAG20050927T173419_1ml10dbq_.bkp 20050927_1.bkp


o1_mf_nnnd1_TAG20050927T175627_1ml29yqg_.bkp 20050927_2.bkp


o1_mf_nnnd1_TAG20050927T175938_1ml2hvbn_.bkp 20050927_3.bkp


20050927_1.bkp 20050927_2.bkp 20050927_3.bkp

이제 RMAN으로 login하여 이 두 가지 유형의 4가지 copies를 catalog로 이식해 보자.

[NEWSVC]LIRACLE:/app/oracle/interim> rman target /




RMAN> catalog datafilecopy '/app/oracle/temp/fra_tbs01.dbf';

cataloged datafile copy

datafile copy filename=/app/oracle/temp/fra_tbs01.dbf recid=3 stamp=570217956

RMAN> catalog backuppiece '/app/oracle/interim/20050927_1.bkp';



cataloged backuppiece

backup piece handle=/app/oracle/interim/20050927_1.bkp recid=17

stamp=570217783




stamp=570217806




stamp=570217853

다른 SQL 창에서 위 결과를 확인해 보자. 먼저, backup piece를 보자.

SYSTEM> col handle for a40

SYSTEM> col worked_date for a20

SYSTEM> select handle,

2 to_char(completion_time, 'YYYY-MM-DD HH24:MI:SS') worked_date

3 from v$backup_piece where handle like '%interim%';

HANDLE WORKED_DATE

--------------------------------------------------- -------------------------

/app/oracle/interim/20050927_1.bkp 2005-09-28 17:50:01



다음으로 datafile의 copy가 제대로 catalog되었는지를 보자.

SYSTEM> col name for a30

SYSTEM> select name,

2 to_char(checkpoint_time, 'YYYY-MM-DD HH24:MI:SS') worked_date

3 from v$datafile_copy



4 where name is not null and file# = 21;

NAME WORKED_DATE

--------------------------------------------- -------------------------

/app/oracle/temp/fra_tbs01.dbf 2005-09-28 17:33:20

이제 반대의 경우를 생각해 보자. 앞서 catalog에 등록한 backup piece중 특정한

것이 삭제되어 더 이상 사용할 수 없게 되었다고 가정하자. 먼저 OS상에서 이를

삭제하자.


20050927_1.bkp 20050927_2.bkp 20050927_3.bkp

[NEWSVC]LIRACLE:/app/oracle/interim> rm 20050927_1.bkp


20050927_2.bkp 20050927_3.bkp

이제 RMAN 창에서 삭제된 file을 catalog에서 제거하자.

RMAN> change backuppiece '/app/oracle/interim/20050927_1.bkp' uncatalog;


uncataloged backuppiece


stamp=570217783

Uncataloged 1 objects

마지막으로 다시 SQL창에서 변경된 결과가 잘 반영이 되었는지 확인하자.

SYSTEM> select handle,

2 to_char(completion_time, 'YYYY-MM-DD HH24:MI:SS') worked_date

3 from v$backup_piece where handle like '%interim%';

HANDLE WORKED_DATE

--------------------------------------------------- -------------------------



위에서 보듯이 catalog가 제대로 정리된 것을 확인할 수 있다.



8.3.2.2. Management Using em

원한다면 이런 작업을 em의 database control에서 “Maintenance Manage

Current Backups(Backup/Recovery)”로 이동하여 다음과 같이 할 수도 있다. 먼저

아래 화면의 중앙 우측을 보면 “Catalog Additional Files”이 있다. 현재 화면에는

보이지 않지만 화면의 끝에는 OS username/password를 입력하는 부분이 있다. 이를

입력한 후 이 버튼을 눌러보자.

아래 화면을 사용하여 catalog에 등록을 할 수가 있다.

8.3.3.Backup and Copy

8.3.3.1. 개요Oracle10g는 backups을 가지고 image copies를 만들어낼 수 있다. 거의 대부분의

backup command와 함께 copy를 지원하는데 이를 유형별로 정리하면 다음과 같다.

유 형 Backup Copy


그림 8-8

Backup Set 관리화면

그림 8-9

Catalog 등록화면


databas

e

backup database ; backup copy of database ;

tablespa

ce

backup tablespace name; backup copy of tablespace name;

datafile backup datafile ? or ‘name’; backup copy of datafile ? or

‘name’ ;

controlfil

e

backup current controlfile; backup controlfilecopy

‘filename’;

CF. 위에서 backup current controlfile은 alter database backup controlfile을

통해 만들어지는 backup과 같다.

8.3.3.2. Example for Tablespace

구체적으로 tablespace에 대하여 그 기능의 수행여부를 확인해 보자. 가장 먼저

사용하는 command는 앞서 “backup as copy”에서 언급했던 backup type을 copy

로 변경하는 것이다.

RMAN> configure device type disk backup type to copy;


CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;


지금 테스트할 backup and copy의 대상은 앞서 “chapter 3”에서 bigfile

tablespace를 위해 만들었던 50MB 크기의 bigdata tablespace를 사용할 것이다.

다음은 그 기초정보이다.

SYSTEM> select bytes + 8192 from dba_data_files

2 where tablespace_name = 'BIGDATA';

BYTES+8192

-----------------

52436992

위에서 보듯이 50MB 크기에 OS header block 8KB를 더한 크기가 실제 OS상에

존재하는 이 tablespace를 구성하는 datafile의 크기이다. 이를 기억한 후 조금 후에

다시 확인해 보자.



다음은 tablespace에 대한 backup이 copy로 이루어지는지를 확인하고 해당 copy에

대한 copy backup을 수행해보자.

RMAN> backup tablespace bigdata;





input datafile fno=00020 name=/app/oracle/oradata/NEWSVC/big01.dbf

output

filename=/app/oracle/flash_recovery_area/NEWSVC/datafile/o1_mf_bigdata_1ms5k9

69_.dbf tag=TAG20050930T103432 recid=4 stamp=5

70364486




piece handle=/app/oracle/flash_recovery_area/NEWSVC/autobackup/2005_09_30/

o1_mf_n_570364489_1ms5ky5q_.bkp comment=NONE


RMAN> backup copy of tablespace bigdata;




input is copy of datafile 00020:

/app/oracle/flash_recovery_area/NEWSVC/datafile/o1_mf_bigdata_1ms5k969_.dbf

output

filename=/app/oracle/flash_recovery_area/NEWSVC/datafile/o1_mf_bigdata_1ms5n1

sy_.dbf tag=TAG20050930T103432 recid=5 stamp=5

70364575






piece handle=/app/oracle/flash_recovery_area/NEWSVC/autobackup/2005_09_30/

o1_mf_n_570364578_1ms5nrns_.bkp comment=NONE


위 결과를 보면 tablespace에 대한 backup이 자동적으로 image copy로

이루어졌으며(datafile의 backup된 위치도 이전에 수 차례 보아왔던 “backupset”이

아니라 “datafile”인 점을 유의하자) 이에 대한 backup copy도 성공적으로

수행되었음을 알 수 있다.

앞서 잠깐 언급했던 OS상에서의 size를 확인해 보면 다음과 같다.

SYSTEM> select bytes + 8192 from dba_data_files

2 where tablespace_name = 'BIGDATA';

BYTES+8192

-----------------

52436992

SYSTEM> !pwd

/app/oracle/temp

SYSTEM> !ls -l ../flash*/NEWSVC/datafile/

total 102528

-rw-r----- 1 oracle dba 52436992 Sep 30 10:34 o1_mf_bigdata_1ms5k969_.dbf

-rw-r----- 1 oracle dba 52436992 Sep 30 10:36 o1_mf_bigdata_1ms5n1sy_.dbf

위와 같이 최초 backup을 통해 생성된 copy본과 이를 이용하여 copy된 copy본을

확인할 수 있다.

CF. 여러분이 datafile #1과 같이 system tablespace에 대한 backup command를

수행하면서 controlfile autobackup을 off 상태로 해 두었다면 RMAN은 backup과

동시에 controlfile에 대한 copy를 만들고 spfile도 생성한다.

8.3.3.3. Controlfile and Controlfilecopy

이미 controlfile의 backup과 copy에 대한 언급은 했었지만 보다 구체적인 접근을

해보자. 일반적인 controlfile backup은 다음과 같이 만들어진다.



RMAN> backup as copy current controlfile;

이는 곧 SQL에서 다음과 같이 만들어지는 controlfile과 같다.

SQL> alter database backup controlfile to 'name’;

만일, standby database를 운영하고 있고 primary database에서 standby

database controlfile에 대한 backup을 한다면 다음과 같다. (물론, standby

database에 접속하여 standby database의 controlfile을 backup한다면 일반적인

방식을 사용하면 되겠다)

RMAN> backup as copy current controlfile for standby;

이는 곧 SQL에서 다음과 같이 만들어지는 controlfile과 같다.

SQL> alter database create standby controlfile as ‘name’;

위에서 만들어진 모든 형식의 controlfile은 모두 backup controlfilecopy로 copy할

수 있다.

RMAN> backup controlfilecopy ‘name’ ;

또한 다음과 같은 option을 통해 모든 backup 가능한 controlfile을 copy하는 것도

가능하다.

RMAN> backup controlfilecopy all;



OCP point

==============================================

=================

1. compressed backup의 의미와 사용 및 설정법

2. backup의 duration, throttling option의 이해



8.4. RMAN and Recovery

8.4.1.Backup and Fast Recovery

8.4.1.1. Full Backup

다음은 향후에 발생하는 recovery 테스트를 위해 또한 혹시 발생할지 모르는 위험한

상황을(실수로 files을 삭제하거나 하는 등의) 미리 대비하기 위하여 전체 database

backup을 받는 과정이다. 각자 backup database를 수행하자.

RMAN> backup database;








input datafile fno=00019 name=/app/oracle/oradata/NEWSVC/sysaux01.dbf


name=/app/oracle/oradata/NEWSVC/exampleNEWSVC01.dbf

input datafile fno=00004 name=/app/oracle/oradata/NEWSVC/users.dbf

input datafile fno=00008 name=/app/oracle/oradata/NEWSVC/drsys01.dbf


input datafile fno=00002 name=/app/oracle/oradata/NEWSVC/undo01.dbf


input datafile fno=00009 name=/app/oracle/oradata/NEWSVC/indx01.dbf


name=/app/oracle/oradata/NEWSVC/odmNEWSVC01.dbf


name=/app/oracle/oradata/NEWSVC/cwmlite01.dbf




piece


o1_mf_nnndf_TAG20051004T170341_1n4fv03f_.bkp comment=NONE






piece


o1_mf_n_570820318_1n4gbn5z_.bkp comment=NONE


8.4.1.2. Fast Recovery

현재 운영중인 database의 backups이 disk에 있고 이 database의 recovery가

필요한 상황에서 굳이 backup datafiles을 copy할 필요가 없다면 어떤 방법이 가장

빠를 것인가. 그것은 아마도 현재의 backup datafiles을 그대로 사용하도록 rename

을 한 후 database restart가 될 것이다. 그러나 이 작업도 여러 차례 command를

사용해야 하는 불편함이 있을 수 밖에 없다. Oracle10g는 새로운 command인

“switch”를 통해 가장 최근의 image copies를 원래의 위치로 copy하지 않고 backup

위치에서 그대로 사용하도록 해준다. 따라서 매우 신속하게 recovery를 시작할 수

있게 된다. 다음은 대표적인 명령의 유형이다.

RMAN> switch database to copy;

RMAN> switch datafile ‘name’ to copy;

RMAN> switch tablespace ‘name’ to copy;

CF. “alter database rename file” 작업을 대행해 준다고 생각하면 된다.

CF. 그러나 이런 작업을 하게 되면 database를 구성하고 있는 datafiles중 일부가

원래의 정책과 어긋난 곳에(backup 위치에) 위치하게 됨으로 적절한 때에 이를

원상태로 변경하는 것이 좋을 것이다. 물론, 이 작업을 통해 사용된 datafiles은 더 이상

backup files로 사용할 수 없을 것이다.

CF. 위와 관련하여 대표적인 예를 다음 장 chapter 9에서 “Migration to ASM”을

설명할 때 볼 수 있을 것이다.

8.4.2.TSPITR(TableSpace Point-In-Time Recovery)

8.4.2.1. TSPITR and RMAN

Oracle10g가 제공하는 새로운 기능들 중 RMAN에서 TSPITR을 수행하는 부분은 매우

중요하다. 이전과 달리 TSPITR을 하는 동안 사용되는 auxiliary instance의 생성부터



소멸까지 모든 과정을 자동화 해주기 때문이다. RMAN으로 TSPITR(TableSpace

Point-In-Time Recovery)할 때에 oracle10g부터는 recovery를 하면서 auxiliary

instance를 만들고 완료되면 자동으로 삭제한다는 것이다. 간단하게 예를 들어보면

다음과 같다.

먼저 테스트할 tablespace를 만들고 scott user로 table을 만들어 data를 insert하자.

SYSTEM> create tablespace ts_rcv

2 datafile '/app/oracle/oradata/NEWSVC/rcv01.dbf' size 50M;

Tablespace created.

SCOTT> conn scott/tiger

Connected.

SCOTT> create table rcv_test (live number, flag varchar2(1))

2 tablespace ts_rcv;

Table created.

SCOTT> insert into rcv_test values (1, 'a');

1 row created.

SCOTT> insert into rcv_test values (2, 'b');

1 row created.

SCOTT> commit;

Commit complete.

SCOTT> select * from rcv_test;

LIVE F

---------- -

1 a



2 b

SCOTT> select current_scn from v$database;

CURRENT_SCN

----------------------

9726741224

아래의 예는 RMAN의 default 환경에서 처리하기 위하여 disk type을 clear하고

작업을 진행한다. 그 후 새로 만들어진 tablespace를 backup한다.

RMAN> configure device type disk clear;


CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;

RMAN configuration parameters are successfully reset to default value

RMAN> backup tablespace ts_rcv;






input datafile fno=00003 name=/app/oracle/oradata/NEWSVC/rcv01.dbf



piece


o1_mf_nnndf_TAG20051004T173051_1n4hfvyn_.bkp comment=NONE




piece




o1_mf_n_570821455_1n4hg19t_.bkp comment=NONE


다음은 앞서 만든 table의 data를 없애보자. 즉, 어떤 사용자의 실수로 data가 모두

없어져 버린 상황이다.

SCOTT> truncate table rcv_test;

Table truncated.


no rows selected

RMAN의 TSPITR를 통해 복구를 수행해 보자. 다음의 명령은 아주 간단한 한 줄이지만

매우 많은 역할을 진행한다. 여기서 RMAN이 recovery를 진행하는 동안 auxiliary

작업을 원활하게 진행할 수 있도록 auxiliary destination을 지정하게 되는데 충분한

공간이 있는 위치를 지정한다.

RMAN> recover tablespace ts_rcv until scn 9726741224

2> auxiliary destination '/app/oracle/temp';

……………..

위 RMAN은 매우 많은 작업을 진행할 것이다. 작업이 진행되는 동안 다른 창에서

background process를 조회해 보자.

SCOTT> !ps -ef | grep ora_

oracle 18016 1 0 Sep29 ? 00:00:00 ora_pmon_NEWSVC

oracle 18018 1 0 Sep29 ? 00:00:00 ora_mman_NEWSVC

oracle 18020 1 0 Sep29 ? 00:00:06 ora_dbw0_NEWSVC

oracle 18022 1 0 Sep29 ? 00:00:09 ora_lgwr_NEWSVC

oracle 18024 1 0 Sep29 ? 00:00:01 ora_ckpt_NEWSVC

oracle 18026 1 0 Sep29 ? 00:00:19 ora_smon_NEWSVC

oracle 18028 1 0 Sep29 ? 00:00:00 ora_reco_NEWSVC

oracle 18030 1 0 Sep29 ? 00:00:12 ora_cjq0_NEWSVC

oracle 18034 1 0 Sep29 ? 00:00:02 ora_rvwr_NEWSVC

oracle 18038 1 0 Sep29 ? 00:00:04 ora_arc0_NEWSVC



oracle 18040 1 0 Sep29 ? 00:00:00 ora_arc1_NEWSVC

oracle 18042 1 0 Sep29 ? 00:00:00 ora_ctwr_NEWSVC

oracle 18044 1 0 Sep29 ? 00:00:00 ora_qmnc_NEWSVC

oracle 18046 1 0 Sep29 ? 00:00:06 ora_mmon_NEWSVC

oracle 18048 1 0 Sep29 ? 00:00:00 ora_mmnl_NEWSVC

oracle 21545 1 0 Sep29 ? 00:00:32 ora_q001_NEWSVC

oracle 19142 1 0 17:43 ? 00:00:00 ora_pmon_ejFv

oracle 19144 1 0 17:43 ? 00:00:00 ora_mman_ejFv

oracle 19146 1 0 17:43 ? 00:00:00 ora_dbw0_ejFv

oracle 19148 1 0 17:43 ? 00:00:00 ora_lgwr_ejFv

oracle 19150 1 0 17:43 ? 00:00:00 ora_ckpt_ejFv

oracle 19152 1 0 17:43 ? 00:00:00 ora_smon_ejFv

oracle 19154 1 0 17:43 ? 00:00:00 ora_reco_ejFv

oracle 19183 1 0 17:45 ? 00:00:00 ora_j001_NEWSVC

oracle 19246 18402 0 17:47 pts/0 00:00:00 /bin/bash -c ps -ef | grep

ora_

oracle 19248 19246 0 17:47 pts/0 00:00:00 grep ora_

위 결과를 보면 auxiliary instance를 위한 background processes를 확인할 수

있다. 물론, recovery가 끝나면 auxiliary instance와 함께 이 processes도 사라질

것이다.

어느 정도 시간이 흐르면 RMAN의 작업이 다음과 같이 진행될 것이다. 주요 부분들을

추출하여 그 내용을 살펴보자.

RMAN> recover tablespace ts_rcv until scn 9726439339

2> auxiliary destination '/app/oracle/temp';

Starting recover at 04-OCT-05


Creating automatic instance

initialization parameters used for automatic instance:

db_name=NEWSVC

compatible=10.1.0.4.0



db_block_size=8192

db_unique_name=tspitr_NEWSVC_iqux

large_pool_size=1M

#No auxiliary parameter file used

db_create_file_dest=/app/oracle/temp

control_files=/app/oracle/temp/cntrl_tspitr_NEWSVC_iqux.f

starting up automatic instance NEWSVC

Oracle instance started






Automatic instance created

contents of Memory Script:

{

# set the until clause

set until scn 9726741224;

# restore the controlfile

restore clone controlfile;

# mount the controlfile

sql clone 'alter database mount clone database';

# archive current online log for tspitr to a resent until time

sql 'alter system archive log current';

# avoid unnecessary autobackups for structural changes during TSPITR

sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';

}

executing Memory Script



executing command: SET until clause

위 내용은 RMAN 스스로 auxiliary instance를 구성하여 start하고 있음을 보여준다.

Starting restore at 04-OCT-05

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: sid=29 devtype=DISK

channel ORA_AUX_DISK_1: starting datafile backupset restore

channel ORA_AUX_DISK_1: restoring controlfile

channel ORA_AUX_DISK_1: restored backup piece 1

piece


o1_mf_n_570820945_1n4gy40x_.bkp tag=TAG20051004T172225

channel ORA_AUX_DISK_1: restore complete

output filename=/app/oracle/temp/cntrl_tspitr_NEWSVC_iqux.f

Finished restore at 04-OCT-05

sql statement: alter database mount clone database

sql statement: alter system archive log current

sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;


{

# generated tablespace point-in-time recovery script

# set the until clause

set until scn 9726741224;

plsql <<<-- tspitr_2

declare

sqlstatement varchar2(512);

offline_not_needed exception;

pragma exception_init(offline_not_needed, -01539);

begin



sqlstatement := 'alter tablespace '|| 'TS_RCV' ||' offline for recover';

krmicd.writeMsg(6162, sqlstatement);

krmicd.execSql(sqlstatement);

exception

when offline_not_needed then

null;

end; >>>;

# set an omf destination filename for restore

set newname for clone datafile 1 to new;

# set an omf destination filename for restore

set newname for clone datafile 2 to new;

# set a destination filename for restore

set newname for datafile 3 to

"/app/oracle/oradata/NEWSVC/rcv01.dbf";

# restore the tablespaces in the recovery set plus the auxilliary tablespaces

restore clone datafile 1, 2, 3;

switch clone datafile all;

#online the datafiles restored or flipped

sql clone "alter database datafile 1 online";





# make the controlfile point at the restored datafiles, then recover them

recover clone database tablespace "TS_RCV", "SYSTEM", "UNDO01" delete

archivelog;

alter clone database open resetlogs;

# PLUG HERE the creation of a temporary tablespace if export fails due to

lack

# of temporary space.

# For example in Unix these two lines would do that:

#sql clone "create tablespace aux_tspitr_tmp

# datafile ''/tmp/aux_tspitr_tmp.dbf'' size 500K";

}




executing command: SET until clause

sql statement: alter tablespace TS_RCV offline for recover

executing command: SET NEWNAME




using channel ORA_AUX_DISK_1

starting media recovery

archive log thread 1 sequence 164 is already on disk as file

/app/oracle/flash_recovery_area/NEWSVC/archivelog/2005_10_04/o1_mf_1_

164_1n4ho0bl_.arc

archive log

filename=/app/oracle/flash_recovery_area/NEWSVC/archivelog/2005_10_04/

o1_mf_1_164_1n4ho0bl_.arc thread=1 sequence=164

media recovery complete

Finished recover at 04-OCT-05

database opened


{

# export the tablespaces in the recovery set

host 'exp userid =\"/@$DESCRIPTION=\(ADDRESS=\(PROTOCOL=beq$\

(PROGRAM=/app/oracle/product/10.1.0/bin/oracle\)$ARGV0=oracleiqux\

)\(ARGS=^'\(DESCRIPTION=\(LOCAL=YES$$ADDRESS=\

(PROTOCOL=beq$\)\)^'\)$ENVS=^'ORACLE_SID=iqux^'$\)\

(CONNECT_DATA=$SID=iqux$\)



\) as sysdba\" point_in_time_recover=y tablespaces=

TS_RCV file=

tspitr_a.dmp';

# shutdown clone before import

shutdown clone immediate

# import the tablespaces in the recovery set

host 'imp userid =\"/@ as sysdba\" point_in_time_recover=y file=

tspitr_a.dmp';

# online/offline the tablespace imported

sql "alter tablespace TS_RCV online";

sql "alter tablespace TS_RCV offline";

# enable autobackups in case user does open resetlogs from RMAN after

TSPITR

sql 'begin dbms_backup_restore.AutoBackupFlag(TRUE); end;';

}


RMAN은 두 번째 단계로 복구를 하고자 하는 tablespace의 내역을 가지고 restore를

통해 auxiliary database를 구성하고 있다.

Export: Release 10.1.0.4.0 - Production on Tue Oct 4 17:37:24 2005


Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 -

Production


Export done in KO16KSC5601 character set and AL16UTF16 NCHAR

character set

Note: table data (rows) will not be exported

About to export Tablespace Point-in-time Recovery objects...

For tablespace TS_RCV ...

. exporting cluster definitions



. exporting table definitions

. . exporting table RCV_TEST

. exporting referential integrity constraints

. exporting triggers

. end point-in-time recovery

Export terminated successfully without warnings.

host command complete

database closed

database dismounted

Oracle instance shut down

위 내역은 세 번째 단계로서 복구된 data를 auxiliary database로부터 export한 후

auxiliary instance를 shutdown 시키는 과정이다.

mport: Release 10.1.0.4.0 - Production on Tue Oct 4 17:37:54 2005


Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 -

Production


Export file created by EXPORT:V10.01.00 via conventional path

About to import Tablespace Point-in-time Recovery objects...

import done in KO16KSC5601 character set and AL16UTF16 NCHAR

character set

. importing SCOTT's objects into SCOTT

. . importing table "RCV_TEST"

. importing SYS's objects into SYS

Import terminated successfully without warnings.

host command complete

sql statement: alter tablespace TS_RCV online



sql statement: alter tablespace TS_RCV offline

sql statement: begin dbms_backup_restore.AutoBackupFlag(TRUE); end;

Removing automatic instance

Automatic instance removed

auxiliary instance datafile /app/oracle/temp/cntrl_tspitr_NEWSVC_iqux.f

deleted

auxiliary instance datafile

/app/oracle/temp/TSPITR_NEWSVC_IQUX/datafile/o1_mf_system_1n4hog1r_.

dbf deleted


/app/oracle/temp/TSPITR_NEWSVC_IQUX/datafile/o1_mf_undo01_1n4hog49_.

dbf deleted


/app/oracle/temp/TSPITR_NEWSVC_IQUX/onlinelog/o1_mf_4_1n4hs955_.log

deleted


/app/oracle/temp/TSPITR_NEWSVC_IQUX/onlinelog/o1_mf_5_1n4hsf7l_.log

deleted


/app/oracle/temp/TSPITR_NEWSVC_IQUX/onlinelog/o1_mf_6_1n4hsk20_.log

deleted


마지막 단계로서 export한 data를 운영 database로 import한 후 TSPITR를 위해

임시로 사용한 files를 삭제하고 정리하는 작업을 진행하는 과정이다.

이제 원한다면(실제 환경에서는 반드시) 복구된 tablespace를 다시 backup하고 해당

tablespace를 online함으로써 작업을 마무리한다.

RMAN> backup tablespace ts_rcv;










piece


o1_mf_nnndf_TAG20051004T180602_1n4khvhx_.bkp comment=NONE




piece


o1_mf_n_570823567_1n4kj134_.bkp comment=NONE


RMAN> SQL "alter tablespace ts_rcv online";

sql statement: alter tablespace ts_rcv online

여러분이 원하는 tablespace의 복구가 제대로 이루어졌는지를 SQL 창에서 다음과

같이 확인해 보자.


LIVE F

---------- -

1 a

2 b

8.4.2.2. TSPITR and em

위에서 살펴본 이러한 RMAN의 TSPITR 과정은 역시 em database control에서도

지원한다. 원한다면 이런 작업을 em의 database control에서 “Maintenance

Perform Recovery(Backup/Recovery)”로 이동하여 다음과 같이 할 수도 있다. 먼저

아래 화면좌측의 list box에서 object type을 tablespaces로 선택해보자.


그림 8-10

Recovery 설정화면


그리고 나서 “Recover to current time or a previous point-in-time”을 선택하고

하단에서 OS 정보를 입력하면 된다.

이제 우측에(화면에는 보이지 않지만) “Next”를 선택하면 다음과 같은 화면을 볼 수

있다. 이 화면은 첫 단계로서 어느 시점에 어떤 형식으로 tablespace recovery를

진행할 것인가를 선택한다. 앞서 직접 테스트한 예를 적용한다면 “Recover to a prior

point-in-time” 및 SCN을 선택한 후 해당 SCN 값을 입력하면 될 것이다.



또 “Next”를 선택하면 다음 단계로서 auxiliary destination을 설정하고 tablespace

를 선택할 수 있다. 화면 중앙에서 auxiliary destination을 입력환 후 우측 하단에서

“Add” 버튼을 누르면 현재의 tablespaces가 나온다. Tablespaces를(복수 선택이

가능한 check box임을 명심하라) 선택한 후 “Select”버튼을 누른다. 즉, 2단계에서는

3가지 화면이 나오게 된다.


그림 8-11

TSPITR 설정화면



그림 8-12

TSPITR 설정화면

그림 8-13

TSPITR 설정화면


“Next”를 통해 다음 단계로 가면 아래의 화면에서처럼 restore를 결정한다. 즉, 특정

위치로 restore를 할 것인지 아니면 그대로 작업을 진행할 것인지를 확인하는 것이다.

이것으로 모든 설정은 끝난 것이다. Recovery를 시작하려면 “Next’버튼을 통해

마지막 단계로 가서 script를 확인하고 submit을 수행하면 된다.

8.4.2.3. TSPITR and RMAN의 한계RMAN을 이용한 TSPITR이 성공적으로 이루어지기 위해서는 그 속성들에 대하여

이해를 하고 있어야 한다. 다음은 복구를 할 수 없는 경우들이다.

1. drop된 tablespace는 복구할 수 없다.

2. rename된 tablespace의 경우 rename 시점의 이전 시점으로 되돌릴 수 없다.

3. 복구하고자 하는 tablespace내 tables과 연관된 objects(constraints등)이 없다면


그림 8-14

TSPITR 설정화면

그림 8-15

TSPITR 설정화면


해당 tables은 복구할 수 없다.

4. 다음과 같은 tables은 TSPITR로 사용할 수 없다. replication을 위한 master

tables, partial tables(partitioned tables처럼 일부만 가지고 있는 경우), 특수

column(varray, nested tables, external files)을 가진 tables, snapshot tables

and logs (이 말은 materialized view를 표현하는 것으로 보인다) tables는 TSPITR

의 대상이 될 수 없다.

5. undo나 rollback segments를 가지는 tablespace, sys 소유의 object를 가지고

있는 tablespace도 TSPITR을 통해 복구작업을 할 수 없다.

다음은 TSPITR이 가지는 특별한 속성들이다.

1. 복구하려는 tablespace에 지정하려는 TSPITR시점 이후에 datafile이 추가된 적이

있으면 TSPITR이 끝난 후 후에 추가된 datafiles은 empty 상태로 남게 된다.

2. TSPITR은 optimizer statistics을 복구하지는 않음으로 recovery된 tables은

새로이 통계수집 작업을 진행해야 한다.

3. TSPITR이 끝나면 해당 tablespaces에 대한 backup작업을 진행하도록 한다. 즉,

복구된 tablespaces 시점 이전의 해당 tablespaces backups은 현재의 control file

을 가지고 사용할 수가 없다. 최대한 빨리 해당 tablespace를 backup하도록 한다.

여러분이 recovery catalog를 사용하지 않고 control file을 대신(현재의 예에서처럼)

사용한다면 추가적으로 몇 가지 주의할 점이 더 있다.

1. TSPITR 시점에 undo segments가 auxiliary set의 일부이어야 한다. RMAN은

현재의 undo를 recovery가 수행되는 시점에 존재하는 것으로 생각하기 때문에

recovery 시점에 undo가 변경이 되어버렸다면 TSPITR은 실패할 것이다.

2. backup의 필요에 의해 control file이 reuse됨으로 너무 오래된 시점으로의

TSPITR은 실패할 가능성이 높다. 따라서 이 시간을 최대한 늘려주기 위해 initial

parameter “CONTROL_FILE_RECORD_KEEP_TIME”을 충분히 설정함으로써

성공률을 높일 수 있다.

3. TSPITR이 진행되면 현재의 control file은 이전의 tablespace 정보를 가지지 않기

때문에 현재 시점 이전의 backup을 사용할 수가 없다. 그러나 과거에 backup한

control file을 restore한다면 전체 database를 대상으로 incomplete recovery를

하는 것은 상관이 없다.

8.4.3.New Resetlogs Open

8.4.3.1. Oracle10g의 Resetlogs Open 변화Oracle10g까지 database recovery가 이루어지면 그리고 특히 복구된 database를

resetlogs option으로 open한 경우, 항상 database full backup을 다시 받으라는



원칙이 있었다. 그 이유는 resetlogs option으로 database가 open되면서 database

incarnation정보가 바뀌기 때문이었다. 즉, log sequence number도 1부터 다시

시작하기 때문에 full backup을 요구했던 것이다. 그러나 oracle10g는 이러한 원칙을

반드시 적용할 필요는 없다. 즉, 더 이상 필수 불변하는 원칙은 아니다.

이제 여러분은 incomplete recovery 혹은 backup control file을 가지고 recovery

를 수행한 후 복구된 database에 대한 full backup없이 시간상의 문제로 급하게

database를 resetlogs option으로 open해도 된다. 따라서 정말 운이 없어서 복구된

database가 또다시 recovery issue를 만나게 된다고 하더라도 resetlogs open

이전에 database backup본을 여전히 사용하여 복구작업을 다시 진행할 수 있게 된

것이다. 그러나 이 기능은 oracle10g가 아무런 사용자의 추가적인 작업을 요구하는

것이 아니기 때문에 현재(혹은 이전에) 만들어져 있는 script등 backup and recovery

와 관련한 여러분의 정책과 프로그램 등에 전혀 영향을 주지 않는다.

CF. “alter database open resetlogs”는 logs를 clear하기 전에 현재의 online redo

logs를 archive하는 작업을 진행한다.

8.4.3.2. Resetlogs 정보와 확인이제 과거에 신경을 쓰지 않던 database resetlogs open 이전 시점의 archived redo

log files도 주의하여야 한다. 즉, 이전에는 delete의 대상이었지만 이젠 사용할 후보자

log files이 된 것이다. 따라서 archive log format에 특별한 type이 필요하게 되었다.

왜냐하면 resetlogs open이후 새롭게 시작되는 log sequence number가 이전

backup본의 archive log name과 중복될 수 있기 때문이다. 이 format이 “%r”인데

이는 chapter 6에서 flashback database를 설명하면서 archive log mode로의

전환과 format에서 잠시 언급한 바 있다. “%r”은 resetlog id를 대표하여 중복을

방지할 수 있다.

SYSTEM> select value from v$parameter

2 where name = 'log_archive_format';

VALUE

--------------------------

arch_%t_%s_%r.arc

따라서 관련 views에도 추가된 columns이 생겼고 이 data들은 database resetlogs

open이후에도 여전히 유효하게 남아있게 된다. 추가된 column은

resetlogs_change#와 resetlogs_time 정보이다. 특히나 v$database는 이전



정보를 위한 prior_resetlogs_change#과 prior_resetlogs_time정보도 저장한다.

이미 우리는 chapter 6에서 flashback database를 수행하면서 resetlogs option

으로 database를 open한 바 있다. 가장 최근의 resetlogs open을 수행한 시점이

바로 그 때이다. 지금 chapter 6의 flashback database의 마지막 부분(Monitoring

Flashback Database)에서 SCN과 시간을 확인해 보라.

여러분은 그 당시 시간이 “2005년 8월 11일” “17:53:20”이며 그 때의 SCN이

“9722944814”라는 것을 알 수 있었을 것이다. 이 값들이 어떻게 표현되는지 확인해

보자.

SYSTEM> alter session set nls_date_format = 'YYYYMMDD HH24:MI:SS';

Session altered.

SYSTEM> set linesize 100

SYSTEM> select sequence#, first_change#, first_time,

2 resetlogs_change# rc#, resetlogs_time rct

3 from v$log_history

4 where first_time > sysdate -1 and rownum < 2;

SEQUENCE# FIRST_CHANGE# FIRST_TIME RC# RCT

------------------ -------------------------- ----------------------- ---------------

-----------------------

165 9726741419 20051004 17:34:40 9722944814 20050811

17:53:10

SYSTEM> select offline_change# ofc#, online_change# onc#, online_time

ont,

2 resetlogs_change# rc#, resetlogs_time rct

3 from v$offline_range;

OFC# ONC# ONT RC# RCT

--------------- --------------- ----------------------- --------------- -----------------------

9726741537 9726741658 20051004 17:38:05 9722944814 20050811

17:53:10



SYSTEM> select name, resetlogs_change# rc#, resetlogs_time rct,

2 prior_resetlogs_change# prc#, prior_resetlogs_time prct

3 from v$database;

NAME RC# RCT PRC# PRCT

------------- --------------- ----------------------- --------------- -----------------------

NEWSVC 9722944814 20050811 17:53:10 9722944218 20050811 17:33:53

8.4.4.Recovery and Drop

8.4.4.1. RMAN Recovery Datafile Without Backups

Oracle10g는 backup되지 않은 datafile의 recovery를 RMAN을 통해서도 지원할 수

있다. 이는 control file에서 해당 datafile의 정보를 추출하여 archive log를

적용함으로써 이루어진다. 따라서 이 방법을 사용하기 위해서는 적어도 문제가 된

datafiles의 생성시점부터 recovery 시점까지의 archive log가 다 있어야 하며 이

datafiles와 관련한 정보를 가지고 있는 control file의 copy도 있어야 한다.

CF. 물론, RMAN이 아닌 alter database command를 통한 SQL*Plus 상의

recovery도 가능하겠지만 아래의 내용들은 RMAN을 통한 복구의 예이다.

다음의 예는 작은 tablespace를 새로 만들어 backup이 없이 datafile을 삭제한 후

복구하는 과정이다. 복구는 아주 간단하게 현재 시점까지의 완전한(complete)

recovery를 진행해 보자.

먼저 테스트를 위한 tablespace, table 및 data를 생성하자.

SYSTEM> create tablespace nobackup datafile

2 '/app/oracle/oradata/NEWSVC/noback01.dbf' size 10M;

Tablespace created.

SYSTEM> create table x_nobackup (missing varchar2(1))

2 tablespace nobackup;

Table created.



SYSTEM> insert into x_nobackup values ('Y');

1 row created.

SYSTEM> commit;

Commit complete.

SYSTEM> select * from x_nobackup;

M

--

Y

이제 datafile을 OS상에서 강제로 삭제하고 archive log를 생성한 후 error를

유발하여 error를 확인해 보자. 혹시라도 buffer cache로부터 data를 읽어올

가능성을 없애기 위해 buffer cache도 flush한다.

SYSTEM> !rm /app/oracle/oradata/NEWSVC/noback01.dbf

SYSTEM> alter system flush buffer_cache;

System altered.

SYSTEM> alter system switch logfile;

System altered.


System altered.


System altered.




System altered.


select * from x_nobackup

*

ERROR at line 1:

ORA-00376: file 11 cannot be read at this time

ORA-01110: data file 11: '/app/oracle/oradata/NEWSVC/noback01.dbf'

SYSTEM> select file_id from dba_data_files

2 where file_name = '/app/oracle/oradata/NEWSVC/noback01.dbf';

FILE_ID

------------

11

SYSTEM> select file#, error from v$recover_file;

FILE# ERROR

---------- --------------------------

11 FILE NOT FOUND

다음으로 RMAN을 통해 backup이 없는 datafile이 복구되는지 확인해 보자.

RMAN> restore datafile 11;

Starting restore at 06-OCT-05


creating datafile fno=11 name=/app/oracle/oradata/NEWSVC/noback01.dbf

restore not done; all files readonly, offline, or already restored

Finished restore at 06-OCT-05

RMAN> recover datafile 11;








174_1n8wogdl_.arc



175_1n8wp446_.arc



176_1n8wpcd6_.arc



177_1n8wpjgq_.arc

archive log


o1_mf_1_174_1n8wogdl_.arc thread=1 sequence=174

archive log


o1_mf_1_175_1n8wp446_.arc thread=1 sequence=175



RMAN> SQL "alter database datafile 11 online";

sql statement: alter database datafile 11 online

이제 복구된 data를 확인하였으니 더 이상 필요가 없어진 테스트 tablespace를

datafile까지 모두 삭제하자.

SYSTEM> select * from v$recover_file;



no rows selected


M

--

Y

SYSTEM> drop tablespace nobackup including contents and datafiles;

Tablespace dropped.

8.4.4.2. RMAN and Drop Database

Oracle10g는 새로운 command “drop database”를 지원한다. 이 명령은 말 그대로

database를 삭제하는 명령이다. 따라서 삭제하는 database를 구성하는 datafiles도

모두 삭제된다. 이는 SQL*Plus, em database control 및 RMAN에서 모두 사용할 수

있다.

이 명령이 유효하기 위해서는 SYSDBA system privilege가 있어야 하고 database는

mount “exclusive” 상태이어야 하고 restricted mode이어야 한다. (반드시 close

상태 즉, open되면 안 된다) 이 drop command는 control file을 읽어서 control file

에 기록이 되어있는 모든 datafiles, control files을 삭제하게 되며 spfile을

사용한다면 spfile도 삭제한다. 그러나 archived logs 및 backup data들은 자동으로

삭제되지 않는 것을 원칙으로 한다. 하지만 여러분이 RMAN을 통해 drop database를

한다면 archived logs 및 backup data들도 함께 삭제할 수 있다.

CF. 만일, raw disk를 사용하고 있다면 이 명령으로 실제 raw disk files을 삭제할 수는

없다. 물론, rollback도 할 수 없으며 성공적으로 작업이 완료됨과 동시에 disconnect

가 발생한다.

다음의 예는 chapter 2에서 사용했던 database “OMFSVR”을 archive log mode

전환한 후 recovery destination을 설정하여 위 drop command를 통해 삭제하는

것을 구현한 것이다. RMAN의 기능을 사용하기 위하여 backup을 통해 backup data

도 만들고 나서 작업을 진행할 것이다.

먼저 ORACLE_SID 변수를 변경하고 drop database가 될 수 있도록 mount



exclusive 및 restricted mode로 database를 올린다. 그리고 나서 현재 존재하는

archive log 및 flashback database log를 확인하고 현재 database를 구성하고

있는 files도 확인한다.

[NEWSVC]LIRACLE:/app/oracle> export ORACLE_SID=OMFSVR

[OMFSVR]LIRACLE:/app/oracle> sqlplus / as sysdba

SQL*Plus: Release 10.1.0.4.0 - Production on Thu Oct 6 12:59:28 2005


Connected to an idle instance.

SYS> startup mount exclusive;







Database mounted.

SYS> alter system enable restricted session;

System altered.

SYS> !ls -l ./fl*/OMFSVR/fla*

total 8020

-rw-r----- 1 oracle dba 8200192 Oct 6 13:07 o1_mf_1n92r9gh_.flb

SYS> !ls -l ./fl*/OMFSVR/arch*/*/

total 17456

-rw-r----- 1 oracle dba 17849344 Oct 6 11:25

o1_mf_1_11_1n92s2gg_.arc

SYS> exit





With the Partitioning, OLAP and Data Mining option

[OMFSVR]LIRACLE:/app/oracle> ls -l ./oradata/OMFSVR/*

./oradata/OMFSVR/u01:

total 1078356

-rw-r----- 1 oracle dba 231407616 Oct 6 14:16 o1_mf_system_zrrkgfyd_.dbf

-rw-r----- 1 oracle dba 137699328 Oct 6 14:16 o1_mf_sys_undo_zrrkh7v2_.dbf

-rw-r----- 1 oracle dba 104865792 Oct 6 14:16 o1_mf_users_zrrkx6cd_.dbf

-rw-r----- 1 oracle dba 104865792 Jun 20 22:00 omf_temp01.dbf

-rw-r----- 1 oracle dba 524296192 Oct 6 14:16 sysaux01.dbf


total 206756

-rw-r----- 1 oracle dba 104858112 Oct 6 14:16 o1_mf_1_zrrkflcl_.log

-rw-r----- 1 oracle dba 104858112 Oct 6 14:11 o1_mf_2_zrrkft2b_.log

-rw-r----- 1 oracle dba 1777664 Oct 6 14:16 omfcont1.ctl


total 206756

-rw-r----- 1 oracle dba 104858112 Oct 6 14:16 o1_mf_1_zrrkfmj1_.log

-rw-r----- 1 oracle dba 104858112 Oct 6 14:11 o1_mf_2_zrrkg0ff_.log

-rw-r----- 1 oracle dba 1777664 Oct 6 14:16 omfcont2.ctl

이제 RMAN으로 접속하여 backup을 수행한다.

[OMFSVR]LIRACLE:/app/oracle> rman target /



connected to target database: OMFSVR (DBID=3948067122)

RMAN> backup database;









including current controlfile in backupset


name=/app/oracle/oradata/OMFSVR/u01/sysaux01.dbf


name=/app/oracle/oradata/OMFSVR/u01/o1_mf_system_zrrkgfyd_.dbf


name=/app/oracle/oradata/OMFSVR/u01/o1_mf_sys_undo_zrrkh7v2_.dbf


name=/app/oracle/oradata/OMFSVR/u01/o1_mf_users_zrrkx6cd_.dbf



piece

handle=/app/oracle/flash_recovery_area/OMFSVR/backupset/2005_10_06/

o1_mf_ncndf_TAG20051006T132205_1n99mjpw_.bkp comment=NONE



RMAN을 통해 drop database를 수행하여 위 결과에서 제대로 수행된 backupset과

앞서 확인한 archive log 및 flashback log를 기억한 후 이 files이 어떻게 되는지 직접

해보자.

RMAN> drop database including backups;

database name is "OMFSVR" and DBID is 3948067122

Do you really want to drop all backups and the database (enter YES or NO)?

y


List of Backup Pieces



BP Key BS Key Pc# Cp# Status Device Type Piece Name

---------- ---------- ----- ----- ------------------ ----------------

----------------------------------------------

2 2 1 1 AVAILABLE DISK

app/oracle/flash_recovery_area/OMFSVR/backupset/2005_10_06/o1_mf_ncnd

f_TAG2005100

6T132205_1n99mjpw_.bkp

deleted backup piece

backup piece

handle=/app/oracle/flash_recovery_area/OMFSVR/backupset/2005_10_06/

o1_mf_ncndf_TAG20051006T132205_1n99mjpw_.bkp recid

=2 stamp=570979328

Deleted 1 objects

released channel: ORA_DISK_1



List of Archived Log Copies

Key Thrd Seq S Low Time Name

------ ------ ------- -- -------------- ----

1 1 11 A 20-JUN-05

/app/oracle/flash_recovery_area/OMFSVR/archivelog/2005_10_06/o1_mf_1_1

1_1n92s2gg_.arc

deleted archive log

archive log

filename=/app/oracle/flash_recovery_area/OMFSVR/archivelog/2005_10_06/

o1_mf_1_11_1n92s2gg_.arc recid=1 stamp=570972351

Deleted 1 objects

database name is "OMFSVR" and DBID is 3948067122

database dropped

RMAN> exit




[OMFSVR]LIRACLE:/app/oracle>

Drop database command가 제대로 성공하였고 backup piece와 archive log도

삭제되었다는 내용이 보인다. 하지만 flashback database log와 datafiles, redo log

files, control files등의 정보는 나타나지 않는다. 이를 직접 확인해 보자.

[OMFSVR]LIRACLE:/app/oracle> ls -l ./fl*/OMFSVR/fla*

total 0

[OMFSVR]LIRACLE:/app/oracle> ls -l ./fl*/OMFSVR/arch*/*/

total 0

[OMFSVR]LIRACLE:/app/oracle> ls -l ./fl*/OMFSVR/backup*/*/

total 0

[OMFSVR]LIRACLE:/app/oracle> ls -l ./oradata/OMFSVR/*


total 0


total 0


total 0

[OMFSVR]LIRACLE:/app/oracle> export ORACLE_SID=NEWSVC

위 결과를 보면 모든 OMFSVR 관련 files이 삭제된 것을 알 수 있다. 다만, temporary

file만은 남아있다. 만일, 이 database가 spfile을 사용하고 있었다면 이 spfile도

삭제되었을 것이다.

CF. 만일, RMAN이 아닌 SQL*Plus에서 작업을 했다면 다음과 같이 database를

삭제한 후 자동으로 disconnect되는 것을 볼 수 있을 것이다.

SYS> startup mount exclusive









Database mounted.

SYS> alter system enable restricted session;

System altered.

SYS> drop database;

Database dropped.




> exit

[OMFSVR]LIRACLE:/app/oracle>



OCP point

==============================================

=================

1. 새로운 TSPITR와 auxiliary instance와의 관계

2. 새로운 resetlogs open과 새로운 archive format “r”의 의미

3. drop database command를 수행하기 위한 권한과 database 상태

참조

==============================================

=================

resetlogs : ob 12p, o8 82p, o8 104p, o9i 478p

TSPITR, auxiliary instance : o9i 467p



8.5. Others

8.5.1.Database Begin Backup

8.5.1.1. 개요RMAN을 사용하지 않고 database의 online backup을 수행한다고 가정하자. 그 동안

우리는 해당 database내의 tablespaces를 모두 begin, end backup command를

통해 backup 작업을 수행해 왔다. 즉, tablespace가 많으면 많을수록 여러 차례

반복해서 많은 command를 수행해야 했던 것이다.

Oracle10g는 이번에 하나의 명령으로 전체 database를 backup mode로 변환할 수

있게 되었다. 즉, 명령어 하나로 database의 모든 datafiles을 online backup mode

로 전환할 수 있게 되었기 때문에 더 이상 개별적으로 begin backup을 일일이 수행할

필요가 없다. 이는 “alter database begin backup”이라는 새로운 command를 통해

이루어진다. 물론, database는 mount 및 open상태 이어야 하고 archive log mode

로 운영 중 이어야 한다.

그러나 여러분이 RMAN을 주요 backup 수단으로 사용한다면 굳이 이 명령을 사용할

필요는 없다. RMAN은 항상 consistent backup을 보장하기 때문이다. 따라서 굳이

SQL*Plus 상에서 전체 database online backup을 수행하고자 할 때에만 이 명령을

효율적으로 사용하도록 하자.

8.5.1.2. Command Limit

이 명령을 사용하게 되면 normal database shutdown 및 normal tablespace

offline을 할 수 없으며 tablespace를 개별적으로 begin backup을 하거나 read-only

mode로 전환하는 작업도 유효하지 않다. 다음 몇 가지 예를 통해서 간단하게 error

messages를 확인하자.

SYSTEM> create tablespace delspace datafile

2 '/app/oracle/oradata/NEWSVC/delsp.dbf' size 5M;

Tablespace created.

SYSTEM> alter database begin backup;

Database altered.



SYSTEM> alter tablespace delspace read only;

alter tablespace delspace read only

*

ERROR at line 1:

ORA-01150: cannot prevent writes - file 11 has online backup set

ORA-01110: data file 11: '/app/oracle/oradata/NEWSVC/delsp.dbf'

SYSTEM> alter tablespace delspace offline;

alter tablespace delspace offline

*

ERROR at line 1:

ORA-01150: cannot prevent writes - file 11 has online backup set


SYSTEM> alter tablespace delspace begin backup;

alter tablespace delspace begin backup

*

ERROR at line 1:

ORA-01146: cannot start online backup - file 11 is already in backup


SYSTEM> alter database end backup;

Database altered.

CF. 위 내용과 유사한 사항으로 다음과 같은 경우에는 제대로 database begin

backup이 수행되지 않는다. 즉, database begin backup을 할 때에 file verification

에 실패가 발생하면 ORA-01128 error, tablespace의 begin backup이 사용되는

도중이면 ORA-01146 와 01110 error, file이 read-only로 변환되고 있는 도중이면

ORA-01232 error가 발생하고 또한 RMAN의 proxy backup이 진행되고 있는 도중에

database begin 및 end backup이 수행되어도 ORA-01253 error가 발생되어

작업을 실패하게 된다.



8.5.1.3. Online Backup Mode Example

기존의 alter tablespace begin backup command는 해당 tablespace에 속하는

datafiles이 없거나, offline 상태 혹은 read-only mode인 경우 error가 발생하지만

alter database begin backup command를 사용하며 위에 기술된 상태의 datafiles

을 skip하고 계속 진행된다. 다음의 예를 통해서 실제 테스트를 진행해 보자.

다음은 datafile이 offline 상태인 경우의 예이다. 이 경우엔 end backup을 통해 경고

메시지를 보여준다.

SYSTEM> alter database datafile '/app/oracle/oradata/NEWSVC/delsp.dbf'

offline;

Database altered.


Database altered.


alter database end backup

*

ERROR at line 1:

ORA-01260: warning: END BACKUP succeeded but some files found not to be

in

backup mode

SYSTEM> recover datafile '/app/oracle/oradata/NEWSVC/delsp.dbf';

Media recovery complete.


online;

Database altered.

다음은 read only tablespace가 있는 경우이다. 이 경우엔 아무런 변화가 없다.

SYSTEM> alter tablespace delspace read only;



Tablespace altered.


Database altered.

SYSTEM> alter database end backup ;

Database altered.

SYSTEM> alter tablespace delspace read write;

Tablespace altered.

다음은 특정 tablespace가 online backup mode인 상태의 예이다. 이 경우는

database begin backup이 시작되지 않는다.

SYSTEM> alter tablespace delspace begin backup;

Tablespace altered.


alter database begin backup

*

ERROR at line 1:

ORA-01146: cannot start online backup - file 11 is already in backup


SYSTEM> alter tablespace delspace end backup;

Tablespace altered.

다음은 datafile이 존재하지 않는 경우이다. 이 경우도 존재하지 않는 datafile은skip

하고 database begin and end backup이 이루어진다.

SYSTEM> !rm /app/oracle/oradata/NEWSVC/delsp.dbf




Database altered.


Database altered.

테스트를 위해 datafile을 삭제해 버렸으니 이를 간단하게 복구한 후 tablespace를

drop하자.


offline;

Database altered.

SYSTEM> alter database create datafile

'/app/oracle/oradata/NEWSVC/delsp.dbf';

Database altered.

SYSTEM> recover datafile '/app/oracle/oradata/NEWSVC/delsp.dbf';

Media recovery complete.


online;

Database altered.

SYSTEM> drop tablespace delspace including contents and datafiles;

Tablespace dropped.

8.5.2.RMAN 추가 정보Automatic Channel Failover :

Oracle10g는 RMAN을 이용하여 backup을 수행할 때 multiple channel을 사용하는

경우 그 기능을 향상 시켰다. 즉, 여러 channel 중 어떤 channel에서 문제가 발생하면



다른 channel을 통해 작업을 완료할 수 있도록 시도하게 된다.

CF. RMAN prompt에서 발생하는 error는 그 것이 무엇이든 “v$rman_output” view

에 기록이 된다. RMAN은 절대로 incomplete 즉, 완료되지 않은 backup 상태를 그냥

놓아두지 않기 때문에 backup이 완전하게 종료 될 때까지 기록하지 않는다.

RMAN Scripts Enhancement :

Oracle10g는 recovery catalog에 저장된 script를 text script로 또 반대로 text

script를 catalog에 저장된 script로 변경하는 것을 가능하게 해준다. 또한 global

scripts라는 개념을 소개하여 RMAN에서 접속하여 여러 database가 global script를

함께 공유할 수 있는 기능도 제공하고 있다.

Oracle10g release 2부터는 tape backup and recovery가 완전히 oracle에 통합이

되어 더 이상 3rd party product를 통한 tape backup등의 작업은 필요하지 않게 된다.

8.5.3.Backup 검증앞서 여러 차례의 backup을 수행하면서 backup 대상에 대한 점검을 한 적은 없다.

모든 datafiles이 정상이라는 가정하에 작업을 해온 것이다. 사실 제대로 backup

정책을 수립하고 앞서 학습한 많은 예들이 제대로 수행되기를 바란다면 주기적으로

검증작업을 할 필요가 있다. 사실 이 부분은 oracle9i에서 소개된 것임으로 new

feature는 아니지만 나름대로 필요한 이야기라 생각된다. 여러분의 기억을 되살려

간략하게 짚어보도록 하자.

다음의 view를 기억해 보자.

SYSTEM> desc V$database_block_corruption

Name Null? Type

----------------------------------------- -------- ---------------------

FILE# NUMBER

BLOCK# NUMBER

BLOCKS NUMBER

CORRUPTION_CHANGE# NUMBER

CORRUPTION_TYPE VARCHAR2(9)

SYSTEM> select * from V$database_block_corruption;

no rows selected



위 view는 corruption이 발생한 내역을 담고 있게 된다. 물론 현재는 아무 data도

없지만 backup 검증 작업을 한 후 문제가 있다면 이 view에 data가 생성될 것이다.

검증작업은 다음과 같이 RMAN prompt에서 “validate” option을 사용한다. 이

작업은 실제 backup은 수행하지 않고 검증작업만을 진행하는 것이다.





RMAN> backup validate database;










name=+DISKGRP_NO1/newsvc/datafile/ts_asm_no1.256.571595383


name=+DISKGRP_NO1/tbs_local/data/tsasmno2.dbf

input datafile fno=00019 name=/app/oracle/oradata/NEWSVC/sysaux01.dbf


name=/app/oracle/oradata/NEWSVC/exampleNEWSVC01.dbf

input datafile fno=00004 name=/app/oracle/oradata/NEWSVC/users.dbf

input datafile fno=00008 name=/app/oracle/oradata/NEWSVC/drsys01.dbf

input datafile fno=00002 name=/app/oracle/oradata/NEWSVC/undo01.dbf






input datafile fno=00009 name=/app/oracle/oradata/NEWSVC/indx01.dbf


name=/app/oracle/oradata/NEWSVC/odmNEWSVC01.dbf


name=/app/oracle/oradata/NEWSVC/cwmlite01.dbf




다시 corruption을 확인해 보자. 위에서 보듯 문제가 없었으니 아무 data도 없을

것이다.

SYSTEM> select * from v$database_block_corruption;

no rows selected

만일 validate의 결과로 corruption이 발견되었다면 다음과 같이하면 된다.

RMAN> blockrecover corruption list;

Starting blockrecover at 26-OCT-05






Finished blockrecover at 26-OCT-05

Oracle10g의 new feature는 아니지만 지금 RMAN을 사용하는 여러분이 계시다면

잊지 말고 앞으로 backup 정책을 수립할 때에 주기적으로 검증작업을 진행하도록

하자. 이는 생각보다 많은 사람들이 간과하는 backup 대상의 문제점들을 미리

확인하는 습관을 갖도록 하자는 의미로 살펴본 것이다.

가급적 주기적으로 다음의 명령을 수행하도록 하자. 이는 corruption을 감지하여



v$database_block_corruption에 list를 생성하고 그 list에 해당하는 corruption을

recovery해줌으로써 보다 안정적인 database운영에 도움을 줄 것이다.

RMAN> backup validate database;

RMAN> blockrecover corruption list;



OCP point

==============================================

=================

1. database begin backup의 limit

2. database begin backup에서 skip하는 datafile의 상태


O10g bak rec_15

Documents

Transcript of O10g bak rec_15