一次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://blog.itpub.net/13365316/viewspace-2126969/