OceanBase 布道师计划：年度技术征文活动，优秀文章评选与布道师荣誉

“让技术可以看到|海底传福音计划”由Oceanbase赞助，并由CSDN共同组织，是开发人员的年度论文竞赛。全年有4轮，基于季度周期，每年1次会议进行出色的文章评估，并且最佳的传教士选择是按年度进行的。

目前，已经选择了第一轮技术论文屡获殊荣的文章。本文是“海底传福音计划”的出色文章之一，作者是Royce1220。

该活动仍在进行中。欢迎有兴趣的朋友点击“阅读原始文本”以输入活动官方网站，以了解有关活动的更多信息或进一步贡献：

。

法官有话要说

Feng Zhongyan（Oceanbase的开源生态学总监，Oceanbase的开源社区负责人）：使用Oceanbase之后，用户实际上是如何操作和维持海底的最关注的问题之一，尤其是紧急情况和故障诊断。 Obdiag的出现已经很好地解决了一些问题。这款Belle DBA通过个人经验向您推出了Oceanbase诊断工具OBDIAG，并专注于使用两种情况将其分享用于许多用户的故障排除。它非常有价值。

Laoyu（高级IT媒体人物，“ Laoyu Notes”的经理）：文章告诉Obdiag以Belle的方式应用，从操作，维护和开发人员的角度使用和收益，以及Obdiagsig的共同建设经验以及总体上，它对海底操作和维护人员具有一定的参考效应。

Zhang Yuwen（Motianlun社区负责人）：文章展示了Belle Fashion Group如何将其业务系统从MySQL+Mycat迁移到Oceanbase 4.2.1，以解决诸如分布式交易，分类业务调整和可扩展性之类的问题。从操作和开发人员的双重角度来看，作者详细阐述了OBDIAG工具在信息收集，群集检查，SQL诊断等中的应用。从操作，维护和开发人员的双重角度来看。这些内容对于数据库管理员和开发人员具有很高的参考值。特别是，通过特定的操作示例，例如锁冲突分析和SQL优化，作者有效地传达了OBDIAG工具的实用性和效率。

我是Belle时尚的DBA。在Belle Fashion应用Oceanbase的过程中，我的角色既是前线的DBA，又是Obdiag特殊利益小组（Obdiag Sig）的成员，这是一种敏捷的诊断工具，用于海底，参与共同建设和开发功能。本文主要分享我在Obdiag Sig中所做的并获得的工作，以及如何充分利用此角色来解决生产环境中的问题。

Belle的Obdiag应用状况

Belle Fashion Group是中国的一个大型时装鞋和服装团体。它在从产品趋势研究到设计和开发，零售以及随后到客户运营的每个阶段都使用数字技术。以前，业务系统使用MySQL+Mycat的库和表结构，并使用了精选编排器作为高度可用的管理中间件。由于不支持分布式交易的问题，在MyCat体系结构下调整碎片业务的难度和差的可扩展性，业务系统将在2023年迁移到Oceanbase 4.2.1版本。Oceanbase在分布式交易，分布式查询优化，优化，分布式查询，优化，分布式优化，优化，分布式查询，优化，分布式查询，水平可伸缩性和外围工具生态学，并且可以准确地解决Belle以前的疼痛点，并减少操作和维护困难和成本。自推出以来，它一直在内部流行，并已在订单中心和消息中心的两个核心业务中使用。

在我们的日常工作中，我们在多种情况下使用了Oceanbase的诊断工具OBDIAG，例如信息收集，集群检查，SQL诊断和根本原因分析。

Obdiag是一种适合黑色屏幕的诊断工具。它的现有功能包括扫描和收集信息，例如Oceanbase Logs，SQL Audit和Oceanbase Process Stack。它可以用于海底群集的不同部署模式（OCP，OBD或基于用户的手动部署文档）实现一键执行，以完成诊断信息的获取。 Obdiag在寻求官方支持之前遇到问题并加快了问题诊断的效率时，帮助我们省略了麻烦的信息收集行动。

我眼中的obdiag

作为Obdiag的用户和共同建设者，我将从两个角度解释Obdiag带给我的收益以及如何更好地使用Obdiag来解决问题。

从运营商的角度来看

从操作和维护的角度来看，这就是我们使用obdiag的方式。首先，以典型的实时锁定冲突场景为例。下面有两个会话，两者都执行相同的操作，也就是说，在表中的数据中选择更新操作。我们首先在会话中执行，然后等待会话第二会执行相同的操作。

面对上述情况，我们只需要使用obdiag执行命令：obdiag rca运行 - scene = lock_conflict，我们可以一键单击地分析会话和交易ID，然后自动提供解决方案。

cat obdiag_lock_conflict_20240808175840/record

