联通软件研究院+OceanBase：贡献源码 5000+行，共促社区生态繁荣发展

为进一步完善产品能力，支撑联通个性化业务需求，并提升对 OceanBase 内核的掌控能力，软研院决定在数据库内核及其自有工具层面展开开源共建。本文将描述联通软件研究院与 OceanBase 社区的共建内容及共建经验。

一、共建 oblogminer，应用于操作数据恢复场景

（一）对数据 DML 操作级精准恢复的迫切性

oblogminer 指事务日志分析。基于业务属性，联通数据库平台需要保证数据库实例级、表级、DML 操作级数据安全。OceanBase 本身的物理备份恢复机制，通过全量备份、增量备份和实时的事务日志备份，可实现数据库实例（租户）在备份周期内任一时间点的数据恢复。通过在工具应用层面定时任务调度，结合 MySQLDump 等底层备份工具，可实现在备份时间点的数据库表级别的数据恢复。

而在 DML 操作级的数据恢复层面，目前没有较好的工具支持，因为大多数 DML 误操作只是修改了一小部分数据，比如删除或更新了几条数据。在这种情况下，如果通过备份恢复去恢复这一小部分数据，会使整个租户的数据被恢复。当租户数据量较大时，该操作会非常耗时，比如 TB 级的数据往往需要恢复几个小时，而应用希望 DML 误操作的小部分数据在几分钟甚至更短的时间内恢复。

OceanBase 虽然提供了事务日志解析工具 ob_admin，可对增量数据进行解析进而使数据恢复，但解析结果可读性较差。尤其在 OceanBase4.x 版本中，解析出来的内容还是密文，需要对不同的数据类型再进行针对性解析。整体解析的工作量巨大，在此之上做到很好的兼容性几乎是不可能的。

OceanBase 社区为增强产品能力，实现事务日志分析，对标 Oracle 的 logminer，启动了 oblogminer 的建设工作。与此同时，了解到联通对 OceanBase 数据 DML 操作级精准恢复的迫切性，双方当即开始了 oblogminer 的共建工作。

（二）联通软研院重点研发 oblogminer 三大功能，提升易用性

oblogminer 的整体架构及数据流程比较复杂，涉及处理增量数据文件内容的解析、事务组装、记录过滤、转换、输出等环节，并且需要针对批量数据进行性能优化，以及对各过程管控等。通过 oblogminer 分析事务日志时，需要用户指定分析的目标集群。oblogminer 会根据用户给定的过滤条件将日志数据转化成对应的 Redo/Undo SQL 等信息供用户进行分析或进行数据恢复。整体架构如下：

从图中可见，Producer 将从 OceanBase CDC 获取的数据转换成 LogMinerBR 格式，再通过 DataFilter 的过滤，将 LogMinerBR 交由 DataConverter 做转换处理，生成更加便于使用的正向和反向 SQL。之后，Writer 组件会将日志归集聚合成批量记录，通过 FileManager 将批量记录写入存储介质（文件存储/OSS 对象存储）。DataManager 负责内存资源的分配及分析进度的管控，ResourceCollector 负责回收相应的内存资源，比如当 LogMinerRecord 完成输出后，会将 LogMinerRecord 对象所占用的内存资源回收。各个模块功能简单介绍如下表所示：

以下介绍软研院重点研发的内容。

1、分析结果输出 JSON 格式

联通软研院的主要业务场景是实现用户 DML 误操作的精准恢复，需要对输出的内容进行针对性分析，提取出用于数据恢复的反 SQL 等关键信息，这就要求输出的内容能更容易地被解析。

JSON 格式是最容易解析的数据格式之一，因此，软研院进行了分析结果输出 JSON 格式内容的研发。主要是针对解析的内容按照 JSON 格式进行拼装。其难点在于对特殊字符的处理，因为记录内容可能会包含所有可能的特殊字符，所以必须正确地处理各种字符，保证生成正确的 JSON 格式。

以下是 JSON 格式输出示例：

