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.