1

我一直在调查我们生产系统中的一些性能问题。一条 SQL 因执行计数非常高而跳出，再加上性能不佳，每个节点每秒达到 20 次以上的峰值，执行时间约为 1 秒。这与我在 V$SQL 中看到的总执行次数/获取次数或应用程序的预期行为不相符。

一些信息

  • 我们有一个性能有限的工具包，这些数据来自长达一小时的 statspack snaps。我们正在运行标准版，所以没有 AWR。
  • 它在 2 节点 11g RAC 安装上运行。
  • 查看昨天的数据，我发现在 9 小时内每个节点执行了 > 500,000 次。从 8 天前的第一次加载开始，V$SQL 向我展示了大约 50,000 次执行。
  • 当我直接查询 statspack 表时，我得到了匹配的数据，而不是一个狡猾的 SPREPORT。
  • 每小时的执行量非常高，我们每天执行 1 或 2 次，是每个节点平均值的 10-20 倍。每个节点的时间不同。通常的数字听起来比应用程序的行为方式有点高，但可以接受。

开发经理坚持认为应用程序不能这样运行，这听起来很合理。但是，什么可能导致报告中的不匹配？

statspack 可能行为不端，但为什么只是周期性地呢？可能是 RAC 问题（我对 RAC 完全陌生）？

有关原因或进一步故障排除提示的任何建议？

4

2 回答 2

1

好的，我的日志记录和 Jon 的建议似乎已经解释了这一点（大部分）。我们在共享池中有多个版本的查询（我不完全确定为什么，或者是什么导致了失效）。这些版本的执行计数保持不变，而活动版本增加。我可以在我的 2 分钟快照中看到这种情况。在某些时候，这些版本确实会过期，因此总执行/解析突然下降。

Statspack 和我使用的查询（自己的错误，刚刚从博客文章中提取了一些东西）似乎都只检查快照值之间的差异。因此，当计数减少 50,000 时 - 它会将其报告为 50,000 次处决。

这似乎很愚蠢，但却是唯一有意义的事情。

于 2018-04-26T13:01:41.383 回答
1

使用GV$SQL而不是V$SQL查看所有节点的结果。

请记住，数据老化可能有GV$SQL多种原因。如果有人运行，大部分数据将被删除alter system flush shared_pool;。如果游标因统计信息更改而失效，则值可能会消失。如果它们过期，值可能会消失，可能是因为共享池太小或存在其他大量活动。

我没有使用标准版或 statspack 的经验。但是您可能想研究一个开源选项，例如orasash。

于 2018-04-24T23:47:49.470 回答