{"TENANT_ID":1002,"TRANS_ID":4415602,"PRIMARY_KEY":"","TENANT_NAME":"","DATABASE_NAME":"","TABLE_NAME":"","OPERATION":"BEGIN","OPERATION_CODE":5,"COMMIT_SCN":1708391913195415000,"COMMIT_TIMESTAMP":"2024-02-20 01:18:33.195415","SQL_REDO":"","SQL_UNDO":"","ORG_CLUSTER_ID":1}{"TENANT_ID":1002,"TRANS_ID":4415602,"PRIMARY_KEY":"","TENANT_NAME":"mysql","DATABASE_NAME":"test","TABLE_NAME":"t1","OPERATION":"INSERT","OPERATION_CODE":1,"COMMIT_SCN":1708391913195415000,"COMMIT_TIMESTAMP":"2024-02-20 01:18:33.195415","SQL_REDO":"INSERT INTO `test`.`t1` (`id`, `name`) VALUES (1, 'aaaa');","SQL_UNDO":"DELETE FROM `test`.`t1` WHERE `id`=1 AND `name`='aaaa' LIMIT 1;","ORG_CLUSTER_ID":1}{"TENANT_ID":1002,"TRANS_ID":4415602,"PRIMARY_KEY":"","TENANT_NAME":"","DATABASE_NAME":"","TABLE_NAME":"","OPERATION":"COMMIT","OPERATION_CODE":6,"COMMIT_SCN":1708391913195415000,"COMMIT_TIMESTAMP":"2024-02-20 01:18:33.195415","SQL_REDO":"","SQL_UNDO":"","ORG_CLUSTER_ID":1}

2、支持 trans_id 精准过滤，过滤器性能优化改造

通常情况下，是针对某个表的一段时间范围内的记录进行解析，生成正向和反向 SQL，但生成的记录数可能多于我们想要的记录数，比如我们执行了某一条 Update 或 Delete 语句，我们更想只针对这一条 SQL 影响的记录进行解析和数据恢复，这时候可以根据事务流水号 trans_id 进行精准过滤。

为更好地支持数据过滤，oblogminer 针对每种过滤场景都设计了专门的过滤器，使数据经过各个过滤器再继续向下传递。在开发测试中发现，随着过滤器的增多，数据过滤的代价也会相应增大。因此对过滤器进行了优化，采用根据过滤条件按需加载过滤器的方式。

例如，针对某个数据库实例，在分析日志时，可能需要分析某段时间内的所有事务日志，这时通过 CDC 自身的过滤就可以满足要求，不需要再经过特定列记录 Filter、操作类型 Filter 等过滤器过滤数据。经过优化，过滤性能得到了较大的提升。

3、执行进度、状态优化

使用 oblogminer 日志分析过程可能会比较耗时，这时就会体现执行进度、状态展示的重要性，即在执行优化改造后，可以实时展示当前执行的总进度、已处理的记录数、实时处理速度、平均处理速度等信息。以便掌握执行进度的实时信息。经过对执行进度、状态的优化，oblogminer 的易用性得到很大提升。

（三）oblogminer 应用于联通误操作数据恢复场景

oblogminer 主要用在联通的误操作数据恢复场景中，目前这部分能力已经集成到联通产品体系中。通过在界面上选择指定的数据库下的指定表，选择执行 SQL 的时间范围等信息，可一键运行 oblogminer 程序进行事务日志分析，并将影响记录生成的反 SQL 汇总到文件中，用于误操作数据的精准恢复。

二、共建备份恢复，适配联通云对象存储

（一）NFS 给数据安全与备份带来极大隐患

联通软研院作为数据库平台的建设及维护方，做好数据安全保障至关重要。数据备份是数据安全的最后屏障。软研院在分布式 CUDB 数据备份中，使用了 NFS 作为备份介质，但其存在两个问题。

1、单点问题

受限于 NFS 的架构，不能搭建集群方式的高可用架构。当机器故障时会出现备份中断甚至数据丢失的情况，存在极大的安全隐患。而且面临单台机器存储资源上限问题，无法水平扩展。当集群规模扩大时，需要不断地拆分实例才能正常进行备份，使用很不方便。

