托尼，你好

嗯...听起来我很熟悉????

>但是，为什么优化器选择"直接路径读取"来检索此数据？

在这种情况下，它不是优化程序-它是运行时引擎。 为什么这样做呢？ 因为您的表大于" _small_table_threshold"。 可以在以下位置找到有关统计信息和对象驱动方法的运行时引擎中各种更改的完整说明和注释：针对全表扫描的优化程序驱动的直接路径读取决策（_direct_read_decision_statistics_driven）

>知道与这些事件相关的ASH统计信息的可靠性还好吗？

如前所述，ASH不是此处的正确信息来源????

您不知道每个等待事件（=请求）试图检索多少个块，以及操作系统为每个调用传递了多少个块（以及以哪种方式）。 1秒的8k可能很糟糕，1秒的1 MB也许还不错。 您需要将Oracle I/O请求与OS调用关联（例如Solaris上的pread-不太确定HP-UX上的相应OS调用）并在那里进行交叉检查。 错误的I/O响应时间不一定是由I/O子系统引起的。 仅举例来说-我在 Solaris/ZFS 和 AIX/JFS2 前一段时间。

>没什么大不了的，对吧？

取决于LHWM和HHWM（假设您正在使用ASSM），而不取决于行数。

星期四见you

致谢

Stefan

嗨，Stefan，

很高兴知道-谢谢。 ????

>通过运行MIRO或在整个系统范围内，此数据是否特定于相应的Oracle会话（交换SAP WP）？ 看来它是系统范围的。

是的，在整个系统范围内。 报告问题并在整个分析过程中定期刷新时，我会重置统计信息。

>例如，屏幕截图中完全没有CPU。

以下是等待时间（包括CPU）中最重要的事件：

干杯

Tony

它要进行FULL TABLE SCAN ..，所以它需要扫描整个表以获取记录。

检查表RBKP上是否有任何索引 对于where子句中的字段。如果不是，则创建它并检查它是否可以提高性能。 （还可以搜索SAP Notes ..可能对此有所帮助）

最诚挚的问候

ashish

感谢Ashish，但我想知道为什么会这样 进行"直接路径读取"，即为什么它绕过缓冲区缓存？

嗨，

我遇到了这个问题，可能在这篇文章中太迟了，但将来可能会帮助其他人。 我们有相同的情况，每当运行MIRO时，它都会直接读取路径，因此I/O很高。 有一个SAP注释和博客解释了这种情况，以及为什么一切都绕过数据库高速缓存直接进入直接路径读取。 同样，这仅在调用MRM_DUPLICATE_INVOICE_CHECK期间发生。

我们通过添加索引RBKP〜2解决了这种情况，SAP注释中也提到了这一点。 索引之后，与系统中的其他活动相比，现在的MIRO负载微不足道。 以前，它是数据库中最重要的I/O负载。

下面是具有SAP注释的参考博客，其中解释了为什么要进行全表扫描以及通过索引进行解析的情况。

https：//blogs .sap.com/2015/01/28/focus-is-on-miro-performance /

SAP注释 134660 –物流发票验证：性能（RBKP）

此致

珍娜