RMAN
How does RMAN compression works ?By default RMAN has three types of compression :
1. Null Compression
2. Unused Block Compression
3. Binary Compression
Till Oracle Version 10.1 only 'Null' compression is done by default but from Oracle Version 10.2 'Null' and 'Unused
Block' Compression is done. These compressions are done automatically, no special command is required for these
compressions.
'Null' and 'Unused Block' Compression are filtering which blocks are send to the backups. 'Binary' compression is an
additional compression on the blocks send to the backup.
1. Null Compression:
When backing up datafiles into backup sets, RMAN does not back up the contents of data blocks that have never been
allocated. (In previous releases, this behavior was referred to as NULL compression). This means RMAN will never
backup the blocks that are ever used. Till Oracle version 9i RMAN performs Null Compression.
Example : You have a tablespace having one datafile of size 100MB and out of 100MB only 50 MB is used. Then RMAN
will backup only 50MB.
2. Unused Block Compression:
From Oracle version 10.2 RMAN skips the blocks that do no currently contain data and this is called Unused Block
Compression. RMAN now creates more compact backups of datafiles, by skipping datafile blocks that are not currently
used to store data. In previous releases, RMAN only supported NULL compression, which skipped space in datafiles
that had never been allocated. No extra action is required on the part of the DBA to use this feature.
Example : You have a tablespace having one datafile of size 100MB and out of 100MB, 50MB is used by the user
tables. Then user dropped a table belonging to that tablespace which was of 25MB, with the new Unused Block
Compression on 25MB of the files is backed up. In this example if null compression is used then it would have backed
up 50MB because Null Compression will consider the blocks that are formatted/ever used.
Unused Block Compression is done, if all of the following conditions apply:
+ The COMPATIBLE initialization parameter is set to 10.2
+ There are currently no guaranteed restore points defined for the database
+ The datafile is locally managed
+ The datafile is being backed up to a backup set as part of a full backup or a level 0 incremental backup
+ The backup set is being created on DISK
or
backup is done to TAPE using "OSB" (Oracle Secure Backup)!
Note:
Unused Block Compression is NOT used if backup done to tape using a THIRD PARTY BACKUP SOFTWARE !
Skipping unused data blocks where possible enables RMAN to back up datafiles using less space, and can make I/O
more efficient.
3. Binary Compression:
Binary Compression can be done by specifying "AS COMPRESSED" clause in backup command, this compression is
called as binary compression.
RMAN can apply a binary compression algorithm as it writes data to backup sets. This compression is similar to the
compression provided by many tape vendors when backing up data to tape. But we cannot give exact percentage of
compression. This binary compression algorithm can greatly reduce the space required for disk backup storage. It is
typically 2x to 4x, and greater for textintensive
databases.
The command to take the compressed backup :
RMAN> backup as compressed backupset database;
+ There is some CPU overhead associated with compressing backup sets. If the database being backed up is running
at or near its maximum load, you may find the overhead from using AS COMPRESSED BACKUPSET unacceptable. In
most other circumstances, compressing backupsets saves enough disk space to be worth the CPU overhead.
+ There is no special command to restore database from the compressed backupsets, the restore command will be
the same as with uncompressed backups.
+ The restore from the compressed backpuset will take more time than uncompressed backupsets.
In addition to the existing BZIP2 algorithm for binary compression of backup in oracle 10G, RMAN 11G executable also
support ZLIB algorithm for the compress backup with the Oracle Database 11g Advanced Compression Option. BZIP2 is
the default compression for RMAN in 11g as well as 10g.
BZIP2 Compression ratio is very good but is slow and CPU intensive.
ZLIB Compression is very fast but compression ratio is not as good as other algorithm. (11g only and with Advanced
Compression Option)
The supported algorithms are BZIP2 (default) and ZLIB. The BZIP2 algorithm is optimized for maximum compression,
whereas the ZLIB algorithm is optimized for CPU efficiency. BZIP2 consumes more CPU resource than ZLIB, but will
usually produce more compact backups. The COMPATIBLE initialization parameter must be set to 11.0.0 or higher for
ZLIB compression, which requires the Oracle Advanced Compression option.
Compression can be used for backupset of datafile, archive log and controlfiles.
e.g
RMAN> backup as compressed backupset archivelog all;
RMAN> backup as compressed backupset database;
RMAN> backup as compressed backupset current controlfile;
RMAN compress the backupset contents before writing to disk. No extra decompression steps are required during
recovery for rman compressed backup;
To configure the compression algorithm
RMAN> CONFIGURE COMPRESSION ALGORITHM '<alg_name>';
4. Various Compression Types:
For various compression types you can refer to V$RMAN_COMPRESSION_ALGORITHM
SQL> select ALGORITHM_NAME, ALGORITHM_DESCRIPTION, ALGORITHM_COMPATIBILITY from
V$RMAN_COMPRESSION_ALGORITHM ;
ALGORITHM_NAME ALGORITHM_DESCRIPTION ALGORITHM_COMPATIB
BZIP2
good compression ratio 9.2.0.0.0
BASIC good compression ratio 9.2.0.0.0
LOW maximum possible compression speed 11.2.0.0.0
ZLIB balance between speed and compression ratio 11.0.0.0.0
MEDIUM balance between speed and compression ratio 11.0.0.0.0
HIGH maximum possible compression ratio 11.2.0.0.0
6 rows selected.
MOD Note ID:A Complete Understanding of RMAN Compression (Doc ID 563427.1)
Channel Control Options:
- Control the OS resources RMAN uses when performing the RMAN operations.
- Affect the degree of parallelism for a Backup or Restore command.
- set limits an I/O band width consumption in kb/mb/gb
ALLOCATE CHANNEL ........RATE.
CONFIGURE CHANNEL ..... RATE.
- Set limits on the size of backup pieces.
- set limits on the size of backup sets.
- Specify which instance performs the operations.
CONFIGURE CHANNEL ........ CONNECT.
- Specify Vendor-Specific parameter for the media manager.
( ALLOCATE CHANNEL ....PARMS,
CONFIGURE CHANNEL ... PARMS)
Benfits of RMAN:
- RMAN fully automated.
- Support high speed incremental backups.
- Can perform error checking when backup or during recovery
- Can perform image copies which are similar to OS backup.
- Can be used with 3rd party backup.
- Unused block compression let you skip unused data blocks, this saving space & time.
RMAN Configure parallelism:
Default -- 1
Maximum -- 254
Examples:
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
To check status:
RMAN> SHOW CHANNEL;
RMAN> SHOW DEVICE TYPE
RMAN> SHOW DEFAULT DEVICE TYPE
to display the current configured settings for automatic channels.
manual channel allocation:
RUN{
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
...
}
To clear the channels & device settings:
RMAN> CONFIGURE CHANEEL DEVICE TYPE ....... CLEAR;
CONFIGURE DEFAULT DEVICE TYPE CLEAR;
CONFIGURE CHANNEL DEVICE TYPE .... CLEAR;
CONFIGURE CHANNEL n DEVICE TYPE .... CLEAR;
erases the channel configuration for the specified device type.
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECE SIZE= 1800K;
RMAN> CONFIGURE MAXSETSIZE TO 7500K; ( 2pow n round the value) by default bytes
SHOW MAXSETSIZE;
