在 OceanBase 运维过程中，你是否遇到过定时任务时段 CPU 突高、应用访问异常的情况？近期技术团队就处理了一例因统计信息收集，触发高并发 SQL 硬解析，最终打爆 OBServer 节点 CPU 的典型案例。
问题描述
某 OceanBase 集群（Oracle 租户模式）在默认统计信息收集时段，偶发CPU打爆，应用服务访问异常，持续故障时间是为晚上22:13～22:14分。之后把每日统计信息改到了凌晨02:00开始，窗口3小时，偶发故障时间变成02:12～02:15。
排查问题原因是：定期收集统计信息后续高并发SQL执行计划硬解析有关。
影响版本
租户模式：Oracle
OBserver版本:4.2.1 BP11 hotfix2
OBserver版本:4.2.5 bp7以下版本
问题排查
针对该故障，我们通过性能监控→表信息核查→会话分析→堆栈追踪四步排查，精准定位根因。
1.OCP租户性能监控查看租户cpu的使用
2.查看表的统计信息(DBA_TAB_STATISTICS)按照last_analyzed时间字段列降序查询
3.性能视图获取活跃会话（gv$ob_processlist）
4.OBServer cpu节点通过obstack 获取堆栈信息
155个线程里面，154个线程是在硬解析(因为父方法就是generate_plan)，1个在等futex_hook；154个线程里面有16个在等待latch，而154-16个线程里面在做硬解析里的各个方法。
等待latch的栈顶方法：
#0 0x0000ffff0fd71250 in ??? from /usr/lib64/libc-2.28.so
#1 0x0000aaaac1aa7c60 in futex_hook from /home/admin/oceanbase/bin/observer
#2 0x0000aaaac1ab7f0c in oceanbase::lib::ObFutex::wait(int, long) from /home/admin/oceanbase/bin/observer
#3 0x0000aaaac1ec6490 in oceanbase::common::ObLatchMutex::wait(long, unsigned int) from /home/admin/oceanbase/bin/observer
两次stack 都是在get_column_stat
大部分硬解析线程，都是在做get_column_stat里面的步骤，比如去kvcache里取缓存，比如分配新的block。
结合活跃会话同一个sql_id，同一个瞬间里，同一个sql_id的active session有155个，这个文件里总共276个active session。
最终根因：
并发SQL硬解析导致执行慢，打爆节点cpu。
挑选同一个线程号1043130，obstack.xc5-obsvr03b.1324670.2025-11-13_02_12_29.txt和obstack.xc5-obsvr03b.1324670.2025-11-13_02_12_50.txt两个文件相差了12秒，但是这个线程号还是相同的方法调用栈，当然这个线程号有去看好几个table_id
备注：当前版本是比如100个并发相同SQL，都会一起发生硬解析。
后续优化
1.优化之前是并发硬解析，优化之后控制一个线程去硬解析，其他的用kvcache里面的计划（计划标记淘汰，实际在kvcache中），相当于100个并发，本来是100个都做硬解析，现在就变成1个做硬解析，99个直接不做硬解析，使用标记淘汰的计划。
2.针对高并发硬解析进行《kvcache性能优化》
问题原因及解决方案
问题原因：
并发SQL硬解析导致执行慢，打爆节点cpu。
解决方案：
1.本场景在硬解析前后RT明显变大，与另一个已知的性能瓶颈，《kvcache性能优化》4.3.5 BP2 已修复。涉及底层调整，未定4.2.5 patch计划。
2.生产环境分布式场景一直存在这个风险。4.2.5BP4 SPM优化需求将分布式场景的计划淘汰策略移置至本地计划场景后，发生的概率变高。
3.目前生产环境没有针对本问题的运维手段。优化器需要调整以下两点：
**说明：**绑定 outline 后，计划硬解析会加快，能够缓解并发硬解析的情况。因为可以更快的得到一个计划，后续查询就不需要硬解析了
以上就是本次 OceanBase CPU 突高故障的完整排查与解决思路。
如果你在实际操作中遇到了问题，或者有其他优化的见解，欢迎在评论区留言交流，后续我们还会分享更多 OceanBase 运维实战干货，下次见~
更多技术分享可扫码关注查看~