2、备份恢复卡顿、夯死问题

通过实际测试发现，NFS 在不同的 CPU 架构、操作系统下性能、稳定性存在较大差异，可能会出现备份卡死或租户数据恢复卡死问题，还有可能出现性能极低的情况，给数据安全带来极大隐患。

（二）传入特殊参数适配联通云存储

适配联通云存储，需要兼容当前的其他对象存储产品，在梳理了基本的代码结构后，主要进行两个方面的改造：一是如何识别联通云对象存储；二是针对联通云对象存储进行备份恢复改造。对于识别联通云对象存储，可能会涉及备份恢复对外接口的修改。为此，软研院向 OceanBase 社区提出了三种改造方案。

最终，确定采用第二种方式，针对联通云对象存储传入 addressing_model=path_style 的参数。确定改造方案后，软研院即进行了适配联通云对象存储的功能改造。经过测试验证，满足预期，并在 OceanBase 的 4.2.1.9 版本、4.2.5 版本同步上线。

（三）应用 4 个集群，备份数据量 30 TB

当前联通内部使用的 OceanBase 4.x 版本主要为 4.2.1.1 版本，在 4.2.1.9 版本正式发布后，软研院一方面针对新建集群直接部署 4.2.1.9 版本，另一方面针对存量 4.x 集群进行了升级操作。由于当前 OCP 版本还不支持联通云对象存储模式的备份，软研院临时建立了一套备份恢复机制，通过自动化脚本，及时实现新增租户的备份配置，再通过定时任务实现数据的周期备份。

现在已经有 1 个存量集群和 3 个新建集群实现了联通云对象存储的备份恢复，备份数据量 30TB 左右，备份稳定性和性能相比 NFS 均有较大提升。更重要的是，联通云对象存储有专业团队进行维护，并支持横向扩展，大大提升了数据安全性，也提升了软研院对分布式 CUDB 产品的信心。

后续，软研院将进行联通云对象存储资源的扩容，完成对存量 4.x 版本的升级，将备份存储服务完全迁移到专业产品中，为数据安全提供更好的保障。

三、共建敏捷诊断⼯具 obdiag，实现一站式运维

（一）obdiag 帮助用户自助诊断问题

OceanBase 是原生分布式数据库系统，故障根因分析通常比较繁琐，涉及的因素较多，如机器环境、配置参数、运行负载等。每当用户遇到 OceanBase 数据库系统的复杂故障时，往往求助于原厂的专业团队。

这不仅因为故障排查涉及大量分布在不同节点上的信息，而且收集和整理这些信息缺乏统一的工具，再加上专家在排查问题时需要获取大量的信息来分析故障。用户与专家反复沟通确认细节的过程使整个故障解决周期变得漫长且充满变数。

那么，如何高效地获取故障场景下分散在各个节点的信息，挖掘其中的关联性，帮助用户自助诊断问题呢？

这时 OceanBase 敏捷诊断工具 obdiag 的重要性便得以体现。拥有 obdiag 这一敏捷诊断工具后，通过 obdiag 的一键集群巡检、一键诊断分析、一键信息收集、一键根因分析以及一键集群洞察功能，简化了故障排查的交互过程。即便是经验相对不足的技术人员也能够快速地识别出潜在问题，并根据诊断结果采取相应的措施，提升故障排查的效率。

（二）参与共建 obdiag 5 大核心功能

联通软件研究院积极参与了 obdiag 的共建，作为首批加入 obdiag 特别兴趣小组（SIG）的成员，软研院共有四位专家融入这一开源项目的迭代开发。

在共建过程中，联通软研院结合自身使用 OceanBase 的实际场景，为 obdiag 开发了 3 个非常实用的根因分析功能、2 个诊断分析功能、1 个基础采集功能，以及 1 个巡检功能，这些新特性增强了 obdiag 在故障排查和系统维护方面的能力，更好的为日常运维工作服务。

