对于10G之前的的空间管理（表TABLE和索引INDEX）相对其他任务来说是个“PHYSICAL WORKS”。最大的问题就是操作麻烦、时间长且容易出错。
    通用的方法基本上就是：EXP/IMP(除非没有业务处理，否则因为时间较长，极容易造成数据的不一致性)，ALTER TABLE ...MOVE(容易造成索引不可用，有可能引起前台应用出现错误，且需要额外的表空间)。而对于索引来讲，基本上就是REBUILD来解决了，同时也需要额外的空间。
    但是在10G中，对于TABLE和INDEX的空间管理变成了“A PIECE OF CAKE!”
    ORACLE提供的SHRINK命令，可以轻松搞定对于DBA来讲是复杂、繁琐又容易出错的重复性劳动。
    通过ORACLE自动收集（一般为每小时一次）的信息为基础，我们可以通过多种方法确定哪些表需要进行空间收缩管理。象SEGMENT ADVISOR或使用DBMS_SPACE这样的PL/SQL包来获得信息等等。
    此处我们可以通过例如：
        在此基础上获得的信息，我们可以直接执行SHRINK操作，通过这个命令来达到，释放未使用空间，降低HWM，提高查等性能的目的（尤其是全表扫描 FULL TABLE SCAN）。执行命令如下：

    其中执行完一个对索引的SHINK后，其空间占用由222M直接降到了96M！
    多说一句，可以通过dbms_space.space_usage，来计算出表进行SHRINK的基本情况。
    通过这样的命令，我们可以不但可以在线执行那些正在被操作的表，并且不需要任何额外的空间。（其实质就是内部执行DELETE和INSERT操作，因为数据本身并没有发生改变，所以只是对数据进行重组REORG，且DML操作不会激发TRIGGER的执行）
    值得注意的参数：
    我们执行这样一个带有CASCADE的语句时

    ORACLE将自动执行所有相依赖对象的SHRINK操作，例如该表相关索引的SHRINK操作。但是需要注意，相关的materialized views,IOT mapping tables,LOB indexes and overflow segments将不会被执行。并且该'ALTER ...SHRINK'命令不但支持简单的堆表(heap tables)和索引，并且还支持 index-organized tables, partitions, subpartitions, materialized views and materialized view log 。
    但是，还是要说个但是：
       
    进步，ORACLE总是在不断进步着 -:)
   
  

本文出自 “Be the miracle!” 博客，请务必保留此出处http://miracle.blog.51cto.com/255044/56245

本文出自 51CTO.COM技术博客