RMAN Backup policy

Hi,
I have few basic doubts in RMAN backup policy
1 . Is that possible to set Retention policy to recovery window in minutes??
2 . If i set Backup Retention Policy to recovery window to 3 days and i am performing RMAN differential incremental backup for 4 days. Will my backups become obsolete after 3 days even though they are needed for recovery or they won't become obsolete since they are needed for recovery ???
Regards,
007

1 What does the documentation of your unknown version of RMAN say? Does it states minutes are possible? If so, why are you asking rhetorical questions? (questions for which you already know the answer)
2 Rman only considers level 0 backups to determine whether a backup is obsolete, as you can't restore from an incremental backup.
Setting up a backup scheme for 4 days with a recovery window of 3 days wouldn't make any backup obsolete.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

RMAN backup policy needed to confirm!

Hi, All friends:
I am working on a production db, now set up Rman backup policy.
My purpose: keep only one backupset of datafile and control file, backup all archived logs--never delete--so database can be recovered to any time before.
so for Rman configuration;
configure retention policy to redundancy 1;
in DB control, setup a night whole db backup with backup archivelog and with with delete obsolete.
Am I right?
if anything wrong, please tell me, I want to confirm.
thanks a lot in advance.

thanks for your answer.
I want to use disk for backup storage because db size is small(only 7G) and we want a quick recovery.
To clarity, for my understanding,
if
configure retention policy to redundancy 1;
backups of archived redo logs won't be marked as obsolete, only backups of datafiles and control files will be marked as obsolete.
so if you run delete obsolete. it won't delete backups of archived logs.
(this is not like recovery windows, say you set retention policy to recovery window of 4 days, if you delete obsolete, RMAN will delete both backups of archived logs and data/control files)
AM I RiGHT?
thanks

Rman Retention policy to recovery window

Hi,
I have few basic doubts in RMAN backup policy
1 . Is that possible to set Retention policy to recovery window in minutes??
2 . If i set Backup Retention Policy to recovery window to 3 days and i am performing RMAN differential incremental backup for 4 days. Will my backups become obsolete after 3 days even though they are needed for recovery or they won't become obsolete since they are needed for recovery ???
Regards,
007

1) Syntax is .... TO RECOVERY WINDOW OF integer DAYS ... no other time statement.
2) Backups become obsolete when no longer needed to fulfil a retention policy. In a (theoretical) scenario, you perform a level 0 backup and then only incremental backups, the starting level 0 backup must be kept for ever (even if it WOULD be possible to define a recovery window in minutes).
Werner

RMAN retention policy really long

Hi,
we are planning to have an RMAN backup policy really long, around 7 years, with all the backup piece stored on a shared drive.
I would like to ask if there are problems or concern to have a recovery windows of around 2500 days, and if I have to change other Oracle parameter like control_file_record_keep_time.
The oracle version is 10.2.0.4, on a Solaris box, the customer don't want you a Catalog.
thanks for your time
Nunzio

I Nikolay,
thanks for you answer.
Nikolay Ivankin wrote:
Nunzio Cafarelli wrote:
What do you mean for huge!? and, in your experience, we should expect some hi decrease of performance, or are we speaking of something like 1%.I can't say - I don't know db size, user's activity, amount of redo information, backup strategy.
You are right, it's not easy to have an idea of what will happen.
Except that 2 points, there are no other functionality concerns!?Aren't enough? I would say, those 2 points are enough to refuse to keep rman info in CF, but catalog db.
Honestly no, if I will have a big (supposing 40 Mb) control file, and I'll have a performance decrease of around 1% or 2% is my opinion that that 2 points are not enough to refuse to proceed in this way.
I'll be scared if I know that ORACLE can't manage that amount of days as recovery window, and I'll have problem if I need to recover the database in a point in time that, for example, is more than 3 years ago.
Anyway, thanks.
Regards
Nunzio

Backup policy on Grid, using RMAN and Recovery Catalog.

