在盖老师的公开课中，提到了一个控制SQL多版本的参数，有很多朋友讨论，这个参数是：_CURSOR_OBSOLETE_THRESHOLD 。
为什么会有这个参数呢？请看下面这个示意图，这是一个真实的生产环境，第一个SQL显示，其Version Count已经达到了26万个，这不仅仅占用了内存，而且会使得SQL解析延迟：
对于版本过多的SQL，一次软解析甚至不如重新执行一次硬解析来的高效，所以Oracle引入了一系列的控制手段来处理这些特殊的游标。
在11.2.0.3之后，这些解决方案最终形成了一个隐含参数，也就是 _CURSOR_OBSOLETE_THRESHOLD，其作用是当SQL版本超过这个参数设定后，直接舍弃这个游标，重新解析，重头开始。在这一版本之前，通过补丁和参数（"_cursor_features_enabled" 和 event 106001）可以达成类似的效果。
Oracle的很多细节控制都是体贴入微的，且用且珍惜吧。
关于SQL的多版本，MOS文章 296377.1 非常值得仔细看看。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/12798004/viewspace-1718565/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
最新文章
- 第84期 查询RAC之间私网的流量信息，监控 RAC 私网流量变化
- 第83期 MySQL JSON Duality View + HeatWave Vector Search for RAG
- 第82期 Oracle 19c RAC集群：如何在线迁移/替换 OCR 磁盘组
- 第81期 批量抓取数据库中耗时最高的SQL自动生成【Active HTML格式的SQL Monitor报告】
- 第80期 追踪 SQL 性能随时间变化、执行计划是否漂移、资源消耗变化
- 第79期 Oracle Buffer Busy Waits 等待事件 P3 参数详解
- 第78期 Oracle Buffer Busy Waits等待事件深入解读
- 第77期 ogg实现REPLICAT进程FILTER数据过滤
- 第76期 明明Oracle表LCADDRESS列定义VARCHAR2(80)ORA-12899报错值太大
- 第75期 ORA-27104: system-defined limits for shared memory was misconfigured
