最近负责起了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你需要的字段,就会大大降低很多压力:
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28207565/viewspace-757314/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28207565/viewspace-757314/