对于SYSAUX表空间而言，如果占用过大，那么一般情况下是由于AWR信息或对象统计信息没有及时清理引起的，具体原因可以通过如下的SQL语句查询：
SELECT OCCUPANT_NAME "Item",SPACE_USAGE_KBYTES / 1048576 "Space Used (GB)",SCHEMA_NAME "Schema",MOVE_PROCEDURE "Move Procedure"FROM V$SYSAUX_OCCUPANTS WHERE SPACE_USAGE_KBYTES > 1048576 ORDER BY "Space Used (GB)" DESC;
或者如下语句
SELECT D.SEGMENT_NAME, D.SEGMENT_TYPE,SUM(BYTES)/1024/1024 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 / 1024 / 1024 FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'SYSAUX' ORDER BY 4 DESC) WHERE ROWNUM <= 10;
如果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/1024/1024 from dba_segments s where s.segment_name like 'WRH$%' and segment_type in ('TABLE PARTITION', 'TABLE') and s.bytes/1024/1024>100 order by s.bytes/1024/1024/1024 desc;
然后直接truncate。
终极解决办法
首先使用DBMS_WORKLOAD_REPOSITORY包清理快照信息（清理时间受快照数量和服务器性能影响，像我这清理大概用了四十分钟）。
exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id =>1,high_snap_id => 34000);
通过这种方式清理的AWR信息，再次查看SYSAUX表空间的空间，发现空间并没有被回收，使用率还和之前一样，这是因为清理AWR操作是通过DELETE操作实现的，表的水位线并没有下降导致的。但是通过再次查询可发现 WRH$_LATCH表记录已经少了。但是表大小还是没有变化。
对分区进行MOVE操作，回收表空间
按照以下步骤，根据实际情况，对每个表分区进行操作。这个表是分区表，分区表不支持表级别的MOVE操作，直接对分区表进行MOVE操作会遇到ORA-14511错误。示例如下
1、首先查看表的分区情况以及大小
select segment_name,partition_name,bytes/1024/1024/1024 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
