执行计划突变排查

OceanBase 技术问题
#1

测试环境的某条SQL在周五的时候出现执行计划突变，看算子是本来走hash join的地方变成了NL join，业务那边反馈慢了好多，手动绑定之后才正常。
现在就是想排查下当时为什么会重新生成执行计划，各位大佬知道在日志中用什么关键字来搜索自动淘汰和手动淘汰以及什么操作会导致执行计划重新生成吗
用grep ‘T1028’ observer.log* | grep “plan cache” ｜ grep “PlanCacheEvi” 没有相关信息

image
image1920×1190 84.2 KB

image
image1920×1136 72.1 KB

@论坛小助手

1 个赞
#3

根据文档库中的信息，执行计划突变通常是由于以下几个原因导致的：

  1. SQL 中涉及表的 Schema 变更：例如添加索引、删除或增加列等，这会导致 SQL 在计划缓存中所对应的执行计划被刷新。
  2. SQL 中涉及重新收集表的统计信息：这同样会导致 SQL 在计划缓存中所对应的执行计划被刷新。
  3. 数据分布变化：如果数据分布发生变化，原有的执行计划可能不再适用，导致性能下降。
  4. SQL 硬解析阶段入参的数据分布属于小概率场景：这可能导致优化器选择了错误的执行路径。

排查步骤

  1. 检查表的 Schema 变更：

    • 查看表的 DDL 历史记录，确认是否有在出现问题前后进行了表结构的变更。
    • 使用以下 SQL 查询表的 DDL 历史记录：
      SELECT * FROM __all_ddl_operation WHERE tenant_id = <your_tenant_id> AND gmt_create BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

  2. 检查统计信息的收集：

    • 查看统计信息的收集历史记录，确认是否有在出现问题前后进行了统计信息的收集。
    • 使用以下 SQL 查询统计信息的收集历史记录：
      SELECT * FROM __all_virtual_table_stat WHERE tenant_id = <your_tenant_id> AND gmt_modified BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

  3. 检查数据分布变化：

    • 查看表的数据量变化，确认是否有在出现问题前后数据量发生了显著变化。
    • 使用以下 SQL 查询表的数据量变化：
      SELECT COUNT(*) FROM <your_table> WHERE <your_conditions>;

  4. 检查 SQL 硬解析阶段入参的数据分布：

    • 查看 SQL 的执行计划历史记录，确认是否有在出现问题前后执行计划发生了变化。
    • 使用以下 SQL 查询 SQL 的执行计划历史记录：
      SELECT * FROM gv$sql_audit WHERE sql_id = '<your_sql_id>' AND gmt_create BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

日志关键字

  • 自动淘汰：可以使用关键字 PlanCacheEvi 来搜索自动淘汰的执行计划。
  • 手动淘汰：可以使用关键字 PlanCacheInvalidate 来搜索手动淘汰的执行计划。

示例命令

grep 'PlanCacheEvi' observer.log* | grep "2024-12-13"
grep 'PlanCacheInvalidate' observer.log* | grep "2024-12-13"

综合分析

根据您提供的图片和日志信息，可以进一步确认以下几点：

  1. 执行计划的变化时间：从图片中可以看到，执行计划的变化时间是 2024 年 12 月 13 日 15:23:37 和 15:54:51。
  2. 执行计划的变化：从图片中可以看到，执行计划从 HASH JOIN 变成了 NESTED LOOP JOIN。

结合以上信息，您可以重点检查在 2024 年 12 月 13 日 15:23:37 和 15:54:51 前后是否有表的 Schema 变更、统计信息的收集或数据分布的变化。

希望这些信息能帮助您排查执行计划突变的原因。如果需要进一步的帮助，请联系 OceanBase 的人工答疑。

具体信息可参考以下文档:

  1. 常见的业务问题
  2. 诊断实践：使用 SQL_PLAN_MONITOR 分析性能问题
  3. 定位和分析慢查询（一）
  4. 分析慢 SQL 查询
  5. SQL 调优典型场景和案例
  6. 执行计划缓存
  7. 连接次序
  8. OceanBase 术语
1 个赞
#4

小助手还是有点东西。。顺便在补充下
1、__all_ddl_operation 也查过，没有表结构的变更
2、查过 DBA_TAB_STATS_HISTORY 表，统计信息在该时间点没有被收集

1 个赞
#5

感谢您的补充信息。既然已经确认没有表结构的变更和统计信息的收集，我们可以进一步排查其他可能导致执行计划突变的原因。

