【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1.8
【问题描述】zabbix基于0B进行升级时，有一步操作进行全表update，数据量约65W，更新时间耗时非常长且未能成功。
【复现路径】
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
5 个赞
推荐使用 obdiag 工具进行日志采集，以便我们确认问题所在。
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”
请将采集到的日志提供给我们，以便我们进一步分析。另外，为了更好地帮助您优化或解决问题，请您提供以下信息：
- 您的 OceanBase 集群配置（如硬件资源、集群规模等）是怎样的？
- 在执行全表更新操作之前，是否有对涉及的表进行过索引优化或者分区设置？
- 更新语句的具体内容是什么？是否可以分享一下SQL文本？
- 是否有其他同时运行的大查询或事务影响系统性能？
- 在测试环境中，是否存在与生产环境不同的配置或参数设置？
通过这些信息，我们可以更准确地定位问题并给出相应的优化建议。
附上敏捷诊断工具 obdiag 使用帮助链接
1 个赞
更新的语句是什么
2 个赞
1、集群架构1-1-1，物理服务器：80C 384G 租户规格：200G
2、否
3、update items set name_upper=upper(name);
4、无
1 个赞
update items set name_upper=upper(name);
1 个赞
根据您提供的信息，您的全表更新操作 UPDATE items SET name_upper = UPPER(name); 在一个包含约65万行记录的表上执行非常缓慢。为了帮助优化这个过程，我们可以从以下几个方面进行分析和建议：
1. 检查现有索引
虽然您提到没有对涉及的表进行过索引优化或分区设置，但仍然建议确认 items 表上的索引情况。过多或不适当的索引可能会导致更新操作变慢。可以通过以下命令查看表上的索引：
SHOW INDEX FROM items;
2. 批量更新
对于大规模的数据更新，可以考虑分批处理以减少锁定时间和内存消耗。例如，每次只更新一部分数据：
-- 假设每批次更新10000条记录
SET @batch_size = 10000;
-- 使用循环逐步更新
REPEAT
UPDATE items
SET name_upper = UPPER(name)
WHERE id >= (SELECT COALESCE(MAX(id), 0) FROM items WHERE name_upper IS NULL)
LIMIT @batch_size;
UNTIL ROW_COUNT() = 0 END REPEAT;
请注意，上述代码需要根据实际情况调整，特别是确保 id 列是唯一且有序的。
3. 并行执行
如果硬件资源允许，并且 OceanBase 版本支持并行 DML 操作，可以尝试启用并行执行来加速更新过程。首先检查是否启用了并行查询功能：
SHOW PARAMETERS LIKE 'parallel_query%';
如果未启用，可以根据集群配置适当调整参数（需谨慎操作）：
ALTER SYSTEM SET parallel_degree_policy='MANUAL';
ALTER SYSTEM SET parallel_servers_target=4; -- 根据服务器核心数调整
4. 临时禁用触发器和约束
如果有任何触发器或外键约束作用于 items 表，它们可能会影响更新性能。可以在更新前暂时禁用这些特性，更新后再重新启用。具体操作取决于实际环境中的设计。
5. 监控与诊断
利用 obdiag 工具收集更多关于此次更新操作的性能数据，包括等待事件、锁争用等信息，有助于更深入地理解问题根源。参考之前提供的链接完成日志采集。
6. 评估系统负载
确保在执行大范围更新时，系统整体负载处于较低水平，避免与其他高负载任务冲突。可以通过 OCP 或者直接使用 SQL 查询当前系统的活动会话和资源使用情况：
SELECT * FROM gv$session WHERE status = 'ACTIVE';
7. 优化SQL语句
对于简单的字符串转换操作如 UPPER()，通常不会成为性能瓶颈。但如果存在复杂表达式或者函数调用，则应尽量简化。此外，确保 name 列上有合适的索引可以帮助提高查找效率（尽管这主要影响的是 SELECT 而非 UPDATE）。
综上所述，请先尝试以上建议中的一些方法，并观察效果。如果问题依旧存在，建议进一步通过 obdiag 收集详细的性能诊断信息并与官方技术支持团队联系获取专业指导。
具体信息可参考以下文档:
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
1 个赞
更新需要多长时间呢，整个表是分区表吗
你发一下执行计划 explain extended update items set name_upper=upper(name); --保存在文本里 提供一下
非分区表
没有执行成功，非分区表
学习学习
update 语句加并行看下能执行成功不，你说的执行不成功是超时报错了吗
升级时除了更新还有没有别的操作
没有别的操作了，现在都停止升级，手动跑这条SQL也跑不下去。
试了下，SQL还是卡死不动，没有结束的感觉。。。。
一直开始不动。。。 因为超时时间设置的已经很大了
能查询个gv$ob_SQL_AUDIT的记录吗，看下更新SQL的记录
-
首先推荐的当然是敏捷诊断工具，通过一键诊断分析对当前集群系统日志进行分析，快速发现可能得异常问题点，协助进行问题排查。可以按照小助手的提示排查
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}” -
全链路诊断中的Show Trace功能，也能轻松发现性能瓶颈并进行进一步的分析和调优。
-
以上两种方式可能并不是万能的，接下来可以按以下步骤尝试自查分析。
a. 通过查看gv$ob_sql_audit审计视图确认影响执行耗时的等待事件。
b. 再获取 SQL 执行计划EXPLAIN EXTENDED，查看执行计划并分析。
c. 获取 sql plan monitor 信息，全过程可以参看如下操作。
1.登录sys租户设置 sql_plan_monitor 参数确认 sql_plan_monitor 已经打开
show parameters like ‘enable_sql_audit’;
如果 enable_sql_audit = False 则将其打开
alter system enable_sql_audit = true;
-
登录业务租户，获取 sql 的执行计划
EXPLAIN EXTENDED sql语句; -
设置临时 trace 获取
SET ob_enable_show_trace=‘ON’; -
再次执行需要采集的 sql 语句
-
获取上一步执行的 sql 的 trace_id 信息
select last_trace_id(); -
临时关闭 plan monitor 数据，防止信息被覆盖
alter system enable_sql_audit = false; -
获取 plan monitor 的 sql ，将 xxxxx 替换为第 6 步返回的 trace_id ，以获取每个算子的吐行信息
select plan_line_id, plan_operation, sum(output_rows), sum(STARTS) rescan, min(first_refresh_time) open_time, max(last_refresh_time) close_time, min(first_change_time) first_row_time, max(last_change_time) last_row_eof_time, count(1) from oceanbase.gv$sql_plan_monitor where trace_id = ‘xxxxx’ group by plan_line_id, plan_operation order by plan_line_id;
8 恢复 sql_audit 参数
alter system enable_sql_audit = true;
d.获取以上信息后，最好也提供对应 trace_id 信息的 observer.log 日志协助分析。 -
助手的回答好像思路不大匹配