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

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

一些信息

• 我们的性能工具包有限，这些数据来自长达一小时的statspack快照。我们正在运行标准版，因此没有AWR
• 它在2节点11g RAC安装上运行
• 查看昨天的数据，我看到在9小时内每个节点执行超过500000次。V$SQL向我展示了8天前首次加载时约50000次执行
• 当我直接查询statspack表时，我会得到匹配的数据，而不是一个不可靠的存储报告
• 每小时的执行率很高，我们每天得到1到2次，是每个节点平均值的10-20倍。每个节点的时间不同。通常的数字听起来与应用程序的预期行为有些出入，但可以接受

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

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

---

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

使用

GV$SQL

而不是

V$SQL

查看所有节点的结果

请记住，由于多种原因，数据可能会过期

GV$SQL

。如果有人运行

alter system flush shared_pool，大部分数据将被删除。如果游标因统计信息更改而无效，则值可能会消失。如果值过期，它们可能会消失，这可能是因为共享池太小或存在其他大量活动

我没有使用标准版或statspack的经验。但您可能需要研究一个开源选项，如。
好的，我的日志记录和Jon的建议似乎已经（大部分）解释了这一点。
我们在共享池中有多个查询版本（我不完全确定为什么，或者是什么导致了失效）。当活动版本增加时，这些版本的执行计数保持静态。我可以在2分钟的快照中看到这种情况。
在某个时候，这些版本确实过时了，所以执行/解析的总量突然下降

Statspack和我使用的查询（Own fault，刚刚从博客文章中删除了一些内容）似乎都只检查快照值之间的差异。因此，当数量下降50000时，它报告为50000次处决

这似乎很愚蠢，但这是唯一有意义的事情。
是的，对不起-是指gv$sql！据我所知，它还没有过时，SQL一直在运行，除了我的团队之外，没有人应该有权运行刷新（我们没有！）Orasah是一个好主意，我们一直在研究这一点（以及ASBO），它可能会帮助我找到它。不过，我需要在投入使用之前检查代码（我确信这很好，但是在生产系统中运行其他人安装的SYS，并带有敏感数据，这让我很紧张）。不过，我会做一个快速而肮脏的日志记录，只需将特定SQL的统计数据快照到我自己的表中即可，