级别 初始 备完 耗时
low 1804 3572 0:10
High 1812 3176 2:00
MEDIUM 1820 3288 0:13
BASIC 1828 3444 0:56 ---不如MEDIUM,时间还长
NO COMPRESS 1820 5924 0:5
RMAN> CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE include current controlfile plus archivelog;
SYMPTOMS
1> Rman COMPRESSION ALGORITHM is set to 'BASIC' ---> Default value
SET COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
两个命令都可以
RMAN> CONFIGURE COMPRESSION ALGORITHM 'basic';
old RMAN configuration parameters:
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
new RMAN configuration parameters:
CONFIGURE COMPRESSION ALGORITHM 'basic' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
2> Compressed backup takes more time then Uncompressed backup.
BACKUP AS COMPRESSED BACKUPSET DATABASE include current controlfile plus archivelog;
BACKUP DATABASE include current controlfile plus archivelog;
COMPRESS:
=========
DBGIO: Type %Comp Blocks Tot Blocks Blksize ElpTime(s) IO Rt(b/s) Name [17:42:22.326] (krmkqio)
DBGIO: ---- ----- ---------- ---------- ---------- ---------- ---------- ----- [17:42:22.326] (krmkqio)
DBGIO: IN 100.0 4192894 4194302 8192 808 42510133 <path>/<db_filename> [17:42:22.326] (krmkqio)
DBGIO: OUT 472348 8192 808 4788953 <path>/<backup_piece_name> [17:42:22.326] (krmkqio)
DBGIO: AGG 4192894 8192 808 42510133 [17:42:22.326] (krmkqio)
DBGMISC: ENTERED krmzlog [17:42:22.326]
NO COMPRESS:
============
DBGIO: Type %Comp Blocks Tot Blocks Blksize ElpTime(s) IO Rt(b/s) Name [17:49:38.004] (krmkqio)
DBGIO: ---- ----- ---------- ---------- ---------- ---------- ---------- ----- [17:49:38.004] (krmkqio)
DBGIO: IN 100.0 4192894 4194302 8192 116 296105065 <path>/<db_filename> [17:49:38.004] (krmkqio)
DBGIO: OUT 4192900 8192 116 296105489 <path>/<backup_piece_name> [17:49:38.004] (krmkqio)
DBGIO: AGG 4192894 8192 116 296105065 [17:49:38.004] (krmkqio)
CHANGES
CAUSE
Bug 14157581 was created on this issue
Bug 14157581 - EXADATA: RMAN COMPRESS BASIC BACKUP EXTREMELY SLOW Bug 14157581 - EXADATA: RMAN COMPRESS BASIC BACKUP EXTREMELY SLOW Bug 14157581 - EXADATA: RMAN COMPRESS BASIC BACKUP EXTREMELY SLOW> ----> Closed as duplicate of Bug 13784430 .
This was closed as not a Bug and expected behavior.
13784430 Bug 13784430 Bug 13784430 Bug 13784430Thi
SOLUTION
This is an expected behavior as confirmed by development.Performance slowness can be a part of basic compression.
Moreover, the default compression algorithm is optimized for best compression (not best performance).
You can try using other other type of Compression((like LOW, MEDIUM and HIGH) ,However please note you need to have License for Advanced Compression to use them.
GOAL
How does RMAN compression works ?
Goal of this document is to give you a Complete Understanding of
-
Null compression
-
Unused block compression
-
Binary compression
SOLUTION
A Complete Understanding of RMAN Compression
By default RMAN has three types of compression :
-
Null compression
-
Unused block compression
-
Binary compression
Untill Oracle Version 10.1 only 'Null' compression is done by default. In Oracle Version 10.2, and forward, 'Null' and 'unused block' compression is done by default. The types of compression are done automatically, no special command is required.
'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 contained data. This behavior is referred to as 'NULL block compression'. This means RMAN will not backup blocks that have never been used. RMAN, through Oracle version 9i and forward has performed 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.
NOTE: Null Compression also applies to Standard Edition and SE ONE
2. Unused Block
From Oracle version 10.2 forward, RMAN skips reading, and backing up, any database blocks that are not currently allocated to a database object. This is regardless of whether those blocks had previously been allocated. This behavior is reffered to as 'Unused Block Compression'. RMAN now creates more compact backups of datafiles, by skipping datafile blocks that are not currently allocated to a database object. Skipping these unallocated data blocks, i.e., for a dropped table, where possible enables RMAN to back up datafiles using less space, and can make I/O more efficient. 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 or higher
-
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
-
The backup is done to TAPE using "OSB" (Oracle Secure Backup)
-
The backup is done with ZDLRA
Note:
Unused block compression is NOT used if backup done to tape using a THIRD PARTY BACKUP SOFTWARE !
Unused block compression is ONLY used in Enterprise Edition.
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 text-intensive 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 binary compression of backup in oracle 10G, RMAN 11G executable offers a wider range of compression levels with the Advanced Compression Option (ACO). The default compression algorithm setting is BASIC and does not require the Advanced Compression Option.
If, however, you have enabled the Oracle Database 11g Release 2 Advanced Compression Option, you can choose from the following compression levels:
LOW - Least impact on backup throughput and suited for environments where CPU resources are the limiting factor.
MEDIUM - Recommended for most environments. Good combination of compression ratios and speed
HIGH - Best suited for backups over slower networks where the limiting factor is network speed
NOTE: Only BASIC compression is allowed in Standard Edition
Compression can be used for backupset of datafile, archive log and controlfiles. For example:
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.
5. Undo Block Compression/Optimization
Starting 11g, RMAN performs undo block optimization. In backup undo optimization, RMAN excludes undo not needed for recovery of a backup, that is, for transactions that have been committed. Undo optimization is only possible if:
- This is a backup set backup
- Full or incremental level 0
- Not a validate
- Backup piece version is 11.0 or above
- User has not disabled undo optimization with:
_undo_block_compression = FALSE - Backup is going to DISK or OSB tape
- No Guaranteed Restore Point (This check is enabled from 11.2 onwards)