Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2896016
  • 博文数量: 599
  • 博客积分: 16398
  • 博客等级: 上将
  • 技术积分: 6875
  • 用 户 组: 普通用户
  • 注册时间: 2009-11-30 12:04
个人简介

WINDOWS下的程序员出身,偶尔也写一些linux平台下小程序, 后转行数据库行业,专注于ORACLE和DB2的运维和优化。 同时也是ios移动开发者。欢迎志同道合的朋友一起研究技术。 数据库技术交流群:58308065,23618606

文章分类

全部博文(599)

文章存档

2014年(12)

2013年(56)

2012年(199)

2011年(105)

2010年(128)

2009年(99)

分类: Oracle

2012-12-29 21:09:07

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 in done by default but from Oracle Version 10.2 'Null' and 'Unused Bloc'k 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 beloning 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.


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 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 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 '';

阅读(1194) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~