其他可能的原因

  1. 参数变更：某些系统参数的变更可能会影响执行计划的选择。
  2. 数据分布变化：虽然统计信息没有变化，但实际数据的分布可能发生了变化。
  3. SQL 重解析：某些情况下，SQL 会被重新解析，导致执行计划的变化。
  4. 系统负载：系统负载的变化也可能影响执行计划的选择。

排查步骤

  1. 检查系统参数变更：

    • 查看系统参数的变更历史记录，确认是否有在出现问题前后进行了参数的变更。
    • 使用以下 SQL 查询系统参数的变更历史记录：
      SELECT * FROM __all_virtual_sys_parameter_history WHERE gmt_modified BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

  2. 检查数据分布变化：

    • 查看表的数据量变化，确认是否有在出现问题前后数据量发生了显著变化。
    • 使用以下 SQL 查询表的数据量变化：
      SELECT COUNT(*) FROM <your_table> WHERE <your_conditions>;
    • 检查表中特定列的数据分布变化，特别是参与连接的列。
      SELECT column_name, COUNT(*), MIN(column_name), MAX(column_name) FROM <your_table> GROUP BY column_name;

  3. 检查 SQL 重解析：

    • 查看 SQL 的执行计划历史记录，确认是否有在出现问题前后执行计划发生了变化。
    • 使用以下 SQL 查询 SQL 的执行计划历史记录：
      SELECT * FROM gv$sql_audit WHERE sql_id = '<your_sql_id>' AND gmt_create BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

  4. 检查系统负载：

    • 查看系统负载的变化，确认是否有在出现问题前后系统负载发生了显著变化。
    • 使用以下 SQL 查询系统负载：
      SELECT * FROM __all_virtual_server_stat WHERE gmt_modified BETWEEN '2024-12-12 00:00:00' AND '2024-12-13 23:59:59';

日志关键字

  • 自动淘汰：可以使用关键字 PlanCacheEvi 来搜索自动淘汰的执行计划。
  • 手动淘汰：可以使用关键字 PlanCacheInvalidate 来搜索手动淘汰的执行计划。

示例命令

grep 'PlanCacheEvi' observer.log* | grep "2024-12-13"
grep 'PlanCacheInvalidate' observer.log* | grep "2024-12-13"

综合分析

根据您提供的信息，可以进一步确认以下几点：

  1. 执行计划的变化时间：从图片中可以看到，执行计划的变化时间是 2024 年 12 月 13 日 15:23:37 和 15:54:51。
  2. 执行计划的变化：从图片中可以看到，执行计划从 HASH JOIN 变成了 NESTED LOOP JOIN。

结合以上信息，您可以重点检查在 2024 年 12 月 13 日 15:23:37 和 15:54:51 前后是否有系统参数的变更、数据分布的变化或系统负载的变化。

希望这些信息能帮助您排查执行计划突变的原因。如果需要进一步的帮助，请联系 OceanBase 的人工答疑。

具体信息可参考以下文档:

  1. 常见的业务问题
  2. 诊断实践：使用 SQL_PLAN_MONITOR 分析性能问题
  3. 定位和分析慢查询（一）
  4. 分析慢 SQL 查询
  5. SQL 调优典型场景和案例
  6. 执行计划缓存
  7. 连接次序
  8. OceanBase 术语

具体信息可参考以下文档:

  1. oceanbase.DBA_OB_TABLE_STAT_STALE_INFO
  2. oceanbase.DBA_OB_TABLEGROUP_PARTITIONS
  3. oceanbase.DBA_OB_TABLEGROUP_SUBPARTITIONS
  4. 取消副本任务
  5. DELETE_SCHEMA_STATS
  6. 集群管理 FAQ
  7. oceanbase.DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

1 个赞
#6

OceanBase 社区已接收您的帖子，正在跟进中。

2 个赞
#8

1、查看日志信息

1894×554 343 KB

查看日志信息是语句执行时，统计数据已过时计划清除和计划缓存键已被删除了没有在之前的plan is expired的信息。

2、查询计划缓存视图

select * from GV$OB_PLAN_CACHE_PLAN_STAT where sql_id=‘DFCD31FF82A35AE4976830B8CC0786DE’ and PLAN_ID=‘698750’;

select * from GV$OB_PLAN_CACHE_PLAN_EXPLAIN where PLAN_ID=‘698750’;

–结果都为空

2、select * from oceanbase.DBA_OB_TABLE_STAT_STALE_INFO;

1327×183 25 KB

查询信息发现last_analyzed_time已经更新

总结原因：从日志的提供和视图查看，信息不足，目前没有办法在分析之前的突变问题。

2 个赞