Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 393

RMAN> run {
2> allocate channel ch1 device type disk;
3> allocate channel ch2 device type disk;
4> backup section size 250m datafile 1;
5> }
[...]
Starting backup at 21.09.2013 23:47
channel ch1: starting full datafile backup set
[...]
backing up blocks 1 through 25600 [...]
channel ch2: starting full datafile backup set
[...]
channel ch1: starting full datafile backup set
[...]
backing up blocks 25601 through 51200
[...]
channel ch2: starting full datafile backup set
[...]
backing up blocks 51201 through 76800 [...]
RMAN>
Oracle 12c introduced the ability to perform multi-section incremental backups which is very useful.
If you do not change the default option then backups will be taken as backup sets. Each backup set can comprise
multiple backup pieces. Optionally you can chose to use binary compression of the backup sets. Depending on the
content stored in the database using (binary) compressed backup sets can greatly decrease the backup size.
So-called image copies are an alternative to backup sets. An image copy is an exact copy of the source file. For
obvious reasons an image copy is of the same size as a data file-an image copy of a completely empty 10G data file will
require an additional 10G of disk space. Image copies can be useful in a scenario where you can afford a second copy
of the database created as image copies in the FRA. The image copies can be rolled forward by applying incremental
backups taken on the “live” data files. If the worst should happen, you can switch the database to the copy, apply the
last remaining archived logs and open the database from within the FRA.
Backup optimization
Using backup optimization is a way to conserve space on the backup media by skipping files that have been backed
up previously while adhering to the retention policy. Using the configure backup optimization on command in
RMAN enables backup optimization for subsequent backups. For files to be skipped they must be identical and also
be part of a valid backup as part of the retention policy. In practice you will find that read-only and offline tablespaces
are most likely to be backed up only once in a recovery window. Assuming that the read-only tablespace TBS1 is
already backed up on Monday in a recovery window of 7 days it will not be backed up on Tuesday and the following
days unless it changes. It will however be backed up the following Monday again, allowing the media manager to
expire the tape with the backup taken a week earlier.
For a retention policy requesting redundant backups to be available a read-only, offline tablespace or archived
log will be excluded from the first additional redundant backup. If for example your retention policy is set to
redundancy 5 and you execute the 6 th backup of the database, identical files which have not changed will be skipped.
Archived redo logs can also be skipped from being backed up if they exist in a backup set. The retention policy
does not play a role when backing up archived logs with backup optimization. During testing it turned out that with
backup optimization enabled, Oracle will skip archive logs already backed up once in a backupset which is available
if you back it up using the backup archivelog like or backup archivelog all commands. Assume for this example