分区表insert很卡

[刘红伟]

【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】4.0
【问题描述】
从gj表查询数据后执行插入gjfq(分区表)，很卡。
不知道什么原因，麻烦老师帮分析下。
gj表600万
gjfq表400万，两个一级分区，每个对应12个二级分区，按照月份。

【附件】

[UNIQUE_KEY]

1 分区键是啥，是不是写的数据跨分区了
2 每次而且写的数据量是不是很大，看下 affected_rows

[和顺]

麻烦提供一下：
1、2张表的结构 show create table xxx \G
2、根据ocp上sql明细对应的traceid ，执行 select * from gv$ob_sql_audit where trace_id=‘xxx’ \G
3、在insert 时候，是否触发了写入限速(1002替换成我们实际的用户租户ID)
grep “T1002.*report write throttle info” observer.log

[刘红伟]

partition by range columns(year) subpartition by hash(eventmonth)
插入数量不固定，大概几万左右

[刘红伟]

gjAndgjfq.txt (5.2 KB)
2.这个查询项很多，需要关注哪个字段吗？执行时间都很长

3.租户id就是1002，未查询到

[坤易]

分布式执行计划。表上索引情况是什么样子的哪？

[刘红伟]

[和顺]

根据ocp上sql明细对应的traceid ，执行 select * from gv$ob_sql_audit where trace_id=‘xxx’ limit 1 \G

麻烦将完整输出贴一下。

[刘红伟]

sql.txt (3.6 KB)

[和顺]

上面提供的sql.txt里 QUERY_SQL: 对应的 字段是空，找一个对应我们该帖子中描述慢点sql看看。

[刘红伟]

根据ocp上面的TraceID查询到的，QUERY_SQL都是空的。
直接查询QUERY_SQL对应的like也没找到记录了。

[UNIQUE_KEY]

这里不要写limit 1， 分布式计划执行时，会有多个sql_audit

[刘红伟]

不加limit 1的话，也无法查询到了，不知道是不是超过保存的时间

[UNIQUE_KEY]

估计已经淘汰了，得重新执行，找到traceId 再查

[刘红伟]

好的，谢谢

[刘红伟]

sql.txt (7.1 KB)
老师，我们重新执行了下，麻烦您看下。
80万数据执行需要110s

[刘红伟]

sql.txt (7.1 KB)
80万数据执行110s完成。

[UNIQUE_KEY]

sql_audit 来看只需要600ms,110s 是从哪儿看到的

[刘红伟]

[UNIQUE_KEY]

得找个执行耗时很长的SQL的traceId 对应的sql_audit