从功能覆盖的角度来说，软研院参与的共建涉及了 obdiag  5 大核心功能，除了新功能的开发，软研院团队还完成了多项功能的迭代升级，并修复了若干已知问题，确保了 obdiag 能够更加高效、准确地支持日常运维工作。

下面展开阐述 obdiag 共建中较有代表性的工作。

1、obdiag 根因分析代码共建

根因分析场景是许多用户关注，也是运维过程中“最难啃的骨头”。

以索引执行失败的根因分析场景为例，大家都知道，在数据库运维中，DDL（Data Definition Language）操作是常见且重要的组成部分，其中包括创建、删除或修改数据库对象，比如表、索引等。但在实际生产环境中，DDL 操作可能会因为各种原因失败，比如资源不足、并发冲突等，这会给业务带来不必要的中断和损失。

为了解决这个问题，软研院对 obdiag 框架进行了扩展，精心设计并实现了一项根因分析功能——索引创建失败的根因分析。这项新特性能够在索引构建遇到错误时，通过一条命令就能深度诊断故障，如同经验丰富的专家一样，准确识别问题根源，并生成详细的分析报告，帮助运维团队快速定位根因。

该功能兼容 OceanBase 4.2.3 版本及后续版本（4.3 及以上），下面通过具体的案例复现展示该功能的实际应用效果。

obdiag rca run --scene=index_ddl_error --env tenant_name=cudb_test --env table_name=test1245 --env database_name=test --env index_name=idx_name -c obce423config.yml

根因分析的结果如下，明确展示了完整的根因分析链路及结果。 

2、obdiag 诊断分析代码共建

这部分以租户队列积压分析为例，阐述联通软研院在 obdiag 常规诊断分析的代码共建。

在 OcenBase 数据库中，如果出现数据库响应缓慢或存在登录、执行操作超时等问题时，通常会从多个角度定位问题，比如业务请求突增、机器性能、队列挤压等角度。其中，租户队列积压意味着队列中的请求处理（消费）速度低于请求到达（生产）速度，导致队列中的请求堆积增多，其本质原因是线程处理请求慢。但队列挤压的排查流程很麻烦，一般需要先确定对应租户的节点分布，登录对应节点去过滤想要时间点的日志，流程很长，当租户 unit 个数多，涉及多个节点时更难定位问题。

为了将排查经验产品化，提升故障排查效率，联通软研院将队列积压分析功能集成到了 obdiag 工具中。现在，一旦出现数据库响应缓慢或操作超时的情况，运维人员可以首先使用 obdiag 快速诊断是否由队列积压引起的问题。这大大缩短了故障排查的时间，提高了问题解决的效率，即使在复杂的多租户环境中也能迅速定位问题根源。

下面是使用样例，通过一行命令就能快速分析最近 2 分钟内租户 cudb64128 是否存在队列积压问题。

obdiag analyze queue  --since '2m'  --tenant 'cudb64128'  -c test1_config.yml

诊断结果如下图所示，cudb64128 租户下最近 2 分钟内在最后一个节点确实发生了租户队列积压的情况。

3、obdiag display 功能代码共建

obdiag display 即一键洞察功能的灵感源自 OceanBase 社区，在几次 obdiag SIG 周会的头脑风暴后，由 obdiag SIG 中的另一位成员领取了该任务，并在 obdiag2.5.0 中实现了第一版。在软研院使用 obdiag 2.5.0 的过程中，能够明显感知 obdiag display 功能对 DBA 很友好，极强的扩展性让大家能够快速地 DIY 自己的洞察场景。

在实际使用过程中，软研院团队发现了一些可优化的点。首先，尽管该功能已经与 OceanBase 4.x 版本实现了良好的兼容性，但缺失对 OceanBase 3.x 版本的支持，这限制该功能在更广泛环境中应用。其次，obdiag display 功能要求用户提供业务租户的 Root 用户名和密码，这种做法虽然便于直接访问所需资源，但也引出了安全性和权限管理的问题。

通常运维人员偏好于使用 sys 租户进行操作，便于控制对敏感数据的访问，同时保持系统的稳定性和安全性。另外，在处理大规模数据查询时，现有的功能未能充分满足需求。特别是当涉及多个相似类型的 SQL 查询时，结果之间的差异性不够明显，这增加了分析和理解数据的难度。

