问题标签 [cbo]

我正在使用 HDP 2.6.2 和配置单元。

我有一种情况，我正在根据一个列从一个大表中更新一个分区表，而查询却表现不佳，我不明白为什么。下面的插入语句是一个示例

insert into partitioned_table partition(dt_month) select * from large_table where incremental_string_col > (select last_incremental_col from temp_tab)

在这里，我假设 where 子句中的子查询执行一次并缓存结果，或者 CBO 将基本上只有一行的整个 temp_tab 表发送到所有节点，但它似乎并没有像放置字符串那样工作作为文字的价值！

我可以明确声明需要在 hive 中缓存表吗？我可以明确声明一个查询只需要执行一次并缓存结果吗？我在这里想念什么？

我理解字符串的列不是最好的情况，但我无能为力。

任何帮助将非常感激！！

我最近将一些“Date”列转换为“Timestamp(6) with local time zone”，以便在不修改现有企业应用程序的情况下使用 oracle 本地化功能。

一切都按预期工作：客户端 sessiontimezone 对数据的“小时”有影响。

我的问题是 ORACLE 基于成本的优化器看起来不再理解我们使用的日期格式，并且计算出错误的基数。你能帮助我们吗？

要重现问题：

然后，为了简化理解，我将数据库 NLS 参数复制到我的会话中。

Test_1 没问题

Test_2 是 ko

Test_3 是 ko

我必须使用哪种格式才能在 CBO 上获得正确的基数？

PS：我使用的查询工具（Business Objects）无法在比较的右侧指定“to_date”或“cast”等功能，这就是我必须管理字符的原因。

假设我想加入 3 个表 A、B、C，内连接和 C 非常小。

而且我无法控制加入的顺序：

运行两者都显示 CASE1 比 CASE2 慢 30-40%。

所以问题是：如何利用 Spark 的 CBO 自动将 CASE1 转换为 CASE2 用于内存表或从 Spark 的 parquet 读取器加载的表？

我试过做：

但这会引发：

无需在 Hive 中保存表即可激活 CBO 的任何其他方式？

附件：

1. 即使使用 spark.conf.set("spark.sql.cbo.enabled", "true") 在 SparkWebUI 中也没有显示成本估算
2. 显示 CASE1.explain != CASE2.explain

CASE1.解释

CASE2.解释

我很难理解为什么当绑定变量是 OR 条件的一部分时 Oracle CBO 的行为方式。

我的环境

Oracle 12.2 优于 Red Hat Linux 7

暗示。我只是提供问题所在查询的简化

关键点

1. 我确实知道，如果我通过使用两个选择来更改 OR 表达式并且 UNION ALL 可以完美地工作。问题是我有很多条件以同样的方式完成，所以 UNION ALL 不是我的解决方案。
2. 该表具有使用 FOR ALL COLUMNS SIZE AUTO 和 ESTIMATE PERCENT 10% 计算的最新统计信息。
3. 就我而言，动态 SQL 不是解决方案，因为查询是通过第三方软件调用的，该软件使用 API Web 将结果转换为 JSON。
4. 我能够以现在需要 19 秒的方式使用按级别连接来改写正则表达式。在它需要40秒之前。
5. 该表只有 113K 条记录，没有索引。
6. 该查询有 20 个此类条件，所有条件均以相同的方式编写，因为通过 API 触发查询的 Web 应用程序中的屏幕允许用户使用任何参数组合或根本不使用任何参数组合。

如果我删除表达式NVL(:loanIds,'XX') = 'XX' OR，查询需要 0.01 秒。为什么这个带有 BIND 的 OR 表达式让优化器如此头痛？

- 更新 -

我要感谢@Alex Poole 的建议，并与他分享第三种选择（删除正则表达式）的魅力。不过，如果能理解其中的原因，那就太好了。你有我最诚挚的谢意。我用了一段时间，我从来没有遇到过这个问题。此外，使用建议regexp_like甚至比使用regexp_substrand的原始建议更好connect by level，但比根本不使用正则表达式的建议要慢得多

原始查询

新查询

一旦EXISTS内部谓词消失，查询就会像地狱一样快。

谢谢大家的意见 ！

我希望任何人都可以帮助我看看我是否可以改进这个查询：

环境：

• Oracle 数据库 12cR2
• Linux 红帽 7
• 具有 8 个 CPU 和 32GB RAM 的虚拟机
• 使用 AUTO SAMPLE 和 FOR ALL COLUMNS SIZE AUTO 方法计算的统计数据是最新的
• 优化器参数是 12.2 的默认参数

原始查询属于第三方软件。正如预期的那样，它正在使用cross join正在创建 HASH JOINS。原始查询和计划统计信息为：

在查看了计划之后，我试图通过创建以下两个索引来避免那些 TABLE FULL SCAN：

在此之后，查询得到改善，它正在INDEX FAST FULL SCAN所有涉及的表中访问，但仍然需要时间

我的最后一次尝试是尝试通过将其中的一些转换为（我可以）来重写cross joins查询inner joins。我得到了更好的时间，但计划看起来一样。我在服务器中以不同级别的负载运行了几次测试，即使计划看起来相同，我仍然在下面的查询中获得了更好的时间。

更新

根据要求，这里是原始查询的 SQL MONITOR 的详细信息

并监视我使用 JOIN / ON 语法更改的查询报告

正如您在监视器中看到的，两个查询都使用相同的 PLAN HASH VALUE，因此 CBO 对它们使用相同的计划，因为它们确实是相同的查询。尽管如此，我总是在使用 JOIN / ON 语法的查询中获得更好的时间，老实说我不明白为什么。

我的问题是是否有一种更简单的方法可以在考虑数量的情况下改进此查询。当计划和成本（包括访问路径和谓词信息）相同时，为什么使用 JOIN/ON 语法的查询在性能上表现更好，这将是很好的理解。

提前致谢。

我在 Oracle 12cR2（通过 Linux Red Hat 7）中发现了这个奇怪的行为，这个特殊的查询。在我看来这是一个错误，但我发布问题以防万一有人发现类似问题。

该查询是由 Java 应用程序触发的，但我已经能够在 sqlplus 中重现该问题。

提示：不要问我括号数量过多，我自己做的，它来自应用程序本身，所以我使用相同的sql文本是100％准确的。

查询 1

所以查询 1 返回 0 行。好吧，让我们更改select * fromfor 以获得表格的三列。

查询 2

这怎么可能？我不会失去理智吧？

作为一个测试环境，我确实刷新了缓冲区缓存和共享池，检查了是否有损坏，甚至弹回了数据库。到目前为止，什么都没有。

简短的总结，使用select * from给我 0 行，使用select field, field, field from给我正确的行数。

你认为这是一个错误还是我没有考虑的不同之处？

PS 添加 order by 也会更改返回的行数。

更新

移动表段并重建所有索引也没有解决任何问题。我什至尝试使用数据泵来导出模式、删除表空间、在不同的 ASM 磁盘中重建表空间并重新导入。没有效果。

所以，我很清楚这是 12.2 中的一个 BUG，但我找不到具体是哪一个。