聊聊昨天说的那个ORA-4030

​昨天有朋友看了我的聊聊文章提问CHATGPT能不能解读AWR报告。怎么说呢，昨天我们先来看一个例子。聊聊

我输入了一个AWR报告的昨天TOP 10 EVENT，看看CHATGPT如何解读吧。聊聊

如果说解读AWR的昨天TOP EVENTS数据，我想CHATGPT不会比一些人类DBA差了，聊聊实际上最初的昨天时候我也是如此解读AWR报告的，只不过AWR报告不仅仅需要能解读，聊聊还需要能分析，昨天能够把AWR中各种相关的聊聊数据综合起来分析，才能从AWR报告中分析出深层次的昨天问题。对于一些十分明显的聊聊问题，仅仅从TOP EVENT就可以看出来了，昨天而绝大多数复杂的聊聊问题，是无法从这些地方找出答案的。这一点CHATGPT肯定做不到，甚至大多数人类DBA也做不到。不过如果经过足够的训练，CHATGPT也可能能做到。

实际上，b2b供应网临时表空间的直接路径读写肯定是与非优化的大排序有关，如果我来解读AWR的时候，遇到这个情况，肯定要去翻PGA相关的数据。从而发现存在一些大SQL的硬盘排序过多。

要想让CHATGPT做到这一点，不仅仅需要更多的训练，更需要高水平的DBA采用正确的方法与它对话，引导它向正确的方向上计算，从而完成深度的解读。

我们还是回到昨天提到的那个案例，对于DBA来说，ORA-4030可能是一个十分明确的问题，我也一直是如此认为的。ORA-4030不外乎物理内存耗尽，操作系统ULIMIT限制，IT技术网操作系统根目录空间等因素。直到上星期一个客户的一个具有1.5TB的超大内存系统报ORA-4030错误我才认识到以前知识的局限性。

客户的一个数据库系统出现了一些ORA-4030报警，都集中在采集TOP SQL的监控系统中，普通业务模块并未报警。         

当时的报错场景是有些奇怪的，从SWAP INFORMATION上看，这个报错十分没有道理。物理内存还有近400GB的FREE，SWAP基本没用。但是在执行一条访问v$sql的语句的时候，出现了无法映射内存的错误。

当时的报错信息是这样的，报错位置是：kxs-heap-w,kqlfto,kqlfo:kqlfoobj。Kxs-heap-w的含义是云服务器执行SQL的时候分配一个内存用于写入，kqlfto是数据库内核与OS BUFFER之间的缓冲。Kqlfoobj是从SGA向PGA/UGA写入数据时产生的。串联起来是当会话在执行SQL语句的时候，从SGA向会话私有内存输出数据的时候，无法分配内存。从下面的TOP 10内存使用情况看,kqlfto:kqlfoobj占了72%，达到2935MB。反推一下，总的进程内存大约是4076MB。

经过分析后，当时我们认为通过调整vm.max_map_count可以解决这个问题，不过用户暂时不同意调整。于是我们只能从另外一个角度去做调整。当时发现报错的实例的SQLAREA特别大，于是在业务不忙的时候刷新了一下共享池，让130多GB的SQLAREA变得正常了，访问V$SQL采集SQL的功能才恢复了正常。采用这种处置方式的原理是SQLAREA中数据少了，向PGA输出数据时，PGA就不会达到4G的限制了。实际上这个案例最终还是要通过调整OS或者数据库参数来解决。

事后分析的时候，我们在MOS上也查到了大量的NOTES。这个问题是和Oracle的实内存分配（非共享内存分配）有关的。

_realfree_heap_pagesize_hint（12c之后，这个参数改名为_realfree_heap_pagesize）是 Oracle 数据库中的一个参数，用于设置非共享内存管理器的页面大小。真正的空闲内存管理器用于管理数据库用于PL / SQL内存和其他非共享内存的真实内存（非SGA）。其默认大小是64KB。因为RHEL操作系统的vm_max_map_count是65530，能够影射的内存大小是有限的，Oracle的_realfree_heap_pages参数定义了每个影射的块大小，Oracle 11g默认是64K，所以PGA中最多可以影射4GB的物理内存。如果超出这个限制，就会因为max_map_count的限制而无法分配内存。

Oracle官方的解决方案是加大_realfree_heap_pagesize_hint或者修改max_map_count。调整任何一个参数都可以让Oracle PGA能够MAP更多的物理内存。

根据这个情况，我们需要更新ORA-4030的知识库，增加故障模型中的诊断路径，把相关的Oracle参数，OS参数等因素加入进去，同时在数据库巡检时增加对这方面的分析与诊断。知识就是这样通过不断地迭代，日益完善的。运维知识完善的基础是来自于生产一线的运维案例。​

最新评论