我一直在研究生产系统中的一些性能问题。一块SQL跳出了很高的执行计数，再加上非出色的性能，每个节点每秒20倍以上的峰值，执行时间约为1秒。这与我在v $ sql中看到的总执行/获取的总数或应用程序的预期行为相关。
一些信息
- 我们的性能工具包有限，此数据来自长时间的STATSPACK快照。我们正在运行标准版本，所以没有AWR。
- 它在2节点11G RAC安装上运行。
- 查看昨天的数字，我在9小时内看到每个节点的执行> 500,000。V $ SQL从8天前的第一个加载时间开始向我显示约50,000个执行。
- 直接查询Statspack表，而不是狡猾的spreport时，我会得到匹配的数据。
- 每小时执行是尖峰，我们每天获得1或2个，是每个节点平均值的10-20倍。每个节点的时间不同。通常的数字听起来有点高于该应用程序的表现，但可以接受。
开发人员经理坚持认为该应用程序不能这样表现，这听起来很合理。但是，是什么导致报告中的不匹配？
Statspack可能是行为不端的，但是为什么要定期呢？可能是RAC问题(我是RAC的新手(吗？
关于原因或进一步故障排除提示的任何建议？
使用GV$SQL而不是V$SQL查看所有节点的结果。
请记住，出于多种原因，数据可以老化GV$SQL。如果某人运行alter system flush shared_pool;，将删除大多数数据。如果由于统计数据的变化而使光标无效，则值可能会消失。如果值年龄，则可能是因为共享池太小或其他大量活动。
我没有标准版或Statspack的经验。但是您可能需要查看一个开源选项，例如Orasash。
好吧，我的记录，乔恩的建议似乎已经解释了这一点。我们在共享池中有多个版本的查询(我不确定原因，或什么原因导致了无效(。这些版本的执行计数在活动版本增加时保持静态。我可以看到这在我2分钟的快照中发生。在某个时候，这些版本确实会衰老，因此总执行/解析突然下降。
statspack，以及我正在使用的查询(自己的错误，仅从博客文章中抬起一些东西(似乎只检查了快照值之间的差异。因此，当计数下降50,000时 - 将其报告为50,000的执行。
看起来很愚蠢，但唯一有意义的是。