Hello Gurus,
I'm trying to move ahead the new features of Oracle 10g in my company. So I've already created Grid Control and will deploy Agents/Targets during the next week. I also want to switch the backup process from the archaic exp/imp to RMAN with the Recovery Catalog.
My question is such: could anybody suggest the best book or text with solutions and descriptions of backup policy, using the Grid, RMAN and Catalog? What I want to do is to create eventually the powerful and centralized storage of every database in a company and do all daily routine from there. But as long as I'm only in the very beginning I want to gain some knowledge before the bad experience, like crashed recovery catalog and no backups for all databases :-)))
Definitely I'll keep existing imp/exp and hotbackup for a long time. I'm not going to substitute all our backup strategy with one catalog. I just want to understand what will be the best practice in the backup perspective.
And at all, I wonder if you please could give me very brief answer to this question: Let's say I have a huge monster with 5 disks by 500Gb RAD0+1. Is it a bad idea to store all of them in one physical machine before they will tape to backup or it could make sense? For me it sounds a bit scary, but probably if all made with the brain it's not a bad idea?
Please, send me to some valuable and good source (like Tom Kyte or Don Burleson) Unfortunately, I didn't find anything regard the backups itself. Only pretty much general thought.
Thanks a lot in advance.
M.

great!
thanks a lot!
this is definitely valuable info and I'll read right away. but as far as understand they suggest to use Data Guard, Standby and RAC which are the best ways to prevent your environment from crash. But in reality (I mean in my company) nobody is going to move to RAC at this point and I'm not sure, that they will have a chance to do in the next year. they just aren't up to it.
what I'm looking for is probably some tips and hints about backups in more or less big environment, but not as big as Oracle itself :-) unfortunately, i'm the only DBA in my surrounding. i mean, i have no friends or mentors DBAs that could seat with me in a pub and pass theirs knowledge from generation to generation :-)))
but anyway, I'll devote this week-end to this link.
thanks a lot!

Restoring RMAN backup from tape beyond retention policy ??

Hello Friends,
I just stuck in some basic finding. Need your help to resolve the questions.
How we can use RMAN backup to restore oracle database when the RMAN backup pushed to tape already and being a OLD backup ( before retention policy date).
Just to elaborate a more.. Say my retention policy is 3 days. I want to restore from a old backup like 30 days old.
So surely the requesting backup is behind retention date and has been pushed to tape.
Please suggest.
Thanks in advance.
Regards
Sinha.

dba.arnab wrote:
Hello Friends,
I just stuck in some basic finding. Need your help to resolve the questions.
How we can use RMAN backup to restore oracle database when the RMAN backup pushed to tape already and being a OLD backup ( before retention policy date).
Just to elaborate a more.. Say my retention policy is 3 days. I want to restore from a old backup like 30 days old.
So surely the requesting backup is behind retention date and has been pushed to tape.
Please suggest.
Thanks in advance.
Regards
Sinha.
Assuming the actual backup files still exist (the only thing actually deleted is the record of them in the catalog), you can make those files available and use the rman 'catalog' command to re-catalog them.

Volume Duplication Policy for RMAN Backups

Hi,
I wish to configure a volume duplication policy for RMAN backups. Both the source media family and duplicate media family are 'content managed' as per the documentation. However, the duplication policy 'trigger' is defined as if the media family is 'time managed', which does not seem to make sense in 'content-managed' media families used by RMAN.
Does anyone have any guidelines on how RMAN volume duplication can be set up so that my duplicates are valid?
Thanks

Yes. I understand. The reason I used time-managed volumes in the tutorial is that with time-managed volumes a duplicate may have different retention and rotation than the original. The procedure for time or content managed duplicates are the same.
A content managed tape may be duplicated to the same or different media family. If to a different media family, the retention would be same...since content managed but it could have a different rotation policy...if desired. For example, if you wanted original tapes left onsite but the duplicates to go offsite for "x" time, then create a new content managed media family and a desired rotation policy...associate that rotation policy to new media family and duplicate tapes to that media family with desired rotation policy. In that scenario, your original media family would have a duplication policy and possible a rotation policy. The new media family would just have a rotation policy.
Donna

RMAN backups does not match its retention policy

