oracle 10gR2 rman备份优化加强

在oracle 10gR1版本之前,用rman备份时会扫描曾经使用过的块(包括做过truncate table等等未回收的块),
导致rman备份集大小会比真正使用数据库的容量更大和备份时间更多。

以下为metalink文档解释：
For releases up to and including 10GR1:
Each datafile is fully scanned. RMAN backs up every block that has ever been written to even if it is currently on the free-list so for example, if a table is truncated blocks used by that table are still included in the backup. Only blocks that have never been written to are omitted (NULL compression). Hence:
physical database size determines INPUT workload
the number of dirty blocks determines backuppiece size
oversizing files for future growth is costly to RMAN as the whole file still has to be scanned with very little output

昨天有个客户用9iR2 rman备份数据库就发现这个问题，真正数据库容量只有150G,而备份集大小就有200G,
导致规划存储容量用来做备份时产生不准确的估算。
10gR2版本就做了改进，备份优化，只备份真正使用过的块，可以提高备份空间，性能和效率
metalink解释：

Release 10GR2 and later:
If a tablespace is locally managed (LMT), compatible is set to 10.2 or later and a full or level 0 backup is being done to DISK, rman will only scan blocks that are CURRENTLY allocated to an object (Unused Block Compression). So for example, if a table is truncated blocks used by that table will not be scanned by RMAN. Unused Block Compression results in improved backup performance by reducing the number of blocks scanned hence:
the space bitmap index for an LMT determines INPUT workload
the number of dirty blocks within those scanned determines backuppiece size
pre-allocating oversized extents to an object can be wasteful for RMAN as the whole extent will be scanned with relatively little output
Unused Block Compression cannot be used by:
3rd party media managers - the whole file is scanned every time a tape backup is done
Incremental backups – to get faster incremenals use Block Change Tracking
RMAN backup VALIDATE command
Oracle Secure Backup is the only media manager able to take advantage Unused Block Compression.

在给客户做10gR2 rman备份时，备份集大小与数据库容量大小非常相近。