案例:ORA-04031 12.1.0.2 on exadata x7

某银行客户近期频繁出现ORA-04031,报错如下:

此次报错的subheap为SQLA^559c65a1,通过trace查看该子堆与父堆的信息

可以看到该子堆已经分配了85360 bytes,extent大小为4072,根据chunk的分配原则,首先尝试在子堆中分配,如果子堆free list无法分配则向父堆申请,这时申请的chunk大小将会是extent size,并作为一个新的extent挂在子堆下。查看子堆的FREE list如下:

请求940字节,但是子堆free list只有704 byte,所以这时会像父堆申请一个子堆extent size的chunk 即4072 bytes,但是trace中并未发现父堆的详细信息。

查看subpool的top组件:

发现组件ksfqpn的内存占用异常,gcs resources和gcs shadows也占用偏高,ksfqpn与io接口相关,ksfq – kernel service functions sequential file io interface,通过查阅mos文档发现与Bug 25058080  Excessive allocation of memory “ksfqpn” in SGA using RMAN backups in Exadata匹配。

其bug主要原因是由于内部算法导致ksfqpn内存重用和回收出现了异常。导致ksfqpn大小是x$ksfgp的1000倍以上

此条目发表在Oracle, Oracle troubleshooting分类目录,贴了, , 标签。将固定链接加入收藏夹。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注