基于以上几点，本着“取之于 SIG，回馈于 SIG”的原则，软研院对 obdiag 进行了一系列针对性的优化：从提升安全性、增加兼容性，到优化展示结果和场景扩充。

在下面的例子中，可以看到原本需要运维人员记录很多内部 SQL 才能查到的信息，现在只需 obdiag display 的一条命令即可，而且用户侧可以无视 OceanBase 的版本，使用时毫无版本差异。

obdiag display scene run --scene=observer.cluster_info 3.x:obdiag display scene run --scene=observer.cluster_info -c armdb1_config.yml4.x:obdiag display scene run --scene=observer.cluster_info -c obce4_1_config.yml

通过 obdiag display 功能，运维人员能够显著提升问题排查效率，无需手动编写 SQL 查询。现在，只需一条指令即可快速洞察所需诊断信息，简化了操作流程并减少了人为错误的可能性。这一功能不仅节省了时间，还使得复杂问题的定位和解决变得更加直观和高效。

4、obdiag 诊断信息收集代码共建

在诊断分析的过程中，信息的收集显得尤为重要。软研院参与共建的诊断信息收集工具 TableDump 旨在快速收集问题表的相关信息，如表结构、表数据分布等，缩短运维人员手动收集的时间，也为后续的根因分析提供数据支持。TableDump 既可以单独使用，方便用户快速查看某个表的基础信息，如表的结构、索引、约束等，也可以作为公共方法，被其他功能项调用，以支持更复杂的数据库诊断和优化任务。

TableDump 在数据库管理和维护中发挥着不可或缺的作用，为用户提供了极大的便利。下面简单演示其功能，通过一行代码即可拉起收集命令：

obdiag gather tabledump --database=test --table=dt_statements_sql --user=root@xxx#xxxx --password=xxxxx -c config.yml

如下图所示，结果集包括执行的 SQL 语句、返回的结果，当前可收集的信息包括表结构、数据分布信息等。

（三）obdiag ⼯具整合，实现一站式运维

在 obdiag 共建的过程中，联通软研院不仅深入参与了代码层面的开发，还积极推动了工具的集成。通过引入多项实用的新特性，显著增强了 obdiag 故障排查和系统维护的能力。基于这些共建成果，软研院进一步将 obdiag 集成到了自主研发的云体系中，实现了统一的操作入口和一站式的运维体验。

通过界面化操作平台，用户可以根据集群信息自动生成配置文件，并利用后台异步调用确保命令连续执行，避免因超时中断而导致的诊断不完整问题。同时，优化了结果展示方式，使其更加直观易懂，并支持实时查询集群节点信息，确保配置文件的最新性和诊断的准确性。目前可在联通云产品控制台进行对指定集群进行信息收集、集群巡检、集群诊断、根因分析。

从代码共建到工具整合的全流程优化，不仅提升了 obdiag 的功能性和易用性，还极大地增强了日常运维工作的效率和可靠性。软研院通过这种方式，不仅回馈了社区，也为自己和广大 OceanBase 用户带来了更为高效、便捷的运维解决方案。

四、共建 OceanBase SIG，取之于社区，回馈于社区

秉持“取之于社区，回馈于社区”的原则，联通软研院积极参与并推动 OceanBase 社区的发展。自 OceanBase 社区特别兴趣小组（SIG）成立以来，软研院积极投身于开源项目的共建与发展，并成为首批 SIG 核心成员之一，认同并践行 SIG 的使命和价值。

（一）联通软研院加⼊ SIG，推动技术创新与实践

在软研院看来， SIG 是技术社区中不可或缺的力量，扮演着推动技术创新和实践应用的关键角色，促进开源项目健康发展。

首先，SIG 为开发者提供了一个专注于特定技术领域或解决问题的协作空间。通过集中讨论、资源共享和技术交流，SIG 成员能够快速识别并应对复杂的技术挑战，加速创新成果的产生与落地。这种高效的协作机制使得新技术和解决方案能够在短时间内得到验证和完善，进而更好地服务于实际应用场景。

