一次WRH$_ACTIVE_SESSION_HISTORY问题处理

前几天处理了一次Oracle高可用变成不可用的问题。问题出在这个上面WRH$_ACTIVE_SESSION_HISTORY。
环境是有一个RAC和一个单实例数据库的背景。先是单实例数据库在我抽查AWR的时候发现很糟糕。（我不是运维DBA，这些不归我管，只是遇到问题来找我）有的一个SQL执行一天都执行不完。我就判定开发写的一定有问题。
机器非常好96C 256G内存。然后有人找我说那个RAC的连不上了。我去连接一下，输入用户名密码要等很久。
去检查一下最近的AWR报告，结果发现早上4点是最后一个。而现在是12点多。已经8个小时了。
既然没有AWR，那么就是AWR存不下来了。看看表空间怎么个情况。
一看SYSAUX空间几乎满了，大小是64G。这个不得让人看到这个大小有点奇怪的感觉。操作系统只能认到一个文件32G，怎么有64G。那么也就是说应该是有两个文件。每个文件都是32G。一看果然是这样的。推断以前运维的出现问题直接掩盖了。
让文件自动扩展，到了32G再加一个，再自动扩展。为什么出现异常不管。这就留下来隐患。如果还是继续原来的思路，再加一个，然后让他自动到32.那么就越来越大，不好解决。
在看一下session 和process两个视图。都是将近4000的。在看看数据库中这两个参数一个是4000一个是6000多。也就是说运维之前应该是看到了他们增大，但是没觉得异常，既然连接数不够就加。至于这些问题都不去解决。好像觉得这些不是他们事情。
可以想象如果现在连接数不够了，继续扩大参数，那么这个也会越来越大。后面就控制不住了。
查了一下SYSAUX空间最大的表是WRH$_ACTIVE_SESSION_HISTORY大概7000多万条数据。这个表顾名思义是活动会话历史表。所以这个和开发的问题是有关系的。