亲爱滴伙伴们！本萎专家又来了，本篇将介绍本萎专家的6步擒龙法，薅出ORA-600的元凶。
首先介绍下环境：
| 数据库版本 | 12.2.0.1 |
| 是否RAC | 是 |
该问题是在滚动打DBRU Patch 30886680(12.2.0.1.200414)时发生的。
该DBRU之前在测试库，ADG备库及一些边缘库均已成功打上，运行2个星期观察均无异常。
最后将所有核心库均打上该DBRU。安装模式为滚动升级，经历这波疫情，大家为了体验现场通宵的疲惫感，争先恐后的要求现场，结果很多兄弟现场一起欢快的开始了通宵之旅。
都是老司机，哥几个信心满满开干，并都觉得提前一小时交卷是张飞吃豆芽，小菜一碟啊。
本萎专家分到了几套RAC，过程中遇到了些小插曲，但都在本萎专家的手速下顺利的提前完成了补丁升级，依照check-list检查核实均正常后，即交付业务侧开始业务测试。
正准备眯一下的时候，一个兄弟那边反馈打完一个节点的时，检查DB ALERT日志发现报一大堆的ORA-600（当晚监控告警已摘除）。
本萎专家第一反应就是，又是丫的你啊！点儿这么背。。。。。，同样的DBRU，同样的系统版本，同样的数据库版本，为啥就你打会报错？？你丫的是不是上完厕所没洗手啊。。。。。。
调侃归调侃，但身体很诚实，毕竟ORA-600不是小事。得抓紧分析原因，最开始以为是补丁的问题，后面从补丁升级成功的库把PSU SCP过去（统一标准运维的好处），回滚重新打发现问题依旧。
后面陆续接到其他兄弟的反馈，每个人手上的部分库一个节点打完补丁，起实例后DB ALERT日志也都报一大堆ORA-600。
这。。。。。。都没洗手？显然问题没这么简单了。为了事情可控，本萎专家建议暂停了其他节点的补丁工作。咱得先把问题分析清楚再继续，如果在规定时间前一个小时还没搞定，所有问题库都回滚到打补丁前状态。毕竟这可都是事关全省业务的核心库啊！想到这里裆部一紧，抓紧干正事儿。
下面开始本萎专家的六步ORA-600擒龙分析：
一、 查看DB ALERT日志：
二、继续分析trace
发现触发SQL是一个查询实例状态等信息的内部调用SQL。
SQL输出截图如下：
三、MOS搜素
看不到更多有用的信息，本萎专家的第一感觉告诉自己，娘希匹的触发BUG了吧。登陆MOS查看有无堆栈信息类似的BUG，一搜真有发现，ID 406804.1中显示在12.2.0.1版本中有：
四、继续分析BUG如下:
该BUG在21.1.0.0 fixed。。。。。。看看有没有Workaround，哇哈，人品大爆发，还真有：
五、BUG属性
根据BUG特征描述只有在_ges_direct_free设置成true时才可能触发该BUG，后面我们通过查看数据库参数及trace日志证实确是触发该BUG。
Trace日志如下：
数据库查询该参数的确设置成true了，那这个参数是干嘛用的呢？
按照文档描述，如果将_ges_direct_free设置成true，就是禁用GES资源缓存。
六、当时为啥设置_ges_direct_free
通过查找历史邮件发现当时是为了解决SGA手动管理情况下，db cache及共享池频繁自动调整BUG，根据SR要求设置予以了该隐含参数的设置。
后续的DBRU包含了这个BUG的FIX，本萎大师将在后续其他文章中详细介绍SGA手动管理模式下，内存频繁抖动导致的相关性能问题。
既然根源找到了，那赶紧把_ges_direct_free设置成false，然后重启所有实例，数据库又回到了熟悉的正常状态。剩下继续打其他节点的DBRU，最后还是提前一个小时完成本次工程工作。
好了，本次六步ORA-600擒龙法到此表述完毕，预听其他故事，咱下回再见。
