点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)我们在ECC系统中遇到间歇性的性...
点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)我们在ECC系统中遇到间歇性的性...
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
我们在ECC系统中遇到间歇性的性能问题,并且发现I/O响应时间偶尔会很高。 特别是,我们在分析的会话中发现了较高的"直接路径读取"。
一个用户报告在事务MIRO中滚动时遇到问题,因此我们在ST12中执行了跟踪:
滚动一页平均大约需要30秒。 上面是那个时期的踪迹。
DB对RBKP执行了FTS:
行数:
没什么大不了的,对吧?
我确定了Oracle会话并提取了ASH数据。 较差的响应时间似乎与等待事件"直接路径读取"有关。 我用" Time Waited"(根据对象RBKP过滤)针对等待事件绘制了会话:
由此(对我而言)显然存在I/O瓶颈。 但是,为什么优化程序选择"直接路径读取"来检索此数据? 了解与这些事件相关的ASH统计信息的可靠性也将是一件好事吗?
谢谢
托尼
(30.6 kB)
托尼,你好
嗯...听起来我很熟悉????
>但是,为什么优化器选择"直接路径读取"来检索此数据?
在这种情况下,它不是优化程序-它是运行时引擎。 为什么这样做呢? 因为您的表大于" _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
一周热门 更多>