共计 1348 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章给大家介绍 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 问题的处理方法就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