+------------------------------------------------------------------------------------------------------------------------------------------+| record |+------+-----------------------------------------------------------------------------------------------------------------------------------+| step | info | +------+-----------------------------------------------------------------------------------------------------------------------------------+| 1 | by select * from oceanbase.GV$OB_LOCKS where BLOCK=1; the len is 2 | | 2 | get holding_lock trans_id:31794294 | | 3 | get holding_lock_session_id:3222014434 || 4 | wait_lock_trans_id is 31794336 || 5 | get wait_lock_session_id:3222015259 | | 6 | exec sql: SELECT * FROM oceanbase.gv$OB_SQL_AUDIT where SID="3222014434"; to get || | holding_lock_sql_info. | | 7 | holding_lock_session_id: 3222014434; not find sql_info on gv$OB_SQL_AUDIT | +------+-----------------------------------------------------------------------------------------------------------------------------------+
The suggest: holding_lock_session_id: 3222014434; wait_lock_session_id : 3222015259, sql_info: not find. Lock conflicts can be ended by killing holding_lock_session_id or wait_lock_session_id

其次，以典型的历史锁定冲突场景为例。当发生锁定冲突时，我们没有时间执行分析命令，也不知道目前要执行什么命令并希望找到历史锁定冲突。第一种方法是通过OCP，可以发现响应时间比执行时间大得多。

第二种方法是使用gv $ ob_sql_audit：命令查看响应时间。

QUERY_SQL:select * from config where config_name = 'test rule' for update;REQUEST_TIME:1723187738073566ELAPSED_TIME:4513197NET_TIME:0NET_WAIT_TIME:0QUEUE_TIME:0DECODE_TIME:0GET_PLAN_TIME:103964EXECUTE_TIME:43923RETRY_CNT:3403

如果响应时间大于执行时间，则通常会重复执行。然后，通过查看重复的数量，您可以确定是否发生了锁冲突。

接下来，我们使用obdiag收集日志：

obdiag gather log --from='2024-08-09 15:10:00' --to='2024-08-09 15:30:00' --grep="ret=-6004"

从日志中筛选和锁冲突相关的错误代码，比如6003/6004/6005。从日志中找到代码。

