对于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:\DEVELOPER\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST\TESTTS1.02.DBF' resize 18m;
alter database datafile 'F:\DEVELOPER\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST\TESTTS1.01.DBF' resize 5m;
alter database datafile 'F:\DEVELOPER\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEST\TESTTS1.03.DBF' resize 40m;
执行这里的sql语句就可以了，不过这里注意了，这里可以看到，实际上是用最大的blocks作为resize的标准，如果size超过，或者是已经扩展过的block 就会出现 文件包含在请求的 RESIZE 值以外使用的数据的错误了，所以这个方法，可行但是并不是很实际。这样的case基本上只在做练习的时候出现。
3. 如果你是一个表或者少量的表在那个表空间，可以通过creat table as select ...的方式或者move的方式，move完成后再干掉表空间，干掉表空间的时候，including contents and datefiles就可以了。