对于table空间的收缩是一个老生常谈的问题，不过却是一个一直都没有很透彻的讨论清楚过的问题。借ks_reny的机会，谈谈个人看法，有不及之处，希望高手引领更深入研究此话题。
　　datafile是物理上的一个文件在下层就是基于文件系统的block块了，而我们经常提到的segment,extent,数据库的 block，这里都是oracle存储是的逻辑上的单位，所以首先设想一下如果是你来实现delete或者drop的操作的时候，你会是真正的调用文件系统的API，而重新把datafile重新整理一遍吗，我想你也不会如此的吧。这样的话，每个delete或者是drop的操作将会带来我们更多的痛苦。所以Oracle更不会如此，这就是为什么你的datafile的大小并没有发生变化的原因，那么，文件系统上虽然没有重新修理datafile，但是 oracle里却通过自己的实现，通过对内部逻辑单元的处理，在逻辑上已经删除了那些单元，从而storage manage知道以后如果需要的连续block这里可以满足的话，就把这个碎片填上了。所以对于oracle来说，他很清楚这里是可用的，这样利用率也就小了变话了。

　　所以这里要解决你的问题就要使我们的datafile瘦身，只有datafile瘦下来了，你的data又不变化了，利用率也就上升了。那么如果让你的datafile瘦下来了，

　　1. exp/imp expdp/impdp 这个虽然原始，也比较繁琐，但是确实是一个非常稳定可靠的方法。

　　2. resize resize面临一个问题，resize到多大，大了没有意义，小了出现错误。

　　这里特地写了一个sql脚本，你可以使用运行这个脚本的结果，就是你指定的file做resize的命令

　　SQL> variable blocksize number;

　　SQL> begin execute immediate 'select value from v$parameter where name = ''db_block_size''' into :blocksize; end;

　　2 /

　　SQL>print :blocksize;

　　SQL> select 'alter database datafile ''' ||

　　2 file_name || ''' resize ' ||

　　3 ceil( nvl(hwm,1)*:blocksize/1024/1024 ) || 'm;' cmd

　　4 from dba_data_files a,

　　5 ( select file_id,

　　6 max(block_id+blocks-1) hwm

　　7 from dba_extents

　　8 group by file_id ) b

　　9 where a.file_id = b.file_id(+) and b.file_id in (7, 8, 10);

　　CMD

　　--------------------------------------------------------------------------------

　　alter database datafile 'F:DEVELOPERORACLEPRODUCT10.2.0ORADATAORCLTESTTESTTS1.02.DBF' resize 18m;

　　alter database datafile 'F:DEVELOPERORACLEPRODUCT10.2.0ORADATAORCLTESTTESTTS1.01.DBF' resize 5m;

　　alter database datafile 'F:DEVELOPERORACLEPRODUCT10.2.0ORADATAORCLTESTTESTTS1.03.DBF' resize 40m;

　　执行这里的sql语句就可以了，不过这里注意了，这里可以看到，实际上是用最大的blocks作为resize的标准，如果size超过，或者是已经扩展过的block 就会出现 文件包含在请求的 RESIZE 值以外使用的数据的错误了，所以这个方法，可行但是并不是很实际。这样的case基本上只在做练习的时候出现。

　　3. 如果你是一个表或者少量的表在那个表空间，可以通过creat table as select ...的方式或者move的方式，move完成后再干掉表空间，干掉表空间的时候，including contents and datefiles就可以了。