Hello,
I have couple of PROD instances on Windows environment with 11.2.0.3 DB version. RMAN retention policy is set to 14 days but I have noticed that backup is showing longer than that.
For example: LIST BACKUP OF DATABASE whows backups since 13th October. I also checked backup pieces at netapp share and they are present.
DELETE NOPROMPT OBSOLETE do not remove anything as expired backup.
I have clear retention policy and set to 14 days again but does not seem to work.
I would appreciate suggestion(s) regarding the strange issue.
Thanks a lot.
Best Regards

John-MK wrote:
Hello,
I have couple of PROD instances on Windows environment with 11.2.0.3 DB version. RMAN retention policy is set to 14 days but I have noticed that backup is showing longer than that.
For example: LIST BACKUP OF DATABASE whows backups since 13th October. I also checked backup pieces at netapp share and they are present.
DELETE NOPROMPT OBSOLETE do not remove anything as expired backup.
I have clear retention policy and set to 14 days again but does not seem to work.
I would appreciate suggestion(s) regarding the strange issue.
Thanks a lot.
Best Regards
We would need to know what kind of backups and when they were taken. Consider this scenario:
retention policy of 7 days.
Incremental level 0 backup taken on Sundays
Incremental level 1 backups taken Mon through Sat.
Let's say Oct 1 is a Sunday, so we take an inc-0 backup on Oct 1, and again on Oct 8.
Now let's say we are at Oct 10. Our 7 day retention policy dicatates that we be able to recover to any day back to Oct 3.
The only way we can recover to Oct 3 is to begin with that inc-0 backup from Oct 1.
All recovery begins with the last inc-0 backup prior to the point in time to be recovered. In a normal, regularly cycling schedule of backups, you will actually end up with backups 1 day short of being twice as old as your retention period.
Let's take a more extreme example. Same 7-day retention period, but after a single inc-0 backup, you don't take any more backups for 3 months. That one single backup is still needed to enforce your recovery window, and so is not obsolete, despite the fact it is 3 months old and your recovery window is only 7 days.
Also, you mention 'expired'. In terms of oracle backups, 'expired' is not the same as 'obsolete'.
"Obsolete" means 'no longer needed to enforce recovery policy'.
"Expired" is a bit more complex.
when a backup is taken, or an archivelog is written, a record of that is written to the repository. when you do an rman 'crosscheck', those repository records are compared to reality -- to see if the recorded backup file or archivelog file actually exists. Maybe someone used an OS command to delete them. Any file found to have 'gone walkabout' have their repository records marked as 'expired'. An rman 'delete expired' then removes those records from the repository.

Unable to restore and recover my Database from RMAN Backup

Dear All,
Iam practicing RMAN in Windows environment.
My configurations are
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION ON; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'F:\Backup\%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'E:\ORACLE\DATABASE\SNCFORCL.ORA';
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'F:\Backup\%U.bak';
Then i took the RMAN backup, now iam shutdown my DB and removed one logfile..
then i tried to startup the DB but it is saying
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: 'E:\ORADATA\ORCL\REDO03.LOG'
So i tried to restore the Database with my rman backup
RMAN> restore database;
But i am unable to restore my logfile in the Datafiles location where as all other datafiles are restored but redo logfiles are not restored.
So, i am unable to recover my DB
Please tell me whether i am doing any mistake, what is the solution for my problem.
Thanks in advance
Mahi

All you restored was your datafiles.
Now issue recover database and that will apply the archive logs.
This is in the oracle documentation.
"You must restore backups of these archived logs for recovery to proceed. You can restore either to the default or nondefault location. If you do not have backups, then you must performing incomplete recovery up to an SCN before the first missing redo log and open RESETLOGS."
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/osrecvry.htm
In this case after issuing restore database in RMAN, then issue this.
"Recover database"
It will then be an incomplete recovery. They should have been multiplexed. Did you restore your controlfile with this backup? You may have to issue an "Alter database open resetlogs;"

Restore spfile from rman backup ---- error.

