临近中午，接到同事反馈一客户业务系统异常缓慢，功能基本处于无法使用的状态，远程到客户业务网进行排查。
发现是sysaux表空间利用率基本达到100%导致的，最终原因是由于awr相关表没有根据保留策略进行清除，导致
与表关联的段越来越大最终撑满sysaux表空间。
官方文档Doc ID 387914.1中提到的解决方案是通过alter session set "_swrf_test_action" = 72;命令进行手动拆分
分区，此篇文档中采用的方式为手动truncate awr相关表的方式进行解决，现将处理过程进行记录。
1、接到故障报修后首先进行数据库日志分析，发现alert日志存在ORA报错提示，提示sysaux表空间不足，如下图：
2、然后根据提示查询数据库表空间使用率，发现sysaux表空间竟然用满了32GB，表空间使用已率经达到100%，查询
结果如下图：
备注：sysaux表空间为system系统表空间辅助表空间，负责存放AWR快照信息、统计信息等。若空间爆满会对数
据库正常应用造成影响。
3、通过命令查询sysaux的使用情况，确定具体占用空间过大的对象，发现是awr相关信息占用率过高，如下图：
SELECT occupant_name "Item",
space_usage_kbytes / 1048576 "Space Used (GB)",
schema_name "Schema",
move_procedure "Move Procedure"
FROM v$sysaux_occupants
ORDER BY 2 desc ;
4、定位是AWR报告占用了30Gb的表空间，进一步查询占用空间大的段，发现基本都是AWR历史信息导致的，如图：
select * from (
select segment_name,SEGMENT_TYPE,sum(bytes)/1024/1024 total_mb
from dba_segments
where tablespace_name ='SYSAUX'
group by segment_name,SEGMENT_TYPE order by 3 desc)
where rownum <=20;
5、通过sql脚本拼接方式批量生成占用sysaux表空间大于100M的表，如图所示：
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;
6、执行生成的sql语句，降低大表的高水位线，释放sysaux空间。如图：
7、进行上述操作后再次查询表空间的利用率，发现sysaux表空间已经处于正常范围之内，如图：
8、对数据库进行查询操作，手动生成awr快照操作均没有任何报错发生，通知客户进行业务测试，业务c测试使用
正常。
总结：此次故障发生的原因是由于过旧的awr报告信息未按照awr快照保留策略进行删除导致的。具体官方解释如下：
文章提到Oracle 根据保留策略确定需要清除哪些行。对于AWR大表，通过特殊的机制将快照数据存储在分区中。
从这些表中清除数据的一种方法是删除仅包含已超过保留条件的行的分区。在夜间进行清除行时，如果分区中所
有数据都超了保留策略，则次分区就会被删除，如果分区中只要包含一行不满足保留策略的数据，则分区不会被
删除，那么表中将会包含过旧的数据。
另外如果分区拆分没有发生（无论出于何种原因），那么最终可能会遇到的情况是我们必须等待最新的条目过期，
然后才能删除它们所在的分区。这可能意味着某些较旧的条目可以大大超过其到期日期。这样做的结果是数据不会
按照预期被清除。