其次，SIG 促进了跨组织的合作与知识传播。不同背景的专家和从业者在此平台上共同探索前沿课题，分享实践经验，不仅拓宽了个人视野，也为整个社区带来了更广泛的技术积累。联通软研院通过参与 SIG，得以借鉴其他成员的成功经验，同时也将自己的最佳实践回馈给社区，形成了良性循环的技术生态系统。

再者，SIG 为培养下一代技术人才提供了宝贵的实战机会。年轻工程师可以通过参与 SIG 活动，接触到最新的技术和理念，并在实际项目中锻炼技能。这不仅有助于提升个人能力，也为企业和社会储备了大量高素质的专业人才。

最后，SIG 的存在增强了技术社区的整体凝聚力和影响力。一个活跃且富有成效的 SIG 能够吸引更多的贡献者加入，形成强大的社群效应。

（二）积极参与 SIG 贡献，让更多人受益

自加入 OceanBase 社区特别兴趣小组（SIG）以来，联通软件研究院积极投身于开源项目的共建与发展，成为首批参与 obdiag SIG 的核心成员之一。

除了上文阐述的代码共建外，还参与 SIG 的日常运营。自加入 OceanBase 的 SIG 以来，软研院团队累计参与超过 20 场次的 SIG 会议，这些会议不仅是技术交流与合作的重要平台，也是推动项目发展、解决问题以及规划未来方向的关键环节。在每一次 SIG 会议上，联通软研院团队都积极贡献自己的智慧和经验，不仅分享联通在大规模数据库运维中的实践经验，还与其他社区成员深入探讨 OceanBase 的技术发展趋势和最佳实践。

例如：就技术难题进行协作讨论，共同寻找解决方案；在开发新功能时，深入讨论功能设计、实现方案等，确保功能的合理性和可行性。通过这种协作方式，obdiag SIG 成功解决了多个技术难题，推动了敏捷诊断工具的持续进步。

联通软研院深知 SIG 会议对于提升社区活跃度和增强凝聚力的重要性，因此，在每次会议中都鼓励更多成员参与进来，分享他们的见解和经验。同时，软研院也积极推动会议内容的产品落地，让更多人受益于 SIG 的工作成果。

五、从贡献者到布道者

（一）开发者⼤会

近年来，OceanBase 每年都会举办开发者大会。在 2024 年 4 月 20 日的 OceanBase 开发者大会，来自全国各地的 600 多名开发者相聚现场，与 OceanBase 的创始人员、业内专家共同探讨一体化多模、TP 与 AP 融合、多云原生前沿趋势，以及 OceanBase Road-map、场景探索和最佳实践。联通软研院数据库团队应邀在大会主会场分享《携手共建：中国联通的 OceanBase 分布式数据库探索之路》。

在演讲中，围绕分布式 CUDB 的发展演进历程、产品生态体系建设、经典案例分享等方面展开阐述。着重介绍了软研院在数据迁移、产品高可用、智能运维等产品能力建设方面取得的一系列创新研发成果，以及在社区共建中对于 oblogminer、obdiag 的建设成果与思考。

（二）“唠嗑了O” 线下技术交流会

“唠嗑了O”是一档由 OceanBase 社区用户组（OUG) 发起，面向社区用户组成员，进行技术交流分享的线下邀请制活动。每期邀请熟悉 OceanBase 的“老司机”坐镇，围绕现代教据技术栈中的产品特性、架构原理、生态工具、案例场景、运维实践等热点话题，展开面对面的技术探讨和畅聊。

金秋九月，OceanBase 社区来到济南，携手联通公共平台与架构研发事业部，在联通软研院济南分院主办了 “唠嗑了O”线下技术沙龙，吸引了济南本地众多数据库的技术专家与技术爱好者，共同围绕 OceanBase 数据库的最新技术、产品特性、架构精髓、生态工具、实战案例及运维智慧等核心议题，展开了深入的探讨和交流。

