案例：troubleshooting error ORA-04031 always happens at duration 0

本案例来自南区某制造业客户环境，数据库版本为rac 11.2.0.4。在2节点频繁的出现ORA-04031，具体alert如下：

可以看到所有的报错都是来自subpool 6 duration 0。

通常ORA-04031的问题分析，都会去看看具体的trace文件，是否生成了heapdump，如果没有的话需要在业务停歇时段去采集一下heap dump，这里注意一下，dump heap的操作会长时间的持有shared pool latch，可能会导致数据库hang。或者可以查询X$KSMSP，但是对于大的shared pool，查询X$KSMSP也可能会导致数据库hang。

Level Description：

• 1 PGA summary
• 2 SGA summary
• 4 UGA summary
• 8 Callheap (Current)
• 16 Callheap (User)
• 32 Large pool
• 64 Streams pool
• 128 Java pool
• 1025 PGA with contents
• 2050 SGA with contents
• 4100 UGA with contents
• 8200 Callheap with contents (Current)
• 16400 Callheap with contents (User)
• 32800 Large pool with contents
• 65600 Streams pool with contents
• 131200 Java pool with contents

为什么这里是level 536870914呢？因为536870914=0x20000002

• 0x2=SGA summary
• 0x20000000=所有heap的top sub heap信息(LARGEST SUB HEAPS)

拿到heapdump之后，可以使用tp大神的heapdump_analyzer脚本或者oracle的heap.awk去进行分析。

可以看到4031报错的subpool 6 duration 0几乎被perm类型的chunk占满。free 32%的是保留池的chunk。

并且几乎所有的perm类型都分配到了每个subpool的duration 0当中。

当启用了AMM/ASMM时，并且开启了duration的情况下，几乎所有perm类型的chunk都会发配到duration 0当中，并且perm chunk一旦分配给了某个shared pool组件的heap则不会释放，也不能被shared pool的其他组件使用。所以就很容易发生duration 0的ORA-04031。

尤其是rac环境比较大的db cache，会分配大量的perm chunk给rac特有的shared pool组件，如gcs shadows/gcs resources/ges resources等等。通常rac环境如果db cache比较大都会是实际情况增加shared pool。

由于客户的环境shared pool分配已经是合理的大小了，所以这里我给到的建议是关闭duration。