Hi,
I am trying to execute recovery on new machine ...
I have done the following steps..
I have one database as ora10g2 as peroduction database on one machine as hosta
I have created a catalog on another machine cora10g2 (hostb)
I have taken a full backup from hosta as per following ...
the following command execute from hosta machine.
$ rman target sys/<passwd>@ora10g2 catalog rman/rman@cora10g2 ...
Backup completed ...
Now I am trying to restore this backup on hostb machine where i have already rman catlog database ..
I have done the following setting ...on host b
set oracle_sid=DUP
and execute following command ...
rman target / catalog rman/rman@cora10g2
RMAN> set dbid 2760732370
executing command: SET DBID
database name is "BAAN10G2" and DBID is 2760732370
RMAN>
RMAN>
RMAN> startup force nomount ;
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/oracle/dbs/baan10g2/dbs/initbaan10g2.ora'
starting Oracle instance without parameter file for retrival of spfile
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 1977112 bytes
Variable Size 67114216 bytes
Database Buffers 83886080 bytes
Redo Buffers 6406144 bytes
RMAN>
RMAN>
RMAN>
RMAN> show all ;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/rman/backup/control/cntrl_%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/baanora3/rman/ora10g2/bkup_db_%d_s%s_P%p_t%t' MAXPIECESIZE 1024;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
RMAN>
RMAN>
RMAN> list backup of spfile ;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
2420 Full 7.33M DISK 00:00:01 14-JUN-07
BP Key: 2426 Status: AVAILABLE Compressed: NO Tag: TAG20070614T182935
Piece Name: /rman/backup/control/cntrl_c-2760732370-20070614-00
SPFILE Included: Modification time: 14-JUN-07
BS Key Type LV Size Device Type Elapsed Time Completion Time
2509 Full 7.33M DISK 00:00:01 15-JUN-07
BP Key: 2515 Status: AVAILABLE Compressed: NO Tag: TAG20070615T130416
Piece Name: /rman/backup/control/cntrl_c-2760732370-20070615-00
SPFILE Included: Modification time: 15-JUN-07
BS Key Type LV Size Device Type Elapsed Time Completion Time
2694 Full 7.33M DISK 00:00:01 15-JUN-07
BP Key: 2739 Status: AVAILABLE Compressed: NO Tag: TAG20070615T131703
Piece Name: /rman/backup/control/cntrl_c-2760732370-20070615-01
SPFILE Included: Modification time: 15-JUN-07
BS Key Type LV Size Device Type Elapsed Time Completion Time
2760 Full 80.00K DISK 00:00:01 15-JUN-07
BP Key: 2763 Status: AVAILABLE Compressed: NO Tag: TAG20070615T163437
Piece Name: /rman/spfile/spfile.ora
SPFILE Included: Modification time: 15-JUN-07
BS Key Type LV Size Device Type Elapsed Time Completion Time
2769 Full 7.33M DISK 00:00:02 15-JUN-07
BP Key: 2771 Status: AVAILABLE Compressed: NO Tag: TAG20070615T163441
Piece Name: /rman/backup/control/cntrl_c-2760732370-20070615-02
SPFILE Included: Modification time: 15-JUN-07
RMAN>
RMAN>
RMAN> restore spfile from autobackup ;
Starting restore at 19-JUN-07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=35 devtype=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: sid=34 devtype=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: sid=33 devtype=DISK
channel ORA_DISK_1: looking for autobackup on day: 20070619
channel ORA_DISK_1: looking for autobackup on day: 20070618
channel ORA_DISK_1: looking for autobackup on day: 20070617
channel ORA_DISK_1: looking for autobackup on day: 20070616
channel ORA_DISK_1: looking for autobackup on day: 20070615
channel ORA_DISK_1: looking for autobackup on day: 20070614
channel ORA_DISK_1: looking for autobackup on day: 20070613
channel ORA_DISK_1: no autobackup in 7 days found
channel ORA_DISK_2: looking for autobackup on day: 20070619
channel ORA_DISK_2: looking for autobackup on day: 20070618
channel ORA_DISK_2: looking for autobackup on day: 20070617
channel ORA_DISK_2: looking for autobackup on day: 20070616
channel ORA_DISK_2: looking for autobackup on day: 20070615
channel ORA_DISK_2: looking for autobackup on day: 20070614
channel ORA_DISK_2: looking for autobackup on day: 20070613
channel ORA_DISK_2: no autobackup in 7 days found
channel ORA_DISK_3: looking for autobackup on day: 20070619
channel ORA_DISK_3: looking for autobackup on day: 20070618
channel ORA_DISK_3: looking for autobackup on day: 20070617
channel ORA_DISK_3: looking for autobackup on day: 20070616
channel ORA_DISK_3: looking for autobackup on day: 20070615
channel ORA_DISK_3: looking for autobackup on day: 20070614
channel ORA_DISK_3: looking for autobackup on day: 20070613
channel ORA_DISK_3: no autobackup in 7 days found
channel ORA_DISK_4: looking for autobackup on day: 20070619
channel ORA_DISK_4: looking for autobackup on day: 20070618
channel ORA_DISK_4: looking for autobackup on day: 20070617
channel ORA_DISK_4: looking for autobackup on day: 20070616
channel ORA_DISK_4: looking for autobackup on day: 20070615
channel ORA_DISK_4: looking for autobackup on day: 20070614
channel ORA_DISK_4: looking for autobackup on day: 20070613
channel ORA_DISK_4: no autobackup in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 06/19/2007 18:00:13
RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
RMAN>
I am not able to restore spfile from rman backup ;;;

