[Translated from mos] a thorough understanding of rman compression, mos Article rman Compression

[Translated from mos] a thorough understanding of rman compression, mos Article rman Compression

A thorough understanding of rman Compression
Source:
A Complete Understanding of RMAN Compression (Document ID 563427.1)

Applicable:
Oracle Database-Enterprise Edition-Version 8.1.7.4 to 11.2.0.3 [Release 8.1.7 to 11.2]
Information in this document applies to any platform.
* ** Checked for relevance on 14-Oct-2014 ***

Objectives:
How does rman compression work?

Solution:
By default, rman has three types of compression:
1. null compression
2. unused block compression
3. binary Compression

10.1 and earlier, only null compression can be used
From 10.2, null compression and unused block compression can be used.
The compression is automatically executed, and no special commands are required to perform the compression.

Null compression and unused block compression are used to filter the backup blocks (of course, there are filtering rules)
Binary compression is an additional compression, which is implemented at the block level of backup.

1. null compression
When backing up datafile to backupset, rman does not back up data blocks that have never been allocate (in earlier versions, this behavior is called null compression)
This means that rman never backs up blocks that never used. Until oracle 9i, rman executes null compression.
Example:
There is a tablespace. This tablespace has a datafile. The datafile size is 100 MB. Among these MB, 50 MB has been used, so rman will only back up 50 MB.

2. unused block compression

Starting from oracle 10.2, during rman backup, the skip will drop blocks that do not currently contain data. This behavior is called unused block compression.
Using skip to drop blocks that are not currently used to store data, rman creates a more compact backup of datafile. In earlier oracle versions,
Rman only supports null compression. null compression means that the skip drops the space in datafile that has never been allocate. When this feature is used, dba is not required for additional work.

For example, there is a tablespace in which there is a datafile, which has 100 MB, 50 MB of which has been used by the user table.
Then the user dropped a 25 MB table in the tablespace, with the new Unused Block Compression on 25 MB of the files is backed up.
In this example, if null compression is used, 50 MB will be backed up, and null compression will be considered (in fact, it is more appropriate to translate it into a backup) blocks that have been formattd and used for used.

If all of the following conditions are met, unused block compression will be enabled:
1) The compatible parameter is set to 10.2.
2) guaranteed restore points is not defined in db
3) datafile is managed locally.
4) datafile is backed up,
5) The backup set is created on the disk.
Or
Use OSB (Oracle Secure Backup) to create a Backup set on tape.

Note: If you use a third-party backup software to back up data to tape, unused block compression will not be used.

Skipping the unused data block will allow rman to use less space to back up datafile, making io more efficient.

3 binary Compression

Binary compression can be used by specifying the keyword 'as compressed 'in the backup clause. This compression is called binary compression.

When rman writes data to the backup set, rman can use the binary compression algorithm. This compression is similar to the compression of many tape vendpoints when backing up data to tape.
However, we cannot give an exact compression percentage. This binary compression algorithm can greatly reduce the disk space occupied by backup files. The typical compression is 2X or 4x, and the compression factor for text-intensive databases is even higher.

The command for compressing and backing up data is

RMAN> backup as compressed backupset database;

Cpu overload occurs when backupset is compressed. When compressing and backing up a database with the largest load, you will find that using as compressed backupset for backup is unacceptable.
In most other scenarios, compressing the backup set saves enough disk space, which is worth increasing the cpu load.
The restore database in compressed backupset does not require special commands. The restore command is the same as the restore command in non-compressed backup.
The restore time in compressed backupset is longer than that in non-compressed backup.

In addition to the BZIP2 compression algorithm used for binary compression in oracle 10g, rman 11g also supports the ZLIB algorithm to compress the backup using the database 11g advanced compression option.
BZIP2 is the default Compression Algorithm in 11g and 10g.

BZIP2 has a high compression rate, but is slow and cpu-sensitive.
ZLIB is fast, but the compression ratio is not as high as other algorithms (11 GB and can be used only when advanced compression options are used)

The supported compression algorithms are BZIP2 (default) and ZLIB. The BZIP2 compression algorithm is optimal for maximum compression.
The ZLIB compression algorithm is optimized for CPU usage. BZIP2 consumes more cpu resources than ZLIB, but generally generates more compact backups.
For ZLIB compression algorithm, the initialization parameter compatible must be set to 11.0.0 or higher, and Oracle Advanced compression option is required.
Binary compression can be used in: controlfile, archive log, datafile
For example:

MAN> backup as compressed backupset archivelog all;RMAN> backup as compressed backupset database;RMAN> backup as compressed backupset current controlfile;

Before writing data to a disk, rman compresses the content of the backupset (contents). For rman compression backup, no additional decompression steps are required.
The compression algorithm is configured as follows:

RMAN> CONFIGURE COMPRESSION ALGORITHM '<alg_name>';

4. Various compression algorithms:
For different compression algorithms, You can query 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.0BASIC           good compression ratio                                       9.2.0.0.0LOW             maximum possible compression speed                           11.2.0.0.0ZLIB            balance between speed and compression ratio                  11.0.0.0.0MEDIUM          balance between speed and compression ratio                  11.0.0.0.0HIGH            maximum possible compression ratio                           11.2.0.0.06 rows selected.