【问题标题】:The query time of a view increases after having fetched the last page from a view in Oracle PL/SQL从 Oracle PL/SQL 中的视图获取最后一页后,视图的查询时间会增加
【发布时间】:2013-09-05 16:09:12
【问题描述】:

我在 Oracle Database 11g 上使用 Oracle PL/SQL Developer。我最近写了一个带有一些奇怪行为的视图。当我在不获取查询的最后一页下运行简单查询时,查询时间约为 0.5 秒(缓存时为 0.2)。

select * from covenant.v_status_covenant_tuning where bankkode = '4210';

但是,如果我在 PL/SQL Developer 中获取最后一页,或者如果我从 Java 代码运行查询(即我运行一个检索所有行的查询),视图会发生某些事情并且查询时间会增加到大约20-30 秒。

在我重新编译之前,视图无法再次正常工作。解释计划前后完全一样。分析所有索引和表。我不知道它是否相关,但该视图使用了一些分析表达式,例如 rank() over (partition by .....)、lag()、lead() 等等。

由于我是新来的,所以我无法发布解释计划的图片(需要 10 的声誉),但总的来说优化器有效地使用了索引,并且由于分析功能,它做了一些分类。

【问题讨论】:

  • 您可以查看 v$sqlstats(和其他)中的存储的计划。也许甲骨文创建了一个具有不同执行计划的新子游标。顺便说一句:执行计划最好发布为(格式化)文本,而不是图片。

标签: performance oracle plsql oracle11g


【解决方案1】:

如果计划涉及某种全盘扫描,则在读取表中的最后一个块之前,查询不会完成。

想象一个表,它在表的前几个块中有很多匹配的行,而在其余部分没有匹配的行。如果要检查大量块,查询可能会很快返回前几页结果,因为它会在表的前几个块中找到它们。但是在它可以将最终的“没有更多结果”返回给客户端之前,它必须检查表的每个最后一个块 - 它不知道表的最后一个块中是否可能还有一个结果,所以它有等到它读完最后一个块。

如果您需要更多帮助,请发布您的查询计划。

【讨论】:

  • 只是为了澄清,问题不是从视图中加载所有行比仅仅加载第一页需要更长的时间,而是当你这样做时——整个视图会以某种方式发生变化。第一次获取所有行时,视图大约需要 4 秒,第二次大约需要 25 秒。因此,视图、优化器或其他东西会以某种方式发生变化,从而使性能变得更差。
  • 我认为您需要对会话进行跟踪(一个用于第一次执行需要 4 秒,另一个用于需要 25 秒)并查看正在执行的查询以及计划是什么正在使用。正如@a_horse 所说,它可能是自适应游标共享导致优化器选择不同的计划。这是假设两个会话实际上都在请求整个数据集。
猜你喜欢
  • 2021-08-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-10-11
  • 1970-01-01
  • 2012-06-12
  • 1970-01-01
  • 2013-07-04
相关资源
最近更新 更多