Hi,
I would like to know few things
1. How are you setting the db_name ? you can set db_id at RMAN, how are you setting the db_name ?
2. Do you have any default init file at default location ? if yes, is the db_name parameter set correctly in that file ?
Since spfile is yet to be restored, you must set the db_name parameter correctly before you start spfile restore.This can be done with init file at default location which can even contain just one paremeter i.e db_name.

RMAN Retention Policy - redundancy vs recovery window

Hi All,
I'm wondering what the most commonly used rman retention policy is, to provide point-in-time recovery. We have 2 oracle servers, one using redundancy policy (3) and the other using recovery window (2 days). I would like to standardize them but am not confident in which direction I should go in.
I'm tempted to lean towards redundancy but wanted to pose the question to a wider, experienced audience for any things to think about/watch out for. Also, I assume the restore process would the same for either.
Thanks in advance.

Redundancy based retention policy means how many backups of each datafile must be retained and Recovery windows based retention policy is a period of time which starts with current time and goes backward in time upto the point of recoverability.
Oracle suggests and its Best practice is "Recovery Window" .( I don't know the reason though)
Two things you need to consider:
1) You might need more space in case of "recovery window" because it depends upon the schedule of the backup. In "redundancy" , your space consumption will be same.
2) You need to keep "recovery window" time less than the value of "control_file_Record_keep_time" so your backup records won't be overwritten in controlfile.
We use "Recovery Window"

Rman backup

Hi,
I want to take one time RMAN backup with indefinite retention policy. what is the best way. I want to recover the database whenever I want may be after year time.
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
or
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 500 days;
or
CONFIGURE RETENTION POLICY TO NONE;
Regards,
DBA

user573035 wrote:
Hi ,
Thanks for your reply. I decided to go as below.
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '${BACKUP_DIR}/${THEDBNAME}/cf_%d_%F';
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 6;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 20G;
This way I will have 2 backup and I will stop to take backup from RMAN. If it requires in future I can restore any of them.
Regards,
DBAI am confused about what you are trying to achieve here, and without knowing that, we really can't give any good advice.
What do you mean by "I will stop to take backup from RMAN" ?
It's sounding like you are planning on only taking one or two backups and never backing up again ..... ?
Are you running in archive log mode? Are you taking regular full and/or incremental backups? What are you trying to achieve by holding one backup for such a long period of time? How do you think this is better than the usual practice of taking a full backup once every week or so and incremental backups daily, with a retention period specified in terms of recovery window (time) instead of redundancy (number of backups)?
You may have some very good reasons, or simply haven't described your intent very well, but right now it sounds like you are about to head down the road to database recovery hell.

NEW 9I RMAN: BACKUP OPTIMIZATION AND RETENTION POLICIES