联通软研院作为东道主，同时作为 OceanBase 4.2.3 版本的社区贡献者，分享了团队在自研分布式 CUDB 上的探索历程与成就，详细介绍了如何与联通云深度融合，为联通超大规模应用提供高效、便捷、稳定的服务。并对软研院参与社区共建的高效数据迁移工具 MOT、事务日志解析与精准恢复、适配联通云 COS 存储等场景展开了深入探讨。在轻松的技术交流氛围下，在场的技术专家都充分表达了自己的观点，并分享了相关实践经验。

（三）与社区的其他共建

联通软研院还积极参加 OceanBase 社区的其他活动，与社区专家进行深入沟通，反馈软研院对于 OceanBase 的使用体验和应用问题，也及时通过社区专家了解产品的新特性、新功能，以及使用误区和最佳实践。据不完全统计，软研院参与社区技术会议和交流活动超过 30 次（包含线上）。

通过社区问答模块提出问题 24+ 个，通过钉钉群等其他方式提出问题共 78+ 个，修复内核 BUG 3 个。另外，软研院还通过社区博客等方式，毫无保留地分享了在社区共建中的经验及成果，先后输出了 oblogminer 功能实现、DDL 报错场景分析、联通 RAG 实践等近 10 篇文章。

六、从周边工具到日志分析，推动未来技术创新

（一）深度参与工具研发，贡献源码 5000+ 行

联通软研院与 OceanBase 社区在内核研发方面进行了深度共建，贡献源码超过 5000 行。完成了事务日志分析 oblogminer 基本能力建设，并进行产品化改造，可一键实现用户 DML 误操作数据精准恢复；完成了 OceanBase 备份恢复适配联通云对象存储 COS 改造，解决了联通内部备份恢复使用 NFS 备份恢复带来的单点、卡顿问题；完成了 OceanBase 敏捷诊断工具 obdiag 共 3 项根因分析场景研发、2 项诊断分析功能的研发、1 项集群巡检添加以及多项功能完善，并进行工具化集成，实现界面化一键诊断能力。

在社区共建方面，联通软研院作为演讲嘉宾或活动联合主办方，积极参与或组织活动。比如在 OceanBase 开发者大会分享《携手共建：中国联通的 OceanBase 分布式数据库探索之路》，展示软研院在社区共建方面的丰硕成果；与 OceanBase 社区携手主办 “唠嗑了O”济南站活动并进行内容分享，展示联通基于 OceanBase 社区版研发分布式 CUDB 的成果和应用效果。另外，软研院还积极在社区论坛、钉钉等渠道反馈问题、提出建议等，并参与社区 SIG 组织发展会议，团队成员因贡献突出依次获得“社区月度之星”称号。

（二）在技术研究、产品开发等⽅⾯深化合作

未来，联通软研院与 OceanBase 社区将在内核研发、obdiag 功能完善、技术交流与分享等方面继续深化合作，共同推动数据库技术的创新与发展。具体而言，包含以下四个方面。

（三）开放合作，推动技术创新

在联通软研院与 OceanBase 社区的合作成果中，开放合作对于推动技术创新的重要性得到了充分体现。双方通过深度共建，不仅在内核研发方面取得了显著成果，从产品根源帮助用户解决问题，比如解决了用户 DML 误操作数据表恢复的问题，还在备份恢复、敏捷诊断工具 obdiag 等多个领域进行了创新和完善。

这些合作成果不仅提升了 OceanBase 数据库的性能和用户体验，还使双方共同面对技术挑战，发挥各自优势，从而加速技术创新的步伐。更重要的是，通过共建共享，促进了双方与其他用户在分布式数据库研发、应用效果等方面的深度交流和经验传递。拉动其他用户参与社区共建与交流，形成良好的用户社区发展生态。

未来，软件院将基于 OceanBase 开源继续深度贡献，在内核研发、obdiag 功能完善、技术交流与分享等方面深化合作，共同推动数据库技术的创新与发展。通过开放合作的模式，提升双方的技术实力和市场竞争力，为数据库行业的发展注入新的动力。