Statspack报告执行次数较多，高于V $ sql中的总数

Question

我一直在研究生产系统中的一些性能问题。一个SQL跳出来，因为它具有非常高的执行计数，再加上非常出色的性能，每个节点每秒钟超过20次，执行时间约为1秒。 这与我在V $ SQL中看到的总执行次数/提取次数或应用程序的预期行为无关。

一些信息

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

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

有可能statspack行为不端，但为什么只是定期？这可能是RAC问题（我对RAC来说是全新的）？

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

Answer 1

使用GV$SQL代替V$SQL查看所有节点的结果。

请注意，由于多种原因，数据可能会超出GV$SQL。如果有人运行alter system flush shared_pool;，大多数数据都会被删除。如果由于统计信息更改而使游标无效，则值可能会消失。如果它们老化，价值可能会消失，可能是因为共享池太小或者还有其他大量活动。

我没有标准版或statspack的经验。但您可能希望查看像orasash这样的开源选项。

Answer 2

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

Statspack，以及我正在使用的查询（自己的错，只是从博客文章中解除了一些内容）似乎只检查了快照值之间的差异。因此，当计数下降50,000时 - 它会将其报告为50,000次执行。

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