Oracle错误解释

发布于 2024-10-18 00:57:13 字数 199 浏览 3 评论 0原文

偶然间我发现我有一个 oracle-db 的性能监控工具,所以我尝试查找一些性能问题。现在该软件向我发出以下警报:

  • SQL 库缓存未命中率(大约 80%)
  • 锁存等待是非空闲等待时间(4-5% 之间)
  • 数据文件随机读取平均时间为 200ms

有人能解释一下那是什么吗对数据库和我意味着什么?

Just by accident I found out that I have an performance monitoring tool for oracle-db so I tried to look out for some performance issues. Now the Software gives me the following alerts:

  • SQL library cache miss rate (somewhere arround 80%)
  • Latch waits are (somewhere between 4-5%) of non-idle wait time
  • Datafile random read avg time is 200ms

Can someone explain me what that means to the database and me?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

疧_╮線 2024-10-25 00:57:13

SQL Library Cache 未命中率是指当您执行查询时,大部分时间 (80%) 还没有在缓存中,即最近没有见过。因此,80% 的查询需要从头开始评估和编译。这可能表明您没有使用绑定变量(因此每个 SQL 都略有不同)。

SQL Library Cache miss rate means that when you execute a query it is most of the time (80%) not already in the cache, i.e. has not been seen before recently. As a result, 80% of the queries need to be evaluated and compiled from scratch. This probably indicates that you are not using bind variables (so that every single SQL is a little different).

翻了热茶 2024-10-25 00:57:13

如果您的用户没有抱怨,那么您就没有问题。如果他们抱怨,您首先要检查共享池的大小和设置,例如 open_cursors、session_cached_cursors。正在进行多少解析?解析是真正的可伸缩性杀手。许多应用程序生成经常重复的 SQL,在查询中使用文字而不是绑定变量。您需要知道您的应用程序如何工作。

你们有什么版本的数据库?

另外,平均随机访问时间为 200 毫秒……通常这并不被认为是健康的。任何超过 10 毫秒的时间都很高,不会给您带来愉快的用户体验。

应用程序正在做什么,大量扫描,大量更新,大量提交?
性能问题似乎总是会引发更多问题……

致以诚挚的问候,
罗纳德.

if your users are not complaining than you have no problem. If they are complaining, your first thing to check if the shared_pool sizing and settings like open_cursors, session_cached_cursors. How much parsing is going on? Parsing is a real scalability killer. Lot's of applications generate sql that is repeated very often, with literals in the query instead of bind variables. You need to know how your app works.

What version databases do you have?

Also, the average random access time of 200ms ..... normally that is not considered healthy. Anything above 10ms is high and not helping your happy user experience.

What is the app doing, large scans, lots of updates, many commits?
Performance questions always seem to raise more questions ...

best regards,
Ronald.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文