Database Reference
In-Depth Information
second day, and it no longer looks like the database did on the first day. This is where we
need to start to do a little thinking.
The keyterm is retention , or, how long do we need to be able to go back in time and
restore the database (or a copy of the database) for business purposes. Currently, our script
offers us pretty much no retention criteria. As soon as we run it, the ability to restore the
database to the previous day with RMAN is no longer possible.
So, you need to determine what the requirements for point-in-time recovery actually are.
For example, if your SLA requires that you be able to restore your database to any point
in time within the last 30 days, you need to consider how to implement this requirement.
In many environments, there is a need to take a copy of a database and make several other
copies of that database for various purposes, such as development. However, in some cases,
they might want to be able to restore the database to the point in time that it looked seven
days ago. This could be another consideration with respect to your backup planning.
Another possibility is that there may be some legal requirement to be able to restore
your database back to a point in time 30 days ago, or six months ago. At the end of the
day, you will have to figure out the number of days to which you need to be able to recover
your database.
Once you have determined your retention requirements, you would configure these reten-
tion requirements via RMAN, since it controls retention automatically within the FRA, and
you can manually control that retention if you have used non-FRA locations. With incremen-
tally updated backups, RMAN's automatic retention policies are not applied. Also, looking
for obsolete backups manually does not work since your backups are being wrapped into the
complete backup.
So, how do we provide for a recovery window, making it possible to restore the database
to some number of days in the past? We simply need to add the retention criteria into the
backup command itself. Here is an example where we have defined a retention criteria of
seven days:
Run {
RECOVER COPY OF DATABASE
WITH TAG 'incremental_update'
UNTIL TIME 'SYSDATE-7';
BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental_update' DATABASE
PLUS ARCHIVELOG DELETE INPUT;
}
The effect of adding the UNTIL TIME clause is that the incremental backups will not be
wrapped into the image copies of the database until seven days has passed. This results in
more incremental backups being stored on media to support the required recovery point.
TableĀ 7.3 provides a quick look at the progress of a backup and its backup files given the
previous command.
Search WWH ::




Custom Search