Performing Oracle Advanced Recovery - OCP: Oracle Database 12c Administrator Certified Professional - page 312

The best practice calls for the use of one full backup, and then incrementally backing up
that backup image over time. This has the effect of only requiring that one full backup of
the database ever be taken. Subsequent backups then just back up the incremental changes.
This kind of backup is called an incrementally updated backup and it can save you a great
deal of time when backing up your database, space to store these backups, and save you
lots of time when restoring these backups.
All of this is done through the auspices of a two RMAN commands as seen here:
Run {
RECOVER COPY OF DATABASE
WITH TAG 'incremental_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incremental_update' DATABASE;
}
These commands are run as a set, the first being a predicate to the second. These
commands might look a bit different than your regular RMAN BACKUP commands, and
they are. Let's look at what's happening in a bit more detail.
The First Execution of the Command
When these set of commands are run the first time, the RECOVER COPY OF DATABASE will
cause RMAN to lookup and find any incremental backup that might need to be applied to
the base backup of the database that was taken.
At the beginning of the first execution there will be no backups for the command to
find at all, since none have been taken (using this tag, presumably) to this point. This is
expected and while a message will appear, no error really occurs.
Note the use of the TAG parameter and that the tags are the same in both commands.
This is important since it provides a way for RMAN to find the correct backups to update
in later executions.
The BACKUP command on this first execution will create a complete image copy of the
database. Note that this is an image copy, and not a backup set, so the resulting size of
the backup files will be the same as the size of the database and likely much larger than
normal RMAN database backups. However, this format, and the strategy we are discuss-
ing now, is the absolute fastest way to restore a large database.
So, let's say that this backup takes place on June 1. If we looked at the FRA on June 1,
after the backup, what we would find is a copy of all of the database datafiles sitting in the
FRA. We would also find, if we looked around, that we forgot to back up the archived redo
logs, which would be a problem since they will be needed to be able to actually recover this
database completely. We will fix this problem by modifying our script as follows:
Run {
RECOVER COPY OF DATABASE