整理表碎片通常的方法是move表，当然move是不能在线进行的，而且move后相应的索引也会失效，oracle针对上述不足，在10g时加入了shrink，那这个方法能不能在生产中使用呢？
shrink的一个优点是能在线进行，不影响表上的DML操作，当然，并发的DML操作在shrink结束的时刻会出现短暂的block；shrink的另外一个优点是在碎片整理结束后，表上相关的index仍然enable。对于第二点进一步说明下，shrink在整理表碎片的时候，行源的rowid已经发生改变，那为什么相关的索引还能enable呢？其实oracle在进行shrink的时候会对相应的索引进行维护，以保证index在shrink结束的时候index仍然有效。这个维护不同于索引rebuild，不会对索引的空间进行整理，shrink有cascede选项，如果在shrink的时候加上该选项，就会对表上相应的索引空间进行整理。
ALTER TABLE test SHRINK SPACE CASCADE;
SHRINK SPACE 具体 操作：
解决经常大量 DELETE 数据导致查询慢的问题.
--打开行移动
ALTER TABLE table_name ENABLE ROW MOVEMENT;
--收缩空间
ALTER TABLE table_name SHRINK SPACE CASCADE;
--关闭行移动
ALTER TABLE table_name DISABLE ROW MOVEMENT;
shrink，原理解释：
shrink也可以分两步进行，第一步先执行ALTER TABLE test SHRINK SPACE compact,此时oracle会在高水位线以下将row尽量向segment的顶部移动，但不收缩高水位线，即不释放空间。这个操作对于那些在尝试读取已经被释放的块的查询是有益的。第二不执行ALTER TABLE test SHRINK SPACE，此时第一步中的结果已经存储到磁盘，不会重新在整理碎片，只是收缩高水位，释放空间。第二步操作应该在系统不繁忙时候进行。
我们先看下shrink的工作原理，shrink的算法是从segment的底部开始，移动row到segment的顶部，移动的过程相当于delete/insert操作的组合，在这个过程中会产生大量的undo和redo信息。在HP Unix上还存在BUG，在10.1.0.3.0中，在shrink的时候可能会触发BUG 3888229，产生巨大数量的redo和undo。move是直接移动数据块的位置，鉴于上面的原因，在使用shrink的时候，耗时可能非常长，通常慢于move。
对于空间的要求，shrink不需要额外的空间，move需要两倍的空间。
通过上面的分析，shrink虽然有online的特性，但是也存在很多问题，所以，在进行表碎片整理的时候，还是建议停机检修，使用move，以下是一些move时候的注意点：
1、move前最好逻辑备份待整理的表；
expdp
2、对于大表，建议开启并行和nologging
alter table test move nologging parallel 2;
3、整理完毕后重建相关的索引
alter index ind_test rebuild nologging parallel 2;
4、恢复表和索引的并行度、logging
alter table test logging parallel 1;