解释Oracle中的计划和计算缓存命中率答案

【问题标题】：Explain plan and computing cache hit ratio in Oracle解释Oracle中的计划和计算缓存命中率
【发布时间】：2017-04-23 14:24:28
【问题描述】：

假设 oracle db 有 40M 字节的缓存内存。我是数据库的唯一用户，我想了解如何执行查询以计算查询的缓存命中率。

假设我们有这个查询：

SELECT column1, count(*) 
FROM table1
GROUP BY column1
ORDER BY column1 desc

假设table1小于40M大小，现在解释计划说：

TABLE ACESS(FULL) 的成本为 1330（I/O ？），SORT(GROUP BY) 的成本为 1340，SELECT STATEMENT 的成本也为 1340。

我有些看不懂，为什么 SORT 和 SELECT STATEMENT 各要花费 1340 I/O？

由于我们有一个大于表大小的缓存，当我们进行表访问时，我们将磁盘内容加载到缓存中，然后当我们想要排序和选择时，我们只需要检索缓存中的内容，所以在我的请注意，排序和选择的 I/O 应该为零。

另外，我如何计算该查询的缓存命中率？

【问题讨论】：

【解决方案1】：

成本是操作的预期时间，以该时间所需的单块读取的等效数量表示。

因此，在一个单块读取需要 0.5 毫秒的系统上执行 100 毫秒的操作将花费 200。

您描述的数字听起来像是累积的，因此 select 的 1340 包括 group by 的 1340，它本身包括 table 访问的 1330。因此 group by 成本为 10。

查询的缓存命中率取决于执行查询之前该表在 SGA 中的数量——如果没有，则 BCHR 将为 0%。如果全部都是，那么 BCHR 将是 100%。

请注意，作为系统调优工具，BCHR 已被广泛弃用，因为高 BCHR 和高效查询计划之间的相关性非常弱。事实上，您可以通过降低查询计划的效率来提高 BCHR。

【讨论】：

谢谢，但排序和选择不计入块读取？那么这将使缓存命中率达到 66.6%，或者是即时完成排序和选择，因此它们不算作 I/O？
不是——如果排序太大而无法在内存中执行（PGA，而不是 SGA），那么它会溢出到磁盘，但其中涉及的 i/o 对 BCHR 没有贡献（BCHR 不能很好地衡量系统效率的另一个原因）。