제품 : RMAN
작성날짜 : 2004-05-20
NEW 9I RMAN: BACKUP OPTIMIZATION AND RETENTION POLICIES
=======================================================
오라클 9i RMAN 에서는 백업을 보다 효율적으로 할 수 있는 기능을 보강 했다.
지금 소개할 "Retention Policies" 기능을 통해서 보다 효율적인 RMAN 백업
전략을 세울 수 있다.
1. 백업 화일 최적화 방법 (Backup File Optimization)
백업 화일 최적화란 백업에 소요되는 공간을 최소화 하는 전략이다. RMAN
백업시에 같은 정보 (dbid, checkpoint, and resetlogs data 등등) 를 가지고 있는
화일이 이미 존재하는 백업 셋 내부에 있는지 체크하게 된다. 만일 같은 화일이
이미 백업 되어 있다면 BACK UP 명령은 해당 화일에 대해서는 백업을 하지 않게
된다.
이때 같은 화일이라고 판단하는 기준은 다음과 같다.
* Datafile: 같은 DBID, checkpoint SCN, resetlogs SCN 과 time. 데이타 화일은
반드시정상적으로 offline 되었거나, read-only 이거나, 또는 정상적 으로 close
되어야 함.
* Archived redo log: 같은 thread, sequence number, 그리고 같은 Resetlogs
SCN 과 time.
* Backup Set: 같은 Backup Set recid 와 stamp.
RMAN 이 백업을 수행하다가 위와 같은 조건의 화일이 이미 존재함을 확인하면
이것은 건너뛰게 될 화일의 대상이다. 하지만 이때 바로 Skip 을 결정하지 않고
정해진 Retention Policies 를 조사 한후에 Skip 여부를 결정 하게 된다.
만일 백업 명령에 DELETE INPUT option 이 사용되면 RMAN 은 백업이 Skip
되어도 화일을 지우게 된다.
RMAN 은 모든 화일에 대한 백업이 Skip 되어도 에러메시지나 경고를 보내지
않는다.
그러나 만일 데이터 화일에 대한 백업이 recovery policy window 보다 오래
된 것 이면 RMAN 은 새로운 백업 화일을 만들기 위해서 화일을 백업 하게 된다.
Note:
자체적인 expirations policy 를 가지고 있는 media manager 를 사용할 경우에는
이런 백업 최적화 정책을 사용하는 것에 신중을 기해야 한다.
백업 최적화 를 사용하기 위해서는 CONFIGURE 명령을 사용한다. CONFIGURE
명령은 명령 수행 이후에 이루어지는 모든 백업에 대해 적용이 된다.
예:
CONFIGURE BACKUP OPTIMIZATION ON; # default 는 OFF
2. Backup Optimization에 Retention Policies 적용 하기
Retention Policy 로 백업 최적화를 조절 할 수 있다. 그러나 retention policy를
사용하지 않기 위해서는 'CONFIGURE RETENTION POLICY TO NONE' 을
이용해서 명시적으로 retention policy를 사용하지 않는다고 해야 한다. 디폴트로
REDUNDANCY = 1 이 적용 된다.
a. Recovery Window 를 이용한 Backup Optimization
만일 백업 최적화가 enable 되어 있고 Recovery Window 가 retention policy
적용을 위해서 셋업 되어 있으면 RMAN 은 항상 가장 최근의 백업이 Recovery
Window 보다 오래된 데이터 화일을 백업한다.
예를 들면 다음과 같은 조건에서
o Today is February 21.
o The recovery window is 7 days.
o The most recent backup of tablespace tbs2 to tape is January 3.
o Tablespace tbs2 is read-only.
2월 21일에 tbs2 테이블 스페이스를 테이프로 백업을 하라는 명령을 내리면,
RMAN 은 이 화일이 1월3일 이후에 변경 사항이 없는데도 불구 하고 백업을 하게
된다. 이로써 RMAN 은 최근 7일 동안에 최소한 한번의 백업이 있어야 된다는
조건을 지키게 된다.
이러한 작동 방식은 media manager 가 오래된 테잎을 제거 해도 되도록 한다.
그렇지 않다면, media manager 는 1월 3일의 백업을 무한정 가지고 있게 된다.
2월 21일에 tbs2 테이블 스페이스의 보다 최근의 백업을 만듦으로 써, RMAN 은
media manager 가 1월 3일에 백업 했던 테입을 지워도 되도록 한다.
b. Redundancy 를 이용한 Backup Optimization
Retention policy 로 Redundancy 를 채택 한 경우에 RMAN 은 Redundancy
에 1을 더한 갯수를 초과하는 오프라인 또는 읽기 전용 화일의 백업을 건너뛴다.
이때 'CONFIGURE RETENTION POLICY TO REDUNDANCY n' 명령어로
Redundancy의 갯수를 정한다.
아래와 같은 백업 최적화 명령을 내린 경우를 예로 든다:
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
아카이브 테이블스페이스를 한번도 백업을 받은적이 없고 다음의 작업을 1주일
동안 한다고 하자.
Day Action Result Redundant Backup
Monday Take tablespace archive offline clean.
Tuesday Run BACKUP DATABASE. The archive tablespace is backed up.
Wednesday Run BACKUP DATABASE. The archive tablespace is backed up.
Thursday Run BACKUP DATABASE. The archive tablespace is backed up. Tuesday backup.
Friday Run BACKUP DATABASE. n/a Tuesday backup.
Saturday Run BACKUP DATABASE. n/a Tuesday backup.
Sunday Run DELETE OBSOLETE. The Tuesday backup is deleted.
Monday Run BACKUP DATABASE. The archive tablespace is backed up. Wednesday backup.
화요일, 수요일, 그리고 목요일의 백업은 아카이브 테이블 스페이스를 복사 해서
3개의 백업이 반드시 존재 해야 한다는 조건을 충촉 시킨다. (1+Redundancy)
금요일과 토요일에는 백업 최적화 조건에 의해서 아카이브 테이블 스페이스를
복사하지 않게 된다.
RMAN 은 일요일에는 유효기간이 지난 백업 화일을 지우게 된다. 따라서 화요일에
만든 백업은 삭제 된다. 월요일의 전체 백업은 3개의 백업이 존재 해야 한다는 조건
때문에 아카이브 테이블 스페이스를 또 다시 백업하게 된다. 이런 방식으로 백업
사이클이 진행 된다.
3. RETENTION POLICY NONE vs. DEFAULT
주의 사항:
'CONFIGURE RETENTION POLICY TO NONE' 과 'CONFIGURE RETENTION
POLICY TO DEFAULT' 는 그 의미가 같지 않다. 전자는 RETENTION POLICY
자체가 존재 하지 않는다는 의미 이며 백업은 expire 되지 않으며 'DELETE
OBSOLETE' 명령은 사용 할 수 없게 된다. 후자는 디폴트 RETENTION POLICY
(REDUNDANCY 1) 를 사용하게 된다는 의미 이다.
'DELETE OBSOLETE' 명령은 RETENTION POLICY 기준으로 expire 된 백업을
제거 하라는 명령이다.
보다 자세한 내용은 Oracle9i Recovery Manager User's Guide and
Reference의 Backup Optimization 부분을 참고 하시기 바랍니다.
--------------THE END----------------------------------------------

