1. 首页
  2. IT资讯

一次ora-4031事故的反思

前段时间交易库一个节点发生了Ora-4031报错,当时所有的SQL都无法分配共享内存,这又导致session塞车与暴增,从而连sqlplus也连不上了,当时的处理将应用切换到第二节点,然后强行重启第一节点(其余还应先试一下sqlplus -prelim选项作个dump)后问题解决。 但一直没太想明白的是,共享内存为什么会不够,从trace文件,当时KGH-NO ACCESS点了28G,最大头,但不明白到底是什么内容,系统的硬解析很低,也没有什么解析内存占用高的SQL,只是根据历史数据发现,KGH-no access在不断增长,从而显示share pool也是在不断增长的,开了SP,但是oracle的回复也不是bug,疑问没有清楚解答; 综合大家的意见,觉得是SQL的解析造成的,于是反复查找那些解析高的SQL,但是心里总觉得不够证据充分,终于在看tanel poder大师的一篇blog时,领悟到,KGH-no access是被oracle的自动内存管理拿去作为data buffer了,怪不得名字叫“no access”,原来是”智能“地当data buffer使用,而且越来越大,虽然貌似还是预留了空间,但基于共享池的子池特性,找空间只找sub0(哪怕sub1,sub2,sub3有空间却不找),所以出现找不到空间是很有可能的,只能说是自动内存管理弄巧成拙吧,怪不得oracle自己也不承认是bug,只是给出控制自动内存管理的解决方案; 只是理清了这一点之后,感觉问题找到了”靠谱“的答案,心里也畅通了许多,不过也奇怪,像这样的坑,好像踩的人并不多呢。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13365316/viewspace-2126969/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:布吉卡,转转请注明出处:http://www.cxybcw.com/194596.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code