on规则（默认为8天）不断将数据Purge掉。无论如何设置，sysaux正常情况下应该是一个固定稳定的大小规格。笔者当前数据库已经运行一两年的时间，要出问题早就出现问题了。说明系统中，有一些数据在不断的“默默长大”，问题在不断的慢慢积累。
尝试检查当前sysaux表空间段结构排名，看有没有与此相关的信息。
SQL> select owner, segment_name, segment_type, bytes/1024/1024 from (select * from dba_segments where tablespace_name='SYSAUX' order by bytes desc) where rownum<5;
OWNER? ? ? SEGMENT_NAME? ? ? ? ? SEGMENT_TYPE? ? ? BYTES/1024/1024
---------- ------------------------------ ------------------ ---------------
SYS? WRM$_SNAPSHOT_DETAILS_INDEX INDEX? ? ? ? ? ? ? ? ? ? ? ? ? 102
SYS? WRM$_SNAPSHOT_DETAILS? ? ? TABLE? ? ? ? ? ? ? ? ? ? ? ? ? 88
SYS? SMON_SCN_TO_TIME_AUX? ? ? CLUSTER? ? ? ? ? ? ? ? ? ? ? ? 80
XDB? SYS_LOB0000057474C00025$$? LOBSEGMENT? ? ? ? ? ? ? ? 53.1875
疑问出现了，最大的几个对象中，snapshot赫然出现在其中。当前Snapshot里面没有数据，无论是被自然purge掉，还是认为删掉，都不应该有数据存在。查看基础数据表：
SQL> select count(*) from WRM$_SNAPSHOT_DETAILS;
? COUNT(*)
----------
? 1723102
SQL> select * from WRM$_SNAPSHOT_DETAILS where rownum<5;
? SNAP_ID? ? ? DBID INSTANCE_NUMBER? TABLE_ID BEGIN_TIME? ? ? ? ? ? ? ? ? ?
---------- ---------- --------------- ---------- -------------------------------
? ? ? ? 1 1778314713? ? ? ? ? ? ? 1? ? ? ? ? 4 05-12??-12 05.00.08.719 ????? ?
? ? ? ? 1 1778314713? ? ? ? ? ? ? 1? ? ? ? ? 5 05-12??-12 05.00.08.771 ????? ? ?
? ? ? ? 1 1778314713? ? ? ? ? ? ? 1? ? ? ? ? 6 05-12??-12 05.00.08.841 ????? ? ? ?
? ? ? ? 1 1778314713? ? ? ? ? ? ? 1? ? ? ? ? 7 05-12??-12 05.00.08.892 ????? ?
其中数据量还是很大的，重点在于snap_id。
SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT_DETAILS;
MAX(SNAP_ID) MIN(SNAP_ID)
------------ ------------
? ? ? 23383? ? ? ? ? ? 1
“慢慢变大”的数据找到了，作为AWR基础的数据，从来就没有被删除。手工删除呢？是不是可以删除？
SQL> select snap_id from dba_hist_snapshot;
? SNAP_ID
----------
? ? 23383
SQL> exec dbms_workload_repository.drop_snapshot_range(1,23383);
PL/SQL procedure successfully completed
SQL> select snap_id from dba_hist_snapshot;
? SNAP_ID
----------
SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT_DETAILS;
MAX(SNAP_ID) MIN(SNAP_ID)
------------ ------------
? ? ? 23383? ? ? ? ? ? 1
SQL> select max(snap_id), min(snap_id) from WRM$_SNAPSHOT;
MAX(SNAP_ID) MIN(SNAP_ID)
------------ ------------
删除的数据，没有连带将基础数据表WRM$_SNAPSHOT_DETAILS内容删除。诡异的问题！
经过查证MOS，发现该数据表不能删除是一个Oracle Bug，具体描述如下：
Bug 9797851 - WRM$_SNAPHOST_DETAILS is never purged
The verification criteria for the bug are:
Drop a range of snap id's using dbms_workload_repository.drop_snapshot_range()
Check the corresponding snap id's in WRM$_SNAPSHOT_DETAILS.
If snap id's from the range that you chose to drop are still present, then you are hitting this bug.
The following solutions are available:
The Patch 9797851 for unpublished Bug 9797851 is available for some platforms and can be downloaded from My Oracle Support
If the patch is not available on your platform on a supported version, please contact Oracle Support.
This issue will be fixed from release Oracle 12.1
As a workaround, it is possible to manually purge the range of snap id's from the table WRM$_SNAPSHOT_DETAILS using appropriate delete statments under the guidance of Oracle Support.
其中内容所，如果要解决这个问题，需要进行补丁操作，或者在Oracle Support指导之下手工进行删除。
由于是生产环境，经过协调，认为当前开启拓展sysaux策略是可以接受的解决方案。于是笔者打算适可而止，不影响系统正常运行。
4、恢复自动AWR收集
最后需要恢复AWR收集。注意：在一些资料中，建议最开始有一个snapshot，通过手工创建，之后Oracle才能自动的进行生成。
为了快速验证，调整收集周期是10分钟。
SQL> exec dbms_workload_repository.create_snapshot;
PL/SQL procedure successfully completed
SQL> exec dbms_workload_repository.modify_snapshot_settings(interval=>10);
PL/SQL procedu