Hi,
Backup optimisation = +- do not copy empty space.
So, when you issue your BACKUP statement, it backs up the datafile. dot. nothing more.
In order to achieve what you're testing, look into TFM for BACKUP INCREMENTAL LEVEL x .
Regards,
Yoann.

Query on RMAN Retention Policy

Hi, I have my Retention policy set to Redundancy 2
I have taken 3 backups so far ( 2 Backup Sets, 1 Image Copy )
When I check report obsolete I get the following
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 2
Report of obsolete backups and copies
Type                 Key    Completion Time    Filename/Handle
Backup Set           1      05-SEP-13
Backup Piece       1      05-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_05/o1_mf_annnn_TAG20130905T100934_92jllgn1_.bkp
Backup Set           2      05-SEP-13
Backup Piece       2      05-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_05/o1_mf_nnndf_TAG20130905T100949_92jllycp_.bkp
Backup Set           3      05-SEP-13
Backup Piece       3      05-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_05/o1_mf_ncsnf_TAG20130905T100949_92jln4d5_.bkp
Backup Set           4      05-SEP-13
Backup Piece       4      05-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_05/o1_mf_annnn_TAG20130905T101030_92jln6cx_.bkp
Backup Set           5      27-SEP-13
Backup Piece       5      27-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_27/o1_mf_annnn_TAG20130927T120734_94bsqrj6_.bkp
Backup Set           7      27-SEP-13
Backup Piece       7      27-SEP-13          /home/app/oracle/fast_recovery_area/PRIMARYP/backupset/2013_09_27/o1_mf_ncsnf_TAG20130927T120751_94bssf0j_.bkp
Archive Log          305    10-OCT-13          /home/app/oracle/fast_recovery_area/PRIMARYP/archivelog/2013_10_10/o1_mf_1_138_95dv9okt_.arc
Archive Log          306    10-OCT-13          /home/app/oracle/fast_recovery_area/PRIMARYP/archivelog/2013_10_10/o1_mf_1_139_95dv9px0_.arc
Archive Log          307    10-OCT-13          /home/app/oracle/fast_recovery_area/PRIMARYP/archivelog/2013_10_10/o1_mf_1_140_95dv9r8f_.arc
Archive Log          308    10-OCT-13          /home/app/oracle/fast_recovery_area/PRIMARYP/archivelog/2013_10_10/o1_mf_1_141_95dv9sk9_.arc
Backup Set pieces 1,2,3,4 basically equate to my oldest backup - hence under redundancy of 2, I can see why that is obsolete
5 and 7 were simply Control File/SPFILE backups from Auto Backup and the 2 newer backups of these have been taken since ( i.e. backupset pieces 9 and 10 )
Q. What happens if I wanted to restore the database to the 27/09 ? What SPFILE and Control would it use ( presuming the OBSOLETE files had been removed out of the FRA ) ?
Would I have to restore the removed backup set into the FRA, Cross Check and then restore the database via RMAN to the 27/09 ?
Q. Why are some of today's ( 10/10/13 ) archive logs marked as OBSOLETE ?
Q. If I wanted to have the ability to restore the database to 2 days ago, is perhaps a Rentention Policy of a 2 day Recovery Window perhaps better than my current Redundancy=2 policy ( combined with taking a daily backup ) ?
any advice appreciated,
Jim