[2024-08-0915:20:52.514054]WDIAG[STORAGE.TRANS]inner_lock_for_read(ob_tx_data_functor.cpp:290)[279073][T1006_TenantInf][T1005][YB420AFA0270-0006196BA9DFF148-0-0][lt=4][errcode=-6004]lock_for_readneedretry(ret=-6004,tx_data={tx_id:{txid:325843478},ref_cnt:1,state:"RUNNING",commit_version:{val:1723188052513540049,v:0},start_scn:{val:1723188052513540049,v:0},end_scn:{val:18446744073709551615,v:3}

这些代码意味着集群中出现过历史锁冲突，如此便可以快速定位历史问题。

最后一个示例是OBDIAGSQL优化，假设Test1和Test2是两个具有完全相同结构的表，但是Test2的数据量大于Test1。连接条件为T1.C1 = T2.C1：

create table test1 (c1 int primary key, c2 int, key t1_i1(c2) local) partition by hash(c1) partitions15;create table test2 (c1 int primary key, c2 int, key t2_i1(c2) local) partition by hash(c1) partitions15;explain select * from test1 t1, test2 t2 where t1.c1 = t2.c1 and t1.c2 > 1 and t1.c2 < 1000;====================================================================== || |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| | ---------------------------------------------------------------------- |0 |PX COORDINATOR | |89 |484 | |1 |└─EXCHANGE OUT DISTR |:EX10001 |89 |416 | |2 | └─HASH JOIN | |89 |264 | |3 | ├─EXCHANGE IN DISTR | |89 |172 | |4 | │ └─EXCHANGE OUT DISTR (PKEY) |:EX10000 |89 |138 | |5 | │ └─PX PARTITION ITERATOR | |89 |62 | |6 | │ └─TABLE RANGE SCAN |t1(t1_i1)|89 |62 | |7 | └─PX PARTITION ITERATOR | |100 |63 | |8 | └─TABLE FULL SCAN |t2 |100 |63 | ====================================================================== |

在执行计划中，将在Test2上进行完整的表扫描，但这不是我们想要的。目前，我们可以使用OBDIAG命令来收集执行计划。

obdiag gather plan_monitor --trace_id=TRACE_ID --env="{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest'}"

从收集结果中可以发现，test2的估行和吐行差距过大，统计信息有问题！

call dbms_stats.gather_table_stats('test', 'test2');

通过obdiag重新统一信息，就可以解决问题。obdiag简单易用，帮助我们解决了很多问题，运维效率不断提升。因此，我也希望投入更多精力，为obdiag做一些贡献。

从开发人员的角度来看

我加入了Oceanbase的敏捷诊断工具兴趣小组，即Obdiagsig，即开源组，构建和促进Obdiag工具和生态系统。目的是创建一个综合出色的用户体验，强大的功能和活跃社区的海底诊断生态系统。 。

在参与共同建设的过程中，我发现了许多与用户的操作和维护角度不同的事物。例如，对于用户，OBDIAG RCA锁定冲突方案，有时无法收集导致锁定冲突的会话ID。从开发人员的角度来看，这个问题的基本原因是，Obdiag通过GV $ ob_lock $ ob_transaction_participants Association的trans_id和gv of tx_id tx_id，然后将GV $ ob_transaction_participants关联，但是GV $ ob_transaction_prarticipant是多重的piets the lirord Pift to lotike pote lotter pote lotter pict cluster at plote数据。用户举行的会话仅连接到后端的观察者，而其他会话ID显示为0，这使得用户无法收集相应的结果。

优化逻辑也相对简单，它是在本地运行目录中快速编辑与根本原因分析有关的脚本文件：obdiag/rca/lock_conflict_scene.py。只需添加一个条件，即计算ID不等于零。然后找出相应的数据，并显示用户想要查询的会话ID。

优化之后：

cat obdiag_lock_conflict_20240808175840/record

+------------------------------------------------------------------------------------------------------------------------------------------+| record |+------+-----------------------------------------------------------------------------------------------------------------------------------+| step | info | +------+-----------------------------------------------------------------------------------------------------------------------------------+| 1 | by select * from oceanbase.GV$OB_LOCKS where BLOCK=1; the len is 2 | | 2 | get holding_lock trans_id:31794294 | | 3 | get holding_lock_session_id:0 || 4 | wait_lock_trans_id is 31794336 || 5 | get wait_lock_session_id:3222015259 | | 6 | exec sql: SELECT * FROM oceanbase.gv$OB_SQL_AUDIT where SID="0"; to get || | holding_lock_sql_info. | | 7 | holding_lock_session_id: 3222014434; not find sql_info on gv$OB_SQL_AUDIT | +------+-----------------------------------------------------------------------------------------------------------------------------------+
The suggest: holding_lock_session_id: 0; wait_lock_session_id : 3222015259, sql_info: not find. Lock conflicts can be ended by killing holding_lock_session_id or wait_lock_session_id

例如，OBDIAG显示功能是共同构建的。以前，我们需要在操作和维护过程中使用大量的SQL和命令。这些SQL和命令的管理非常麻烦，并且经常被我们自己的“小笔记本”记录下来。如果需要，请搜索相应的命令，并且经验不足的用户可能无法启动。

因此，借助Oceanbase的官方功能，我们将一些常用的命令和SQL整合到Obdiag中。它只需要一个命令即可快速响应和显示结果，减少了操作和维护的难度，并允许新手用户也可以使用海底，例如在海洋中漫游的旧鸟。

obdiagsig共同建设经验和感受

像我一开始一样，许多用户认为参加共同建设会推迟他们的工作，或者对研发能力有很高的要求，并且担心如果他们不胜任，他们会受到打击。但是实际上，参与海底的共同建设非常简单。例如，如果添加了一个方案，我们只需要在运行目录的相应模块下打开配置文件，并根据规则和步骤创建它。例如：

#展示场景增加vi~/.obdiag/display/task/observer/demo.yaml：info_en:"[test]"info_cn:"[测试case]"task: -version:"[3.1.0,3.2.4]"steps: {steps_object} -version:[4.2.0.0,4.3.0.0]steps: {steps_object}

当前的一些成就如下：

目前，Obdiag 2.5.0版已正式介绍了Obdiag显示功能，欢迎每个人都能获得经验并提供指导和建议。

加入Obdiagsig之后，我不仅没有延迟工作，而且我的操作和维护工作也使我的操作和维护工作更加顺利。所有这些都来自我自己的操作和维护过程，我需要经常收集信息，并通过社区论坛和其他形式将其反馈给Oceanbase官员。随着收集越来越多的信息，收集频率越来越高，我开始与Obdiag接触。同时，我们使用OBDIAG来解决生产问题越来越多的次数。我已经开始吸引Obdiag强大的DIY功能，该功能可以轻松地将我想要的功能植入OBDIAG，并在共同构造项目中进一步加深。对obdiag的理解。

作为Oceanbase的用户和Obdiag的共同建设者，我衷心希望，更多的前线操作，维护人员和开发人员可以参与Obdiag项目，集思广益，并共同努力，建立更完整的OBDIAG场景，并且更强大的Obdiag知识基础以更好地解决我们在操作和维护过程中遇到的问题。