oracle 10g SYSAUX表空间快速增长之WRI$_OPTSTAT_HISTGRM_HISTORY篇

在下午的检查中，还发现另外几个对象在sysaux表空间中占据很大的空间：I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST，大小为4124M，WRI$_OPTSTAT_HISTGRM_HISTORY，大小为2893M，前者是后者的索引，此表是用来保存历史的的收集统计信息的。

查看metalink相关文章：

Statistics space used by SM/OPTSTAT in the SYSAUX tablespace is not reclaimed after purging [ID 454678.1]

Reduce SYSAUX Tablespace Occupancy Due to Fragmented TABLEs and INDEXes [ID 1271178.1]

发现metalink上认为的是这个表索引的碎片比较多，需要重整。在oracle10g中，重整表的方式有多种，为了不重新rebuild index，且不影响现在的业务，没有采用move的方式，而是采用shrink 的方式对索引进行了收缩：

ALTER INDEX I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST SHRINK SPACE;

shrink后，此索引的大小缩至286.75M，同时此表的大小也有很明显的缩小，现在只有309M，效果挺明显；

再对WRI$_OPTSTAT_HISTGRM_HISTORY shrink:

ALTER TABLE WRI$_OPTSTAT_HISTGRM_HISTORY SHRINK SPACE;

报：ORA-10631: SHRINK clause should not be specified for this object

经过分析，原来此表上有函数索引，此索引正是上面的那个索引： I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST ，有函数索引的表是不能进行shrink操作的。

如果时间允许，可以尝试按照move的方式对这些表重整一下，并重建索引。

-- To implement the solution, please execute the following steps::
1- Take a full backup of the database
2- Move the tables:

sql> alter table WRI$_OPTSTAT_TAB_HISTORY move;
sql> alter table WRI$_OPTSTAT_OPR move;
sql> alter table WRI$_OPTSTAT_IND_HISTORY move;
sql> alter table WRI$_OPTSTAT_HISTHEAD_HISTORY move;
sql> alter table WRI$_OPTSTAT_HISTGRM_HISTORY move;
sql> alter table WRI$_OPTSTAT_AUX_HISTORY move;

3- For indexes, find the indexes for the above tables and rebuild them. In case an index is unusable, please see the following example:

SQL> select status from dba_indexes where index_name='I_WRI$_OPTSTAT_IND_OBJ#_ST';
SQL> select status from dba_indexes where index_name='I_WRI$_OPTSTAT_TAB_ST';

Assuming that indexes: I_WRI$_OPTSTAT_IND_OBJ#_ST & I_WRI$_OPTSTAT_TAB_ST are unusable, then, we have to do the following:

a.Determine the DDL's for the indexes using dbms_metadata package as shown in the example below
SQL> set long 4000
SQL> select dbms_metadata.get_ddl('INDEX','I_WRI$_OPTSTAT_IND_OBJ#_ST','SYS') from dual;
SQL> select dbms_metadata.get_ddl('INDEX','I_WRI$_OPTSTAT_TAB_ST','SYS') from dual;

b.Then drop and recreate the indexes using the obtained DDL's.

c.Once done you can confirm the status by running the following query for example :
SQL> select status from dba_indexes where index_name='I_WRI$_OPTSTAT_IND_OBJ#_ST';
SQL> select status from dba_indexes where index_name='I_WRI$_OPTSTAT_TAB_ST';

4- sql> exec dbms_stats.alter_stats_history_retention(8);  
--> This will ensure that statistics history will be retained for at least 8 days.