This blog has moved here.

Friday, March 19, 2010

When having a rman retention policy based on REDUNDANCY is a bad idea...

Suppose you have a RMAN retention policy of "REDUNDANCY 2". This means that as long as you have at least two backups of the same datafile, controlfile/spfile or archivelog the other older backups become obsolete and RMAN is allowed to safely remove them.

Now, let's also suppose that every night you backup your database using the following script:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
rman {
backup database plus archivelog;
delete noprompt obsolete redundancy 2;
}

The backup task is quite simple: first of all it ensures that we have the controlfile autobackup feature on, then it backups the database and archives and, at the end, it deletes all obsolete backups using the REDUNDANCY 2 retention policy.
Using the above approach you might think that you can restore your database as it was two days ago, right? For example, if you have a backup taken on Monday and another one taken on Tuesday you may restore your database as it was within the (Monday_last_backup - Today) time interval. Well, that's wrong!

Consider the following scenario:
1. On Monday night you backup the database using the above script;
2. On Tuesday, during the day, you drop a tablespace. Because this is a structural database change a controlfile autobackup will be triggered. Ieeei, you have a new controlfile backup.
3. On Tuesday night you backup again the database... nothing unusual, right?

Well, the tricky part is regarding the DELETE OBSOLETE command. When the backup script will run this command, RMAN finds out three controlfile backups: one is originating from the Monday backup, one is from the structural change and the third is from our just finished Tuesday backup database command. Now according to the retention policy of "REDUNDANCY 2", RMAN will assume that it is safe to delete the backup of the controlfile taken on Monday night backup because it's out of our retention policy and because this backup is the oldest one. Uuups... this means that we gonna have a big problem restoring the database as it was before our structural change because we don't have a controlfile backup from that time.

So, if you intend to incomplete recover your database to a previous time in the past it's really a good idea to switch to a retention policy based on a "RECOVERY WINDOW" instead. In our case a RECOVERY WINDOW OF 2 DAYS would be more appropriate.

5 comments:

Anonymous said...

What happens if you have RECOVERY WINDOW OF 2 DAYS set up but the last 2 backups fail? Will the older backups be deleted because they passed the 2 days window?

Alexandru Tica said...

No, RMAN must guarantee that the current backups you have ensure a recovery of your database at least as it was 2 days ago. If you have a valid backup taken 3 days ago and then, on the next 2 days you don't take any backups, RMAN will keep the valid backup because it is the only way you can recover within the configured 2 days recovery window. RMAN will restore your valid backup (from 3 days ago) and will apply all the necessary archives.

Anonymous said...

hi, new to the site, thanks.

Anonymous said...

Hi,
from your article u only have explained reduncay concept with example wht about recovery window your aticle in very much incomplete in nevre helped me ...........

James Steevens said...

Hi,

Pretty good article.