【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.2
【问题描述】一张单表，数据量600万，执行一次update全表更新执行计划预估时间70多秒，但是实际执行时间5分钟多，请问可能的原因是什么？
update执行效率慢信息收集.txt (596.3 KB)
在传统的Oracle数据库上执行相同的语句，表结构也是一样的情况下，执行时间只有100秒左右
可能和压缩和副本数量有关系，oracle数据库应该是没有副本和压缩
压缩我去掉了，副本3
我当前的方向是两种产品的数据存储的结构不一样所导致的。
OB是分布式的，副本同步的时间就比oracle要多出来。两个数据库的存储引擎不一样，所以没法对比。
你这个update慢，加并行/*+ parallel(8) */是一个优化手段。
表是单分区，sql是本地执行计划，sql执行最多的时间是execute time，从sstable中read数据，比mem中多，如果不加并行，没有其他明显的优化手段了
OB 里更新大表还要看租户内存资源。资源不够的情况下更新过程中会有转储。
此外，一个 UPDATE 更新大表的做法并不推荐。想要快，可以写存储过程，用游标循环批量更新。
我尝试加并行了，但是效果不理想，执行时间有时还会增加，cpu核数27C
这个是一个可行的方法，只是我也还是有疑问，为什么执行计划中预估的时间和实际执行时间差距那么大，且从执行计划中的算子看就是一个全表扫描，执行计划比较单一
假设你看的是 explain 生成的执行计划，这是一个解析的执行计划，并不会实际执行。这里面 显示 的 TIME 信息（以前版本里叫 COST），都是 OB 内核根据内部一些规则计算的，是个预估值。
既然是预估值跟实际有出入就很正常了。因为 SQL 实际执行时影响性能的因素有很多。比如说 锁冲突导致的等待、CPU 负载、可用的内部worker、数据是否在内存中、增量内存是否会发生转储、磁盘IO性能如何、网络流量如何。这些信息 explain 期间是不可能精确预测。
这个 TIME 信息会引起一些误解。建议不要太在意其绝对值。看相对值还有一些意义。比如说同一个环境下同一个 sql 通过调整 hint观察两个执行计划下的time 信息，也许可以解释为什么 SQL 引擎默认为什么选择其中一个执行计划而不是另一个。
OB 跟 ORACLE 比 性能优势，不会去比某个大表全表查询或更新。比的是整体的能力。OLTP的吞吐，再叠加 OLAP 的大查询等等。 也不是绝对的有优势，跟实际业务场景、SQL、服务器配置、参数配置多方面因素有关。
0 |UPDATE | |9027962 |79274335 | |
| |1 |└─TABLE FULL SCAN|TEST01|9027962 |10974150
主要耗时实在更新上，评估的行数是902万行，按实际的行数来算，实际的时间差不多更长吧
实际是600万，我考虑过buffer表那种，所以在没有会话的窗口期做了合并和统计信息采集，然后再次测试效果一样
真实的执行计划消耗，只能通过v$ob_sql_audit视图查看吗
实际的执行信息（包括执行时间、等待事件、读取或修改行数等）看 GV$OB_SQL_AUDIT 。
实际的执行计划看 GV$OB_PLAN_CACHE_PLAN_EXPLAIN 。需要先拿到对用的 tenant_id、svr_ip、port和 plan_id。
示例：
SELECT plan_depth, plan_line_id,operator,name,ROWS,cost
FROM `GV$OB_PLAN_CACHE_PLAN_EXPLAIN`
WHERE svr_ip='172.16.128.161' AND svr_port=2882 AND plan_id=1500 AND tenant_id=1002
;
注意：实际执行计划中的 COST 并不等于实际执行时间。 它只是 SQL在执行之前生成的执行计划，依然是 “预估”。
你可以把单分区，拆成多分区表，比如hash，然后加并行。并行的值 跟 分区数是倍数关系。并行的值从低到高，多测几次