WRH$_ACTIVE_SESSION_HISTORY问题的处理方法

这篇文章给大家介绍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多万条数据。这个表顾名思义是活动会话历史表。所以这个和开发的问题是有关系的。
估算了一下，truncate一下可以回收26G空间。这个过程大概花了20分钟。越大越难做，时间越长。这就是平时不注意问题的后果。
当然再做这个之前查查这个哪天开始是大的，查下来上周五开始，每秒都是3500条。
彻底根治办法是开发改，但是眼前先只能truncate这个WRH$_ACTIVE_SESSION_HISTORY释放空间。然后创建个概要文件给单实例用户，限制连接到RAC的连接。因为这个主要是单实例连接到RAC造成的。而这个单实例其实是dblink过来的。这本来没有问题。单实例建立物化视图。但是开发就是不访问本地已经有的物化视图就是要远程连接到RAC上来。
最初分开目的是为了让单实例的机器不对RAC重启，结果还是这样。其实如果做得好的情况下，放在一起也没有问题。业务不大。做不到的情况下，分开也没有用。就实际的开发现状而言，看看单实例上满负荷在运行就知道开发的水平和能力了。
这些机器每天处理30-50万笔交易不是问题，但是现在估算3000都处理不了。

关于WRH$_ACTIVE_SESSION_HISTORY问题的处理方法就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。