ODC执行sql一百毫秒但是java程序中运行sql代码要几分钟，需要收集统计信息后才能恢复正常

OceanBase 技术问题
#1

ODC执行sql一百毫秒但是java程序中运行sql代码要几分钟，需要收集统计信息后才能恢复正常。数量级的话，数据库大概40万条数据，每日会增加2000条。sql 如下：SELECT COUNT(DISTINCT (cust_id)) AS cust_count, t2.cluster_id, t2.locate_address, t2.latitude, t2.longitude, t2.city, t2.district, t2.township FROM cs_vds_clock_in_data t1 JOIN cs_vds_clock_in_cluster t2 ON t1.cluster_id = t2.cluster_id LEFT JOIN edm_base.vw_empe_prvg_gljsc gljsc ON t1.emp_inst_id = gljsc.prvg_inst_id AND gljsc.EMPE_NO = WHERE t2.city = AND (gljsc.empe_no <> ‘null’ OR t1.attendee_empeid = ) GROUP BY t1.cluster_id;

#3

如果经常需要手动收集统计信息，可以查看一下是否开启自动合并参数major_freeze_duty_time

#4

开启了每日自动收集，但是实际上数据变动量比较小应该不会触发自动收集；ODC执行sql正常，代码调用会超时。数量级的话，数据库大概40万条数据，每日会增加2000条。sql 如下：SELECT COUNT(DISTINCT (cust_id)) AS cust_count, t2.cluster_id, t2.locate_address, t2.latitude, t2.longitude, t2.city, t2.district, t2.township FROM cs_vds_clock_in_data t1 JOIN cs_vds_clock_in_cluster t2 ON t1.cluster_id = t2.cluster_id LEFT JOIN edm_base.vw_empe_prvg_gljsc gljsc ON t1.emp_inst_id = gljsc.prvg_inst_id AND gljsc.EMPE_NO = WHERE t2.city = AND (gljsc.empe_no <> ‘null’ OR t1.attendee_empeid = ) GROUP BY t1.cluster_id;

#5

可以告知下出现这种问题和什么因素有关吗？

#6

问题看起来出在 代码里。一个看代码用的 驱动，换驱动试试。
另外，你可以用 dbeaver 连接 ob 测试看看。dbeaver 本质也是一个 java程序，也需要jdbc 连接 db。当然 odc 实际上也是java 程序。 为了进一步验证这个是不是问题，你用 dbeaver 也试试

#7

您好，我在执行完数据统计后代码中运行sql就恢复正常了，大概数据库新增1.6万条数据后，又出现了上述问题；您说的驱动 我看官网实例给的就是mysql-connector-java以及jdbc，您建议换成哪个驱动试试？

#8

如果是这个特征（ob统计信息收集后业务sql也恢复正常了），那跟驱动无关，大概率就是 sql 性能方面的原因。统计信息收集后 sql 性能好。
再下次出现的时候，先看看sql 的执行计划。抓业务sql，看执行计划。跟 正常期间的执行计划进行对比。

1 个赞
#9

感谢您。您说的这个sql性能是指的sql本身有待优化的空间还是OB优化sql执行存在问题，有一个比较困惑的点是ODC执行sql始终是正常的，只是程序执行存在问题需要手动收集统计信息，这里面有哪些可能原因？

#10

分析性能问题需要数据，避免盲目猜测。现象背后都有对应的"数据”。
特别是 odc，功能很强大，每执行一个 sql 都能看对应的实际执行计划和时间耗时分布（看看odc文档）。
至于业务sql 的快慢，就需要你到 审计视图 ob_sql_audit 里去找到业务sql，查看对应的执行计划。

#11

可以参考下面实践方法分析看看：

#12

感谢，我参考绑定计划 sql加hint试下

#13

你好，目前该问题还存在么。可以使用obdiag进行sql性能分析采集
SQL性能问题, 此处env中的trace_id对应gv$ob_sql_audit的trace_id
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”

#14

目前已经确定是统计信息的问题，我直接绑定为hash join执行，有些情况下不是最优计划，但不会出现超时的情况。很纳闷为什么统计信息不能自动更新，可能是什么问题呢？