光标:引脚 S 在 11g 中等待 X

Sre*_*ree 3 oracle oracle-11g

这是我们数据库中排名前 5 的等待事件之一,尽管等待的次数不多,但我们将其视为潜在威胁,我们希望找到根本原因和解决方案。任何建议将不胜感激..

DB 版本:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64 位生产

AWR:

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                            3,887          95.0
db file sequential read             207,505         125      1    3.1 User I/O
direct path read                     33,793          69      2    1.7 User I/O
cursor: pin S wait on X                   5          43   8650    1.1 Concurrenc
db file scattered read               34,229          39      1     .9 User I/O
Run Code Online (Sandbox Code Playgroud)

Jus*_*ave 5

为什么发生 5 次的等待事件占数据库等待时间的 1.1%,您将其视为潜在威胁?是否有一些额外的信息让您相信这是一种威胁?显然,某些事情必须在您的前 5 个等待事件中。此事件是否一直是最重要的等待事件之一?或者它只是出现在一个 AWR 上?

当一个会话试图固定一个游标而另一个会话正在解析它时,通常会发生特定的等待。潜在地,95% 的 CPU 相关等待事件中的一些可能是解析的结果(尽管您想查看 AWR 中其他地方的硬解析的数量)。如果你有一个 OLTP 系统,你真的应该只在重启后立即做任何数量的硬解析——其他的一切都应该使用准备好的语句,最多做一个软解析。如果系统中某处有动态 SQL,删除它可能会有所帮助,尽管它也可能是节省几秒钟的相当激烈的步骤。