Oracle处理关于sysaux表空间爆满的问题---更新最新方法！！

对于SYSAUX表空间而言，如果占用过大，那么一般情况下是由于AWR信息或对象统计信息没有及时清理引起的，具体原因可以通过如下的SQL语句查询：

SELECT OCCUPANT_NAME "Item",SPACE_USAGE_KBYTES /  "Space Used (GB)",SCHEMA_NAME "Schema",MOVE_PROCEDURE "Move Procedure"FROM V$SYSAUX_OCCUPANTS WHERE SPACE_USAGE_KBYTES >  ORDER BY "Space Used (GB)" DESC;

或者如下语句

SELECT D.SEGMENT_NAME, D.SEGMENT_TYPE,SUM(BYTES)//  SIZE_M FROM DBA_SEGMENTS D WHERE D.TABLESPACE_NAME = 'SYSAUX' GROUP BY D.SEGMENT_NAME, D.SEGMENT_TYPE ORDER BY SIZE_M DESC

或者如下语句，查看前十

SELECT * FROM (SELECT SEGMENT_NAME,
               PARTITION_NAME,
               SEGMENT_TYPE,
               BYTES /  /
          FROM DBA_SEGMENTS
         WHERE TABLESPACE_NAME = 'SYSAUX'
         ORDER BY  DESC)
 WHERE ROWNUM <= ;

如果OCCUPANT_NAME列为SM/AWR（Server Manageability - Automatic Workload Repository），那么表示AWR信息占用过大；如果该列为SM/OPTSTAT（Server Manageability - Optimizer Statistics History），那么表示优化器统计信息占用过大。

如上截图，则是AWR信息过大，那么可以通过设置AWR的保留时间来减小AWR信息的存储空间，通过如下的SQL语句可以获取AWR的保留时间。

SELECT * FROM DBA_HIST_WR_CONTROL;

截图中可以看出在Oracle 11g中，AWR默认保留8天。Oracle版本为11.2.0.4.0，AWR默认保留期限8天。但是为什么会占用这么多SYSAUX表空间呢？首先，要明确AWR快照信息的删除方式：AWR报告默认是采取DELETE
的方式进行过期信息删除的，相比TRUNCATE而言，就会产生大量的碎片，对于开启了自动扩展数据文件的表空间而言，碎片的现会象更加严重。再有一点，ASH的信息在有可能不受AWR快照保留策略的控制。从如下SQL查询可得知，从SNAP_ID为1的快照到目前为止的所有快照都还在数据库中保存着，使用DBMS_WORKLOAD_REPOSITORY包清理过期或者不需要的AWR数据，可以回收这部分空间，但是由于是delete操作，无法降低水位线，对于自动扩展的表空间，碎片化更加严重。

select min(snap_id),max(snap_id) from  wrh$_active_session_history;

临时解决办法

直接查询出是哪些表分区

select distinct 'truncate  table  '||segment_name||';',s.bytes//
  from dba_segments s
 where s.segment_name like 'WRH$%'
   and segment_type in ('TABLE PARTITION', 'TABLE')
   and s.bytes//>
   order by s.bytes/// desc;

然后直接truncate。

终极解决办法

首先使用DBMS_WORKLOAD_REPOSITORY包清理快照信息（清理时间受快照数量和服务器性能影响，像我这清理大概用了四十分钟）。

exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id =>,high_snap_id => 34);

通过这种方式清理的AWR信息，再次查看SYSAUX表空间的空间，发现空间并没有被回收，使用率还和之前一样，这是因为清理AWR操作是通过DELETE操作实现的，表的水位线并没有下降导致的。但是通过再次查询可发现 WRH$_LATCH表记录已经少了。但是表大小还是没有变化。

对分区进行MOVE操作，回收表空间

按照以下步骤，根据实际情况，对每个表分区进行操作。这个表是分区表，分区表不支持表级别的MOVE操作，直接对分区表进行MOVE操作会遇到ORA-14511错误。示例如下

1、首先查看表的分区情况以及大小

select segment_name,partition_name,bytes/// gb from dba_segments where segment_name='WRH$_EVENT_HISTOGRAM';

2、对分区表进行MOVE操作，回收空间

alter table WRH$_EVENT_HISTOGRAM move partition WRH$_EVENT__2646583334_0;
alter table WRH$_EVENT_HISTOGRAM move partition WRH$_EVENT_HISTO_MXDB_MXSN;

3、MOVE后，重建分区表索引

##查看分区表索引信息
select index_name from dba_indexes where table_name='WRH$_EVENT_HISTOGRAM';
##重建分区表索引

SQL> select index_name from dba_indexes where table_name='WRH$_EVENT_HISTOGRAM';
INDEX_NAME
------------------------------
WRH$_EVENT_HISTOGRAM_PK
SQL> alter index WRH$_EVENT_HISTOGRAM_PK rebuild partition WRH$_EVENT__2646583334_0;
SQL> alter index WRH$_EVENT_HISTOGRAM_PK rebuild partition WRH$_EVENT_HISTO_MXDB_MXSN;

使用toad查看水位已经降了下来

其他表也照此操作处理即可。

流程可以参考下图，先在plsql上查询top10和编辑语句，直接复制到服务器sql窗口执行，方便快捷。

经过处理几个表后，水位线已经降下大半，由于该测试操作的数据库后期已经不再使用，剩下的就不处理了，实际情况需要根据生产情况确定。

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------

今日发现一个博客，说了一些处理上的风险，部分数据库可以参考这个清理，尤其对那些繁忙的数据库。

地址如下

http://blog.itpub.net/26148431/viewspace-2135213/

参考原文链接：https://blog.csdn.net/lihuarongaini/article/details/101298827