Oracle 10g Shrink Table – Shrink Space 收缩空间

Oracle 10g Shrink Table的使用是本文我们主要要介绍的内容,我们知道,如果经常在表上执行DML操作,会造成数据库块中数据分布稀疏,浪费大量空间。同时也会影响全表扫描的性能,因为全表扫描需要访问更多的数据块。从Oracle 10g开始,表可以通过shrink来重组数据使数据分布更紧密,同时降低HWM释放空闲数据块。

segment shrink分为两个阶段:

  1. 数据重组(compact):通过一系列insert、delete操作,将数据尽量排列在段的前面。在这个过程中需要在表上加RX锁,即只在需要移动的行上加锁。由于涉及到rowid的改变,需要enable row movement.同时要disable基于rowid的trigger.这一过程对业务影响比较小。
  2. HWM调整:第二阶段是调整HWM位置,释放空闲数据块。此过程需要在表上加X锁,会造成表上的所有DML语句阻塞。在业务特别繁忙的系统上可能造成比较大的影响。Shrink Space语句两个阶段都执行。Shrink Space compact只执行第一个阶段。
    如果系统业务比较繁忙,可以先执行Shrink Space compact重组数据,然后在业务不忙的时候再执行Shrink Space降低HWM释放空闲数据块。shrink必须开启行迁移功能。

    alter table table_name enable row movement ;
    

    注意:alter table XXX enable row movement语句会造成引用表XXX的对象(如存储过程、包、视图等)变为无效。执行完成后,最好执行一下utlrp.sql来编译无效的对象。

语法:

alter table <table_name> shrink space [ <null> | compact | cascade ];  
alter table <table_name> shrink space compcat; 

收缩表,相当于把块中数据打结实了,但会保持high water mark;

alter table Shrink Space;

收缩表,降低 high water mark;

alter table Shrink Space cascade;

收缩表,降低 high water mark,并且相关索引也要收缩一下下。

alter index idxname Shrink Space;

回缩索引

  1. 普通表
    Sql脚本,改脚本会生成相应的语句

    select'alter table '||table_name||' enable row movement;'||chr(10)||'alter table '||table_name||' shrink space;'||chr(10)from user_tables;  
    select'alter index '||index_name||' shrink space;'||chr(10)from user_indexes; 
    
  2. 分区表的处理
    进行Shrink Space时 发生ORA-10631错误.Shrink Space有一些限制.
    在表上建有函数索引(包括全文索引)会失败。
    Sql脚本,改脚本会生成相应的语句

    select 'alter table '||table_name||' enable row movement;'||chr(10)||'alter table '||table_name||' shrink space;'||chr(10) from user_tables where ;  
    select 'alter index '||index_name||' shrink space;'||chr(10) from user_indexes where uniqueness='NONUNIQUE' ;  
    select 'alter table '||segment_name||' modify subpartition '||partition_name||' shrink space;'||chr(10) from user_segments where segment_type='TABLE SUBPARTITION' '; 
    

Shrink的几点问题:

  1. shrink后index是否需要rebuild:因为shrink的操作也会改变行数据的rowid,那么,如果table上有index时,shrink table后index会不会变为UNUSABLE呢?
    我们来看这样的实验,同样构建my_objects的测试表:

    create table my_objects tablespace ASSM as select * from all_objects where rownum<20000;  
    create index i_my_objects on my_objects (object_id);  
    delete from my_objects where object_name like '%C%';  
    delete from my_objects where object_name like '%U%'; 
    

    现在我们来shrink table my_objects:

    SQL> alter table my_objects enable row movement;  
    Table altered  
    SQL> alter table my_objects shrink space;  
    Table altered  
    SQL> select index_name,status from user_indexes where index_name='I_MY_OBJECTS';  
    INDEX_NAME STATUS  
    ------------------------------ --------  
    I_MY_OBJECTS VALID 
    

    我们发现,table my_objects上的index的状态为VALID,估计shrink在移动行数据时,也一起维护了index上相应行的数据rowid的信息。我们认为,这是对于move操作后需要rebuild index的改进。但是如果一个table上的index数量较多,我们知道,维护index的成本是比较高的,shrink过程中用来维护index的成本也会比较高。

  2. shrink时对table的lock
    在对table进行shrink时,会对table进行怎样的锁定呢?当我们对table MY_OBJECTS进行shrink操作时,查询v$locked_objects视图可以发现,table MY_OBJECTS上加了row-X (SX) 的lock:

    SQL>select OBJECT_ID, SESSION_ID,ORACLE_USERNAME,LOCKED_MODE from v$locked_objects;  
    OBJECT_ID SESSION_ID ORACLE_USERNAME LOCKED_MODE  
    ---------- ---------- ------------------ -----------
    55422 153 DLINGER 3  
    SQL> select object_id from user_objects where object_name = 'MY_OBJECTS';  
    OBJECT_ID  
     ----------  
    55422 
    

    那么,当table在进行shrink时,我们对table是可以进行DML操作的。

  3. shrink对空间的要求
    我们在前面讨论了shrink的数据的移动机制,既然oracle是从后向前移动行数据,那么,shrink的操作就不会像move一样,shrink不需要使用额外的空闲空间

转自:http://blog.itpub.net/35489/viewspace-709279/

发表评论

电子邮件地址不会被公开。 必填项已用*标注