A lots of library cache lock due to High Version Count
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: A lots of library cache lock due to High Version Count
近期某一个客户核心系统出现短暂hung，经过排查发现故障期间出现了大量的Library cache lock等待，如下：
| Event | Waits | Total Wait Time (sec) | Avg Wait | % DB time | Wait Class |
|---|---|---|---|---|---|
| library cache lock | 531,841 | 69.1K | 129.93ms | 36.6 | Concurrency |
| DB CPU | 29.2K | 15.5 | |||
| enq: TX – row lock contention | 29,871 | 22.8K | 764.04ms | 12.1 | Application |
| library cache: mutex X | 902,385 | 21.7K | 24.05ms | 11.5 | Concurrency |
| cursor: mutex S | 5,750,518 | 11.2K | 1.94ms | 5.9 | Concurrency |
| enq: US – contention | 312,220 | 7445.3 | 23.85ms | 3.9 | Other |
| cursor: mutex X | 547,300 | 5876.1 | 10.74ms | 3.1 | Concurrency |
| cursor: pin S wait on X | 169,218 | 4182.9 | 24.72ms | 2.2 | Concurrency |
| latch: ges resource hash list | 669,961 | 3806.3 | 5.68ms | 2.0 | Other |
| row cache lock | 532,689 | 3634.8 | 6.82ms | 1.9 | Concurrency |
通过等待事件分析发现等待主要集中在1个高频SQL上：
| Version Count | Executions | SQL Id | SQL Module | SQL Text |
|---|---|---|---|---|
| 1,110 | 8rsyjurdj8fy2 | update Lot set beforeProcessOp… |
通过脚本进一步检查发现该sql 这么高的version count，主要是因为bind mismatch，其中大部分cursor都是bind length upgrade。
对于该问题，Oracle提供了几种方式来解决该问题：
|
1 2 3 4 |
1、 event 10503 2、_cursor_features_enabled=1026 event="106001 trace name context forever, level 300" |
从Oracle 11.2.0.3版本开始便引入了 _cursor_obsolete_threshold.
然而最开始我们简单以为设置_cursor_obsolete_threshold 即可，最后发现由于SQL执行频率极高，每小时超过百万次，这会导致
cursor被频繁的标记为过期，最终产生大量硬解析。我们通过设置10503 event发现确实解决了SQL version count过高的问题。
但是客户业务侧确反馈出现了一些其他的问题，比如ORA-01483/ORA-01461等。
经过几天发现发现设置event 10503 可能触发19c的一些bug，最终建议客户将该event去掉，同时也删除_cursor_obsolete_threshold参数。
这里我们删除event 10503，并不代代表不设置，而是不要在数据库实例级别设置，改而在应用代码中进行session级别设置。
这样既可解决SQL version count问题，同时也可以解决应用反馈的报错问题。
Leave a Reply
You must be logged in to post a comment.