Statspack报告了大量的执行次数，高于V$sql的总数

Question

我一直在调查我们生产系统中的一些性能问题。其中一段SQL具有非常高的执行计数，再加上不出色的性能，每节点每秒的20+次数达到峰值，执行时间为1秒。这与我在V$SQL中看到的全部执行/获取不一致，也不符合应用程序的预期行为。

一些信息

• 我们有一个有限的性能工具包，这些数据来自长达一小时的statspack快照。我们正在运行标准版本，所以不会有问题。
• 它运行在一个2节点11g的RAC安装上。
• 从昨天的数据来看，在9个小时内，每个节点执行的次数超过50万次。V$SQL向我展示了8天前第一次加载时的5万次执行。
• 当我直接查询statspack表时，我得到了匹配的数据，而不是一个不可靠的SPREPORT。
• 每小时执行的次数非常多，我们每天得到1到2次，是每个节点平均执行次数的10-20倍。每个节点的时间不同。从应用程序的行为来看，通常的数字听起来有点高，但可以接受。

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

也许statspack行为不当，但为什么只是周期性的呢？会不会是RAC的问题(我对RAC完全陌生)？

对原因或进一步的故障排除提示有什么建议吗？

Answer 1

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

请记住，由于几个原因，数据可能会在GV$SQL之外老化。如果有人运行alter system flush shared_pool;，大部分数据将被删除。如果由于统计信息的变化而使游标失效，则值可能消失。如果它们老化，值可能会消失，这可能是因为共享池太小，或者还有其他大量的活动。

我没有使用标准版或statspack的经验。但是，您可能希望查看像奥萨什这样的开源选项。

Answer 2

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

Statspack和我使用的查询(自己的错误，只是从博客文章中删除了一些东西)似乎都只检查快照值之间的差异。所以当这个数字下降了50,000，它报告说是50,000人被处决。

这听起来很愚蠢，但这是唯一有意义的事情。