这是我们数据库中排名前 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)
为什么发生 5 次的等待事件占数据库等待时间的 1.1%,您将其视为潜在威胁?是否有一些额外的信息让您相信这是一种威胁?显然,某些事情必须在您的前 5 个等待事件中。此事件是否一直是最重要的等待事件之一?或者它只是出现在一个 AWR 上?
当一个会话试图固定一个游标而另一个会话正在解析它时,通常会发生特定的等待。潜在地,95% 的 CPU 相关等待事件中的一些可能是解析的结果(尽管您想查看 AWR 中其他地方的硬解析的数量)。如果你有一个 OLTP 系统,你真的应该只在重启后立即做任何数量的硬解析——其他的一切都应该使用准备好的语句,最多做一个软解析。如果系统中某处有动态 SQL,删除它可能会有所帮助,尽管它也可能是节省几秒钟的相当激烈的步骤。
| 归档时间: |
|
| 查看次数: |
5179 次 |
| 最近记录: |