本文介绍了如何处理WRH问题。内容非常详细，感兴趣的朋友可以参考一下。希望对你有帮助。
几天前，我处理了Oracle高可用性变得不可用的问题。问题是WRH$_ACTIVE_SESSION_HISTORY。
环境是具有RAC和单实例数据库的后台。首先，当我抽查AWR时，发现单实例数据库非常糟糕。(我不是运维DBA，这些都不在我的掌控之中，遇到问题就来找我。)有些SQL不能整天执行。我断定开发和写作一定有问题。
这台机器很好。96C 256G内存。然后有人来找我说RAC连接不上。我会接通。输入用户名和密码需要很长时间。
查看最新的AWR报告，原来凌晨4点是最后一个。现在已经12点多了。已经八个小时了。
既然没有AWR，那么AWR就无法生存。看看桌子空间。
乍一看，SYSAUX的空间几乎满了，尺寸是64G。这一定不能被看到。这个尺寸有点奇怪。操作系统只能识别一个文件32G，怎么会有64G？所以应该有两个文件。每个文件32G。真的是这个样子。由此推断，之前的运维问题直接掩盖了。
让文件自动展开，再加一个文件到32G，然后自动展开。不管为什么会出问题。这就留下了隐患。如果我们继续原来的想法，再加一个，然后让他自动达到32。然后会越来越大，很难解决。
查看会话和流程视图。都快4000了。看看数据库中的这两个参数。一个4000，一个6000多。也就是说，在运维之前，我们应该已经看到了它们的增加，但是我们并没有感觉到异常，既然连接的数量不够，我们就要增加它们。至于这些问题，我们不会解决。好像这不关他们的事。
想象一下，如果现在连接数不够，参数继续扩大，那么这个会越来越大。我在后面控制不了。
我查了一下，SYSAUX空间最大的表是WRH$_ACTIVE_SESSION_HISTORY，大约7000万条数据。顾名思义，该表是活动会话历史表。所以这和发展的问题有关。
估计truncate可以回收26G的空间。这个过程花了大约20分钟。越大越难，时间越长。这是平时不注意问题的后果。
当然，在再次这样做之前，先看看它是哪一天开始变大的，然后再看看。从上周五开始，每秒有3500个项目。
根本的解决办法是发展和改革，但目前只有截断，WRH$_ACTIVE_SESSION_HISTORY释放空间，才能使用。然后为单实例用户创建一个配置文件，以限制与RAC的连接。因为这主要是单实例连接RAC造成的。这个实例实际上来自dblink。没有问题。通过单个实例创建实体化视图。但是，开发是远程连接到RAC，而不访问本地现有的实体化视图。
最初，分离的目的是防止单实例机器重新启动RAC，但结果仍然是一样的。事实上，如果做得好，放在一起是没有问题的。生意不大。如果做不到，分开也没用。就实际开发状态而言，我们可以通过查看满负荷运行的单个实例来了解开发的水平和能力。
这些机器每天可以处理30-50万笔交易，这不是问题，但现在估计有3000笔交易无法处理。
下面是如何处理WRH$_ACTIVE_SESSION_HISTORY问题。希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/127542.html