RMAN -
Creating Archival Backups
To take backup out of retention policy and make it exempt, use
the keep option with the backup command. In Oracle 10g, we were
using the logs or nologs options to specify that RMAN will, or
will not, keep archived redo log files that are necessary for the
recovery. However, starting with Oracle 11g, RMAN does not let
us keep all the archived redo log files generated after backup is
taken. The only archived redo log files backed up are those files
which are needed to take the backup to its routine status. You
can keep the backup until a specific time or forever.
In the following example, we back up the database and take it
out of retention policy for 10 days:
RMAN> backup database
2> keep until time 'sysdate+10'
3> format 'c:\tmp\test_db%u'
4> tag testdb_backup;
current log archived
backup will be obsolete on date 05-JUN-10
archived logs required to recover from this backup will be
backed up
To change the parameter of the keep option, use the change
command. In the following example, we change the obsolete
time of the backup named testdb_backup and make it 20 days:
RMAN> change backup
2> tag testdb_backup
3> keep until time 'sysdate+20';
using channel ORA_DISK_1
keep attributes for the backup are changed
backup will be obsolete on date 15-JUN-10
backup set key=21 recid=21 stamp=720028138
RMAN>
Creating Compressed Backups
Before Oracle 10gR2, RMAN was not backing up the data blocks
that had never been used. But if it found a data block that was
used once, it was backing it up even if it was empty. That is
called NULL compression.
Starting from 10gR2, RMAN skips the data blocks that are empty and
do not contain any data. This is called unused block
compression. The last type of compression is called binary
compressionwhere RMAN applies
a binary compression algorithm as it writes data blocks to the
backup pieces.
Although RMAN uses more CPU space during compression,
ultimately compressed backups show up with a smaller size. To use
this feature, add the phrase as compressed backupset after the
backup command. To follow the compression process and its
difference from backup which is taken without compression, see the
following example. Here, we create a normal, non-compressed
backup of the SYSAUX datafile. Then we create a compressed backup
and compare their size:
RMAN>backup datafile 3 format c:\uncompressed_sysaux.bkp';
rman>backup as compressed
backupset datafile 3 format
c:\compressed_sysaux.bkp';
c:\>dir *.bkp
09.08.2009 02:20 11 419 648 copmressed_sysaux.bkp
09.08.2009 02:20 151 863 296 uncompressed_sysaux.bkp
As shown, the compressed backup is smaller in size than the
uncompressed backup. To identify which files were compressed,
query v$backup_filesas
follows:
It is possible to compress archived redo log and incremental
backupsas follows:
RMAN> backup as compressed
backupset archivelog all;
RMAN> backup as compressed backupset incremental level 0
database;
RMAN> backup as compressed backupset incremental level 1
database;
RMAN> backup as compressed backupset incremental level 1
cumulative database;
For more information on creating incremental backups, see the
Making Incremental Backups? section later in this chapter.
To set all backups to be compressed as the default mode, make
changes in the RMAN configuration parameter as follows:
RMAN> configure device type disk
backup type to compressed backupset;
using target database control file instead of recovery catalog
new RMAN configuration parameters:
configure device type disk backup type to compressed backupset
parallelism 1;
new RMAN configuration parameters are successfully stored
RMAN> show all;
configure device type disk backup type to compressed backupset
parallelism 1;
By changing this parameter, all backups will be compressed. To
return to the default non-compressed configuration, clear the
configuration to make future backups be non-compressed:
RMAN> configure device type disk
clear;
old RMAN configuration parameters:
configure device type disk backup type to compressed backupset
parallelism 1;
RMAN configuration parameters are successfully reset to default
value
RMAN> show all;
configure device type disk parallelism 1 backup type to
backupset; # default
There is a new compression algorithm that comes with Oracle 11g
ZLIB. This compression
algorithm does not use as much CPU as BZIP2, but it produces a
backup larger in size than what BZIP2 does. In the following
example, we create three different backups: 1) non-compressed, 2)
default BZIP2 compressed and 3) ZLIB compressed. The difference
can be seen by checking their sizes.
Backup of the database without using any compression algorithm
is created:
RMAN> backup database;
piece handle=o1_mf_nnndf_tag20100525t114933_5zpwqy2x_.bkp
tag=TAG20100525T114933 comment=none
Now compress the backup using the default BZIP2 compression
algorithm:
RMAN> show compression algorithm;
RMAN configuration parameters for database with db_unique_name
ORCL are:
configure compression algorithm 'BZIP2'; # default
RMAN> backup as compressed backupset database;
piece handle=o1_mf_nnndf_tag20100525t115237_5zpwxotc_.bkp
tag=TAG20100525T115237 comment=none
Next change the configuration of the compression algorithm to
create a ZLIB backup:
RMAN> configure
compression algorithm "ZLIB";
new RMAN configuration parameters:
configure compression algorithm 'ZLIB';
new RMAN configuration parameters are successfully stored
RMAN>
backup as compressed backupset database;
piece handle=o1_mf_nnndf_tag20100525t115451_5zpx1w6t_.bkp
tag=tag20100525t115451 comment=none
RMAN>
Now check the sizes of all the backup sets and see the
difference:
1,027,399,680 NO
O1_mf_nnndf_tag20100525t114933_5zpwqy2x_.bkp
186,687,488 bzip2
o1_mf_nnndf_tag20100525t115237_5zpwxotc_.bkp
202,997,760
O1_mf_nnndf_tag20100525t115451_5zpx1w6t_.bkp
