streams pool占用内存异常，导致数据库出现大量的ORA-04031

0、案例概述

客户的一套19C版本CDB架构的RAC集群，据现场的同事反馈，节点1的alert日志中出现大量ORA-04031错误，严重时，用户执行的任何SQL语句都会返回ORA-04031，而节点2正常。客户希望尽快排查错误原因。

 

1、故障分析

1.1 分析数据库的alert和ORA-04031对应的trace日志。

由于权限原因，现场的同事无法及时提供alert和trace日志，只提供了一份AWR报告。

 

1.2 基于目前的情况，只能先看看AWR报告，如果无法从AWR报告中找出故障原因，再继续提供其他日志信息。

 

1.3 分析AWR报告

从上图可以看出：数据库的负载较低，但Library hit却只有70%，这远远低于理想值。这也许正是出现ORA-04031的原因。后续需要重点关注Library hit为什么这么低。

从这里，我们可以发现疑点：节点1这台主机的物理内存有256GB，SGA分配了大概117GB左右。但BufferCache 和 SharedPool 加起来才17GB左右，那剩余的内存被什么组件占用了呢？

从时间模型部分可以看出：硬解析的时间占比是非常高的。

对于ORA-04031这个故障的原因，大胆作出以下推测：SharedPool分配的内存太少，或者在运行过程中，SharedPool内存空间被SGA中的其他组件猎夺，导致SharedPool不够，最终出现大量的ORA-04031和硬解析。

 

为了印证这一推测，继续查看AWR中的内存部分。

从图中可以看出：SharedPool最开始有18GB左右，但在运行过程中，最小只有8GB左右。大量的SharedPool内存被其他组件猎夺，这极容易出现librarycache相关的等待事件，以及ORA-04031故障。同时，我们也可以看出，StreamsPool组件竟然占用了96GB左右的内存，这个内存占用情况是非常离谱的。StreamsPool组件通常是数据同步工具才会使用该组件。访问现场的同事，得知该节点上部署了一套第三方的数据同步工具。

至此，整个故障已经非常清晰。第三方的数据同步工具占用了大量的StreamsPool内存，继而进一步猎夺SharedPool内存，造成SharedPool内存不够用，只能进行大量的硬解析，甚至因为SharedPool内存不够而出现ORA-04031。

 

查看数据库的初始化参数设置。

可以看出：StreamsPool内存设置成了80GB，这个设置是非常不合理的。另外一个问题是：StreamsPool最多时占用了96GB的内存，比设置的80GB初始值还高，第三方的数据同步工具，为什么会占用这么多的StreamsPool内存，是需要深入研究的。 鉴于只有一份AWR报告，目前只能分析到这个位置。

 

2、建议

立即调小StreamsPool内存设置，同时给SharedPool内存设置一个最小值，比如：25GB。保证业务能够正常运行，SharedPool不会被其他的内存组件猎夺内存资源，而产生ORA-04031。

后期，需要第三方的数据同步工具厂商介入调查，为什么需要这么大的StreamsPool内存？同时，也不能排除是数据库的BUG，没有更多的信息，暂不做进一步分析。