有关执行计划，空间释放的另一些

      最近负责起了DBA的部分工作，于是有一天在对表空间的清理中发现了一张表，这个表有27G那么大，是一个分区表，按天分区。我查看了过程，每天删除35天以前的数据，但是用的方法是delete，那么我就可以很明确的推断出，这个表占用了大量本应该释放的空间。

      我第一个使用的方法是move：

      

alter table table_name move partition part_1;

　　 这样做很快，但是今天我在看一本书的时候，上面记载这种方法会更改rowid，会让原来的索引失效。不过和我的有一点小出入：

       

      这个表上没有索引，所以我这样做了也无所谓，但是系统中存在着很多这样的表，我需要试验一下在分区表上move操作会不会导致索引失效。事实上我不需要建立索引实验，我只需要知道move之后rowid变了没有就好了。

      建一张分区表：

      

create table test1
(
   day_id varchar2(2),
   value number
)
partition by range(day_id)
(
   partition part_1 values less than ('02'),
   partition part_2 values less than ('03')
);

insert into test1 values ('01', 1);
insert into test1 values ('01', 2);
insert into test1 values ('02', 1);
insert into test1 values ('02', 2);
commit;

　　

     上图是数据。下面只查询一下part_1里的数据：

     

     然后在执行move语句，看看这样之后的结果：

     

    仔细看，rowid确实变了，根据上面书中的记载，这样是要导致索引失效的。后来经过实际测试，确实失效（我在day_id列上建立的local索引）。失效之后rebuild索引的时候不能使用这个语句：

    

alter index idx_name rebuild;

　　而要一个分区一个分区的重建：

      

      继续上面第一段的内容说，这个表被我从27G弄到了3.7G，省了快20G的空间出来，对我们这种没什么空间的系统很宝贵了。

      如果水位线高的话会严重影响查询的执行计划，test是一张不分区的表，这个表被我delete全部数据之后以append的方式插入了和delete之前相同多的数据。

      首先建立这个表：

      

create table test as select * from dba_objects;
--收集统计信息
analyze table test compute statistics;

　　执行计划是这样子的：

     

     然后将所有的数据删除掉，以append方式插入原来的那么多数据，然后分析表，然后看执行计划：

     

delete from test;
commit;
insert /*+append*/ into test select * from dba_objects;
commit;
analyze table test compute statistics;

　　

      如上如红色框处所示，在查询得到的结果相同的情况下，COST要大了很多，我推测这是扫描了那些本来应该释放掉的数据块所致。

      move之后情况就会变得不一样：

      

      我听说很多技术很正规的公司不允许写select *。我觉得这个是对的，select你需要的字段，就会大大降低很多压力：