Understanding RMAN backup of used blocks [Oracle 9i and 10gR1] RMAN Concepts manual states that "RMAN performs compression on its backups, which means that datafile blocks that have never been used are not backed up". This "never been used" is strictly enforced. If you have a big table and it's later truncated or most columns dropped, the space once used by that table still makes the backup piece big. RMAN doesn't care about segment high water mark; in fact, even after the table is dropped, space is still counted. The only way to reduce the size of the backup piece is shrink the datafile. The word "compression" in the manual does not mean data compression as in gzip or Winzip. [Oracle 10gR2] This has changed in 10gR2; even if "data" remains in the datafile, as long as their segment has been dropped from data dictionary, the RMAN backup piece WILL BE SMALLER. See "Unused Block Compression" in Note:360443.1. [Update 2009-12] Tested 10.2.0.1. Problem still exists (backup piece is the same size). Tested 10.2.0.4. Problem fixed (backup piece is slightly smaller than sum(bytes) from dba_data_files minus sum(bytes) from dba_free_space). Also from 10gR2 on, you can really compress backup sets (BACKUP AS COMPRESSED BACKUPSET ...), making OS-level compression unnecessary. ---------------------------------------------------------------------------------------------------- Related: What's considered used by dbv? (http://www.itpub.net/thread-1078266-1-1.html) When dbv sees blocks that have data, it doesn't check whether the data belongs to any segment. It's even possible the segment has been dropped. This is true even in Oracle 10g. Do this test: create tablespace test datafile 'c:\test.dbf' size 10m; create table t (x char(1000)) tablespace test; --The SQL below just inserts some data. Syntax is for 10g only. insert into t select rownum from dual connect by level <= 1000; alter system checkpoint; drop table t purge; You can run dbv between every two steps above. What's relevant here is that if you run dbv after the table t is dropped, even purged, so the tablespace test is absolutely empty as far as data dictionary is concerned, dbv still says there's data in it. So dbv doesn't care about the logical side of Oracle, only physical side of it.