Q. What happens if I wanted to restore the database to the 27/09 ? What SPFILE and Control would it use ( presuming the OBSOLETE files had been removed out of the FRA ) ?
Would I have to restore the removed backup set into the FRA, Cross Check and then restore the database via RMAN to the 27/09 ?
- Yes you can get the database to the date which ever you want , using recover database until time.
Q. Why are some of today's ( 10/10/13 ) archive logs marked as OBSOLETE ?
- can you please provide the output of below command
RMAN> show all;
Q. If I wanted to have the ability to restore the database to 2 days ago, is perhaps a Rentention Policy of a 2 day Recovery Window perhaps better than my current Redundancy=2 policy ( combined with taking a daily backup ) ?
- You can restore the database back to two days or 5 days based on your requirement. You nee to recover the database using until time option.
Thanks,
http://gssdba.wordpress.com

RMAN RETENTION POLICY configuration.

Currently I am doing RMAN backup once a day and save the copy to tapes through TSM. If I want to keep 15 copies of the db (NOT 15 same copies. It will be one copy from every day backup, so each copy will be different). How should I configure the RETENTION POLICY? Shall I do
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;
Or shall I do
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
Also do I need to configure anything on the TSM side?
Thanks.

To keep the last 15 full backups use redundancy 15.
You don't need to do anything on TSM if:
- you use RMAN to backup directly to tape device and
- you use RMAN DELETE OBSOLETE statements to purge old backups.
See http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmconfb.htm#BRADV8400

RMAN Backup policy

Similar Messages

Maybe you are looking for