在 2023 年度发布会上,OceanBase 沿着“一体化”产品战略思路,发布了一体化数据库的初个长期支持版本 4.2.1 LTS。作为 4.0 系列的初个 LTS 版本,该版本的定位是支撑客户关键业务稳定长久运行,我们非常认真的打磨了这个版本,确保客户可以在关键业务负载中放心地规模化使用。
在客户真实生产环境中,一体化版本已成功支持上百个关键业务系统的稳定运行,涵盖私有化部署和公有云环境。作为 OceanBase 4.x 系列的迭代版本,4.2.2 版本正式发布。我们在内核层面进一步加强了系统,通过重构估行系统和统计信息收集机制,全面优化复杂场景下的 SQL 执行性能。持续完善 MySQL/Oracle 兼容性,新增了 Lateral Derived Tables、分页查询保序、DBLink调用远端UDF等多项业务依赖的实用特性。在两种兼容模式下,我们也分别补充完善了 GIS、XML、JSON 等多模数据类型的实现。引入了 SQLSTAT、TIME MODEL、手动 Transfer 分区等多项易用性功能改进。通过降低索引空间占用、支持 OBKV RPC 压缩等特性,我们进一步优化了系统资源的使用,确保在满足用户关键业务负载场景对性能和稳定性的前提下,提供更灵活、更高效的支持,更好地适应实际生产环境的需求。
本文将深入介绍 OceanBase 4.2.2 面向关键业务负载方面的内核、多模、易用性、性能等新进展,分享新版本带来的重要功能特性及用户价值。
1、关键特性及用户价值
(一)内核增强
OceanBase 4.2.2 版本注重提升数据库整体性能与稳定性。估行系统全面强化,新策略和手动干预方式优化器性能显著提升。统计信息功能高效升级,为关键业务系统提供更准确的查询计划优化。大 IN 查询场景引入全新算法,减少资源开销,提升系统响应速度。
执行引擎强化包括 Recursive CTE 搜索、Window Function 内存管理、Adaptive Hash GBY 优化,显著提升 SQL 查询执行性能。存储过程效率提升,PL 编译结果落盘降低 CPU 消耗,生成列和函数索引通过固化 SESSION 变量值提高稳定性。此外,OBCDC 黑白名单配置实现更细粒度、可控的日志同步管理。
(二)兼容性
OceanBase 4.2.1 LTS 作为关键业务系统升级的里程碑,标志着兼容性方面的重要进展。4.2.2 版本经过深度优化,进一步提升了Oracle 和 MySQL 的兼容性。新引入的Lateral Derived Tables以及分页查询保序功能,进一步增强了SQL语句的可读性和结果输出的稳定性。针对整型列类型变长,实现了对 Online DDL 方式的支持,避免了对业务写入的阻塞。
同时,新增的客户端本地导入功能使数据开发人员能够更便捷地进行本地文件导入测试。通信协议的完善,包括对 MySQL COM_SET_OPTION 和 AuthSwitchRequest 协议的兼容,进一步增强了 MySQL 生态兼容。同时,新增对 MySQL 8.0 新增的 show extended 语法的支持提升了系统的灵活性。这一系列升级旨在为用户提供更好的兼容性,为关键业务系统的平滑升级提供有力支持。
(三)多模能力
OceanBase 4.2.2 版本在多模能力进行了全面升级,引入了一系列强化和新增功能,为用户提供了更广泛、更灵活的数据处理和分析能力。在 GIS 增强方面,不仅对 MySQL GIS 和 Oracle GIS 的常用表达式进行了强化,还新增了对 PostGIS 兼容函数的扩展支持,加入了对三维空间对象的存储能力,为空间数据应用提供了更强大的支持。
在 XML 和 JSON 方面,OceanBase 4.2.2 版本进一步丰富了对 MySQL XML 和JSON的支持,新增了多个兼容表达式,包括对XML中的ExtractValue和UpdateXML、对JSON中的JSON_SCHEMA_VALID、JSON_SCHEMA_VALIDATION_REPORT和JSON_ARRAY_APPEND的支持,为用户处理和操作 XML 和 JSON 数据提供了更多灵活性和便捷性。特别值得注意的是,新增的 JSON Partial Update 功能为使用 JSON 文档存储业务数据的用户提供了更高效的文档更新方式,避免了全文档读取和全量更新,尤其在处理大型文档时,带来了明显的性能提升。
(四)性能提升
为更好地满足用户在公有云环境下的 4C16G 小规格诉求,4.2.2 版本进行了专项性能优化,包括后台线程使用、Location Cache 访问、读写主路径、系统调用等多个关键方面。在同等环境的 Sysbench 压测中,相对于 4.2.0 版本,小规格环境下的性能提升幅度达到了 10% 到 30%,确保了小规格系统资源充分利用,为用户提供更为流畅的使用体验。
除了小规格的性能提升,新增并行 DDL 支持了在 Oracle 模式下并行设置表或列的 Comment 以及并行 Create Index,提高了 OMS 表结构迁移效率。对于日志同步,引入了单日志流并行同步模型,显著提升了同步性能并优化了内存使用,特别适用于异地部署和云存储场景。旁路导入得到强化,新增资源管理模块,实现了对导入任务线程和内存资源的精准控制,确保了导入任务的稳定执行。R 副本按 Region 级联的新特性减少了跨 Region 网络带宽占用,得到用户广泛欢迎。此外,4.2.2 版本通过渐进式执行优化了分区局部索引空间,解决了构建索引过程中的临时空间放大问题。JSON/XML 汇聚函数经过内存优化,提升了执行过程中的内存利用效率。
(五)易用性提升
OceanBase 4.2.2 版本是基于用户反馈和建议的成果,着重提升易用性和用户体验。引入 SQLSTAT 功能实时记录 SQL 执行状态,便于性能问题定位。时间模型统计支持 SESSION、TENANT 级别,提供 9 个关键性能指标,有助于精准问题诊断和性能调优。手动 Transfer 分区功能允许用户定制数据分布,满足个性化需求。主备租户事件记录细化,方便用户查找操作记录。新增网络备库复制角色简化运维,PL & SQL 日志解耦提高问题排查效率。PL 执行时间统计、执行计划和限流同时绑定,简化了对 PL 执行性能的分析。动态配置 LOB 存储模式提供更灵活的业务配置选项。这一系列改进旨在使用户更高效地利用 OceanBase 解决实际业务需求。
2、关键特性说明
(一)内核增强
1. 估行系统增强,提升优化器性能
随着 OceanBase 版本的持续演进,优化器代价估算方式也变得更加丰富多样。在考虑每个算子的估算时,当前版本已经实现了对存储层估算、统计信息估算、动态采样以及默认统计信息等算法的全面支持。然而,尽管在使用上相对自由灵活,但却存在缺少清晰策略和完善控制手段的问题。
为应对这一挑战,OceanBase 4.2.2 版本对估算系统进行了全面重构,根据不同应用场景制定了不同的估算策略优先顺序,并引入了 HINT、系统变量等手动干预估算策略选择的方式。与此同时,新版本还对谓词选择率和 NDV 计算框架进行了进一步增强,以提升优化器代价估算的准确性。
2. 统计信息增强,更全面的数据收集
统计信息在数据库系统中扮演着关键的角色,它们提供了数据库引擎用于优化查询计划的重要依据。特别是针对关键业务系统,如果统计信息收集策略不够优化,可能导致数据库引擎缺乏对数据分布和索引使用情况的全面了解,从而影响查询计划的准确性。
在近期发布的 4.2.2 版本中,我们在 4.2.1 基础上进一步完善了统计信息功能,重点优化了统计信息的收集性能、兼容性和易用性。这一系列的改进主要包括:
- 离线统计信息收集流程的重构:提高了统计信息的收集效率,确保离线收集流程更加高效可靠。
- 优化统计信息收集策略:默认自动收集索引直方图,采用推导统计信息收集方式,进一步提高了收集的精度和全面性。
- 确保在线统计信息收集的事务一致性:确保在线统计信息收集的事务一致性,避免了统计信息收集过程中数据丢失或损坏等意外情况发生。
- 兼容 Oracle DBMS_STATS.COPY_TABLE_STATS 和 MySQL ANALYZE TABLE 功能:增加了对 Oracle DBMS_STATS.COPY_TABLE_STATS 功能的兼容性,同时提供更丰富的语法支持,使统计信息的拷贝更加灵活。
- 新增取消统计信息收集的命令和丰富的监控支持:通过新增取消统计信息收集的命令,加强了对统计信息收集进度的监控,提升了运维的易用性。
- 提供统计信息并行删除能力:引入了统计信息并行删除能力,进一步提高了统计信息的删除效率。
这一系列的改进不仅使得统计信息的收集更为高效和全面,同时也提供了更多灵活性和便利性,为用户提供了更加可靠的统计信息从而提升性能和稳定性。
3. 执行引擎强化,提升 SQL 执行性能和系统稳定性
随着数据库应用场景的不断扩展和业务数据的增长,用户对 SQL 查询的性能和响应速度提出了更高的期望。在这种背景下,执行引擎作为数据库的核心组件,承担着转化 SQL 查询为底层数据操作的任务。因此,为了提供更高效、更稳定的数据库服务,我们在 4.2.2 版本中着重加强了执行引擎的功能和性能,包括 Recursive CTE 搜索优化、Window Function 接入自动内存管理、Adaptive Hash GBY 数据倾斜优化、Adaptive Hash GBY 自适应策略完善、Hash Based Distinct Aggregate 优化等,提升 SQL 执行性能和系统稳定性。
4. PL 重新编译逻辑优化,提高存储过程执行效率
存储过程编译为共享库后,可以提供给多个线程使用。但如果发生依赖对象变更,共享库可能失效需要重新编译。4.2.2 版本针对重新编译场景做了进一步加强,在临时表匹配、静态 SQL 依赖对象信息收集、表 DDL 变更等方面进行一系列逻辑优化,减少因 PL CACHE 缓存对象失效导致重新编译的场景。
5. PL 编译结果落盘,减少 CPU 资源消耗
当前 PL Function/Procedure 编译后会加入到 PL Cache 中,当内存压力过大时可能会被淘汰,重启后会丢失编译结果,并且在分布式场景下也需要重新编译。在这些情况下,PL 无法命中 PL Cache,进而触发 LLVM 编译,导致消耗部分 CPU 资源。4.2.2 版本开始,我们对 PL 编译结果进行了重要的改进,PL Function/Procedure 被加入系统表落盘保存,未触发 DDL 使 PL 缓存失效的情况下,无论重启还是分布式场景都可以只编译一次后复用缓存。
6. OBCDC 黑白名单,更细粒度的日志同步控制
OBCDC 目前已具备租户级别的日志同步功能。为了进一步提升同步的可控性,4.2.2 版本引入了对库和表级别的同步粒度的支持。具体而言,该版本支持用户通过简单的正则表达式配置黑白名单,以满足用户对于只需要同步部分表的数据消费场景的需求。
(二)兼容性
1. Oracle兼容
定位于关键业务系统升级的 4.2 版本,是 Oracle 兼容性的一个里程碑版本,汇集了 OceanBase 在银行、券商、保险、运营商、电力、人社等多个行业实际业务场景中打磨出的各项兼容能力,让更多的业务场景可以利用 4.2 LTS 版本进行平滑应用迁移。
- 用户自定义类型(UDT)增强:4.2.2 版本完善了 UDT 相关的依赖对象信息收集机制,兼容了 Oracle UDT 未指定 FORCE 关键字时的执行行为,同时增强了 USER/ALL/DBA_OBJECTS 视图 STATUS 列及 USER/ALL/DBA_DEPENDENCIES 等视图的信息准确性。
- 文本协议支持复杂数据类型展示:加强对 Oracle 文本协议下复杂类型序列化功能的兼容性,当 SQL 查询结果中存在复杂数据类型时,支持将复杂数据类型序列化为 Oracle 兼容的文本输出。
- DBLink 支持调用远端 UDF:在 Oracle 模式下,已支持通过 DBLink 连接原生 Oracle 查看远端表或视图,调用远端存储过程。4.2.2 版本新增支持 PL 和 SQL 调用远程 Oracle UDF,或 Package 中的 Function 功能。
- Lateral Inline View:类似 MySQL 兼容模式的 Lateral Derived Tables 语法,Oracle 兼容模式现已支持 Oracle Lateral Inline View 语法。通过添加 Lateral 关键字,使内联视图可以引用同一 FROM 子句中前面表的列,并提供 DECORRELATE/NO_DECORRELATE hint 来控制是否进行 Lateral Inline View 改写。
- 全局临时表功能完善:在 Oracle 模式下,全局临时表在之前版本已支持基本的 Create、 Select、 Insert、 Delete 和 Update 功能,新版本进一步新增支持 Merge Into 和 Insert All 使用临时表的场景。
- 视图注释:在之前版本仅支持实体表添加注释不同,新版本现已支持对视图和视图列添加注释,可通过 comment on 语句添加,或在视图定义中使用 -- 添加。
2.MySQL兼容性
OceanBase 的 MySQL 兼容模式在之前的版本已经对 MySQL 5.7 有很好兼容能力的基础上,并引入了大量 MySQL 8.0 的新功能。在近期 4.2.2 版本中,我们对兼容性进行了进一步提升,主要包括以下几个方面:
- Lateral Derived Tables:Lateral Derived Tables 是一种特殊的 Derived Tables,可以引用同一 FROM 子句中前面表的列。这种用法使得 SQL 更易读易写,通常还能减少数据的重复扫描计算,从而提升 SQL 执行性能。
- 分页查询保序:由于计划选择、并行执行等因素影响,很多数据库在 limit offset 场景下输出结果是不稳定的,通常需要在每个 SQL 外层添加 order by 来确保稳定有序输出。原生 MySQL 虽然未承诺保序,但很多查询仍会保持结果集有序输出,为了避免 MySQL 迁移业务分页场景的改造,OceanBase 增加了分页查询保序功能。需要注意,在处理大数据量时,与不保序行为相比,可能会存在一定的性能回退。如果业务场景对保序有明确诉求,可以在评估测试性能影响并确认接受后,通过配置项打开该功能。
- INTEGER 列类型增长支持 Online 方式:对于主键列、分区键、索引列、被生成列依赖的列以及有 Check 约束的列,如果列类型为整型,当列类型修改为取值范围更大的整形列类型时(如 INT -> BIGINT),在 4.2.1 版本中是通过双表双写的 Offline DDL 实现,转换过程中会加表锁,阻塞读写。但从 4.2.2 版本开始,将 Offline DDL 改进为 Online DDL,整型列类型增长将不再影响业务写入。
- 客户端本地导入:OceanBase 4.2.2 之前版本,支持了通过 SQL 导入服务端(普通或旁路)、NFS、OSS 文件,但客户端本地文件需要借助 OBLoader 等工具导入,无法通过 SQL 命令直接导入。为了方便数据开发人员进行本地导入测试,以及解决云环境无法登录服务端导致数据导入不方便的问题,4.2.2 版本新增支持客户端本地导入(Load Data Local Infile)功能,通过流式文件处理方式完成本地文件导入。
- PS 协议支持存储过程出参:在 MySQL 兼容模式下,通过 PS 协议执行 CALL PROCEDURE 语句时,我们新增了对存储过程带出参的支持。
- 通信协议完善:兼容 MySQL COM_SET_OPTION 通信协议命令,用于指定 CONNECTION 级别选项,如 MYSQL_OPTION_MULTI_STATEMENTS_ON、MYSQL_OPTION_MULTI_STATEMENTS_OFF。同时,4.2.2版本还兼容了 MySQL AuthSwitchRequest 协议,用于支持认证方式切换,解决部分客户端版本不匹配导致认证出错的问题。
- Show Extended Tables/Columns/Index:OceanBase 4.2.2 版本支持了 MySQL 8.0 新增的 show extended 语法,包括 show extended tables、show extended columns、show extended index。
(三)多模能力
1. MySQL GIS 增强
OceanBase 4.1 版本引入了对 MySQL GIS 数据类型及部分空间对象相关表达式的支持。4.2.2 版本在这一基础上进一步强化了空间数据的存储和计算分析能力,新增支持了 MySQL 兼容的 ST_Crosses、ST_Overlaps、ST_Difference、ST_Union、ST_SymDifference、ST_Length、ST_Centroid以及ST_AsGeoJSON 等表达式。
针对 GIS 行业中最广泛使用的 PostgreSQL 数据库,OceanBase 在新版本中扩展并补充了一些与 MySQL 有所不同的常用表达式,包括 _ST_Touches、_ST_Equals、_ST_MakeEnvelope、_ST_ClipByBox2D、_ST_GeometryType、_ST_IsCollection、_ST_NumInteriorRings、_ST_PointOnSurface、ST_AsMVTGeom以及_ST_AsMVT 等。此外,新版本还支持了三维空间对象的存储能力,为更多空间数据场景提供了更强大的支持。
2. MySQL XML
新增兼容 ExtractValue 和 UpdateXML 表达式,进一步丰富了对 MySQL XML 数据类型的支持。ExtractValue 用于从 XML 文档中提取特定路径的值,而 UpdateXML 则用于在 XML 文档中更新指定路径的内容。这些新增的表达式丰富了 XML 数据的处理方式,帮助用户在操作 XML 数据时更加得心应手。
3. MySQL JSON
新增兼容 JSON_SCHEMA_VALID、JSON_SCHEMA_VALIDATION_REPORT 和 JSON_ARRAY_APPEND 表达式,进一步拓展了系统对 MySQL JSON 数据类型的支持。JSON_SCHEMA_VALID 用于验证 JSON 数据是否符合指定的模式,而 JSON_SCHEMA_VALIDATION_REPORT 则提供了更详细的验证报告。此外,JSON_ARRAY_APPEND 使用户能够在 JSON 数组中追加元素,增加了处理 JSON 数据的灵活性和便捷性。
4. MySQL JSON Partial Update
4.2.2 版本引入了 JSON Partial Update 功能,为用户提供更高效的 JSON 文档更新方式。对于使用 JSON 文档存储业务数据的用户,以往只能进行全文档读取和全量更新,当文档较大时,这样的操作可能导致性能下降。通过新增支持的 JSON Partial Update 功能,用户可以使用特定表达式(如 json_set、json_replace、json_remove)来更新 JSON 文档的部分字段,而不需要进行全量覆盖更新。这种方式有效提升了更新性能,尤其在文档较大的情况下,更能满足用户的预期性能需求。请注意,为使用该功能,需要通过配置项 log_row_value_options 进行相应的设置。
5. Oracle GIS
为支持依赖位置信息服务的业务方便地存取和分析空间数据,4.2.2 版本新增支持 SDO_GEOMETRY 数据类型,可用于描述 point、linestring、polygon、multipoint、multilinestring、multipolygon、collection 7 种空间类型。同时也支持了通过成员函数 get_dims、get_gtype、st_isvalid 查询 SDO_GEOMETRY 空间对象的维度、类型以及是否是有效的空间对象的信息,支持了通过 get_wkb、get_wkt、get_geojson 来将 SDO_GEOMETRY 转换为 Well-Known-Binary 、Well-Known-Text 或 JSON 的数据格式,进一步拓展了空间数据的应用范围。
6. Oracle XML
新增兼容 XMLTABLE、INSERTCHILDXML、DELETEXML、XMLSEQUENCE 表达式的兼容支持,这些表达式的引入进一步加强了数据库对 XML 数据的处理能力,为用户提供更多灵活性和便利性。
7. Oracle JSON
4.2.1 版本为 PL 语句引入了 JSON_OBJECT_T 和 JSON_ELEMENT_T 两种 JSON 数据类型的支持,为用户提供更灵活的 JSON 数据处理方式。4.2.2 版本进一步补充支持了 JSON_ARRAY_T 数据类型,为用户提供更全面的 JSON 数据表达能力。这一系列的更新进一步增强了 Oracle 兼容模式下对 JSON 数据的支持,使用户能够更便捷地处理和操作 JSON 数据。
(四)性能提升
1. 小规格专项性能优化
为适应公有云环境下的 4C16G 小规格,4.2.2 版本在多个关键方面进行了专项性能优化,包括后台线程使用、Location Cache 访问、读写主路径、系统调用等。在 Sysbench 压测场景下,针对 30 个压测表、单表 50 万行数据、单 Primary Zone 的测试,相较于 4.2.0 版本,新版本性能提升幅度约为 10% 到 30%。这一专项性能优化旨在进一步优化在小规格环境下的系统运行效率,提供更加出色的性能表现,确保用户能够充分利用小规格系统资源,享受更为流畅的使用体验。
2. 单日志流并行同步
在 4.2.2 版本之前,日志同步模型为不同日志流并行同步和处理,单日志流基于 Pipeline 方式同步。4.2.2 版本实现了基于文件数据块的单日志流并行同步模型,在显著提升备库异地部署等场景下同步性能的同时,也对内存的使用进行了优化。
3. OBKV RPC 压缩
在典型的互联网高并发压测场景中,查询请求通常占据相当大的比例。尽管机器的 CPU 资源充足,但由于带宽资源紧张,用户需要扩充多组 ODP。为解决这一问题,我们引入了 OBKV 查询请求回包的 RPC 消息压缩功能。该功能允许用户根据业务场景选择不同的压缩算法,并设置开始压缩的下限阈值。通过 RPC 消息压缩,客户端和服务端之间在带宽资源有限的情况下,能够显著减小网络传输数据的大小,降低网络带宽的消耗。
4. 强化旁路导入资源控制
OceanBase 4.x 版本引入的旁路导入功能极大提升了数据导入速率。然而,在用户设定较高并行度且并发执行多个旁路导入任务的情况下,缺乏对资源的严格控制可能会导致较多线程和内存占用,影响其他任务的正常执行。为解决这一问题,4.2.2 版本新增三个维度的旁路导入资源管理能力:
- 新增任务级资源申请管理模块,根据导入任务的执行模式和分区数量,申请对应的线程和内存资源。
- 新增租户级资源管理模块,用于管理租户在旁路导入中所需的线程和内存资源。通过定时任务,该模块能够感知资源池的变化,并回收异常中断的导入任务所申请的资源。
- 新增 OBServer 级资源管理模块,记录节点级资源的申请情况,并根据任务数动态伸缩旁路导入任务排序阶段的可用内存。
5. R 副本按 Region 级联:
自 OceanBase 4.2.0 版本支持 R 副本功能以来,该特性在弱读、复制表等场景受到很多用户的欢迎。R 副本通过注册为 F 副本或其他 R 副本的下游来同步日志,但当多个 R 副本及其上游被部署在不同的 Region 时,可能导致额外的跨 Region 网络带宽占用。为应对这一挑战,4.2.2 版本引入了 R 副本对 Region 的感知能力。在日志同步过程中,系统将优先选择同一 Region 的其他副本作为上游,以尽量避免跨 Region 的网络传输,从而有效节省跨 Region 带宽。
6. 分区局部索引空间优化
在之前的版本中,构建索引时通过系统内部执行 SQL 加载索引表数据,如果某个节点数据量很大,在排序过程中可能引起临时空间放大。4.2.2 版本支持了索引表补数据的渐进式执行,控制数据处理一批次大小,多机任务并行执行,这样在充分利用了分布式并行计算能力的同时,也解决了在索引构建过程中出现的临时空间放大问题。
7. JSON / XML 汇聚函数内存优化
新版本优化了 XMLAGG、JSON_OBJECTARRAY 等汇聚函数在执行过程中的内存消耗。这一优化措施旨在提升执行过程中的内存利用效率,使这些汇聚函数更为轻量化,从而在执行时减少对系统资源的占用。
(五)易用性提升
1. 性能诊断利器 - SQLSTAT
OceanBase 历史版本已提供通过 SQL AUDIT 和 PLAN STAT 来定位数据库性能问题的方式,但对于执行中的 SQL 或执行过去比较长时间的 SQL,缺少易用的定位手段。4.2.2 版本新增支持 SQLSTAT 功能,用于实时记录 SQL 执行状态和执行期间统计项信息。结合负载仓库(WR)功能,可以较容易地找到对性能影响很大的 TOP SQL,进一步实现诊断自动化。可通过 [G]V$SQLSTAT 视图查看当前所有 SQL 的基本性能统计数据,通过 CDB/DBA_WR_SQLSTAT 视图用于查看持久化后 TOP SQL 的性能统计信息。
2. 时间模型统计 - TIME MODEL
为了更加及时地反映数据库的负载情况,获取准确的数据库内执行耗时统计,4.2.2 版本支持了 SESSION 、TENANT 级别的时间统计模型。新增 DB time、DB CPU、non idle wait time、idle wait time、background elapsed time、backgroud cpu time、background database time、background database non-idle wait time、background database idle wait time 等 9 个指标,以此进行问题诊断和性能调优。可通过 [G]V$SYSSTAT 和 [G]V$SESSTAT 查看统计项信息,同时 WR 模块会以默认 1 小时间隔采集并持久化到 DBA_WR_SYSSTAT 视图中。
3. 手动转移分区
OceanBase 现有的自动负载均衡机制可以自动调整分区分布,以达到在线扩缩容和分区均衡的目的。不过实际业务场景中,用户有定制数据分布的需求,希望将特定的分区进行聚合或打散。4.2.2 版本新增转移(Transfer)分区功能,用户可以选择将特定的分区迁移到特定的日志流上,并提供任务状态查看能力。
4. 主备租户事件展示
OceanBase 4.2.2 版本之前,主备租户 SWITCHOVER、FAILOVER 等事件记录在 RS 事件中,RS 事件会随时间清理,且租户级记录混在集群操作记录中不易查找。4.2.2 版本将主备租户操作记录拆分到每个租户下,通过 CDB/DBA_OB_TENANT_EVENT_HISTORY 视图透出。
5. 网络备库复制角色
OceanBase 4.2.0 版本开始支持基于网络直连的物理备库(简称网络备库)。使用网络备库功能前,需要在主库配置一个复制专用账号,并赋予该账号一些视图的访问权限,用于备库在同步流程中能够访问主库相关信息。当前管理员共有 7 个视图需要授权,操作较为复杂。4.2.2 版本新增支持 Oracle 模式下网络备库复制角色,简化新建备库的操作。
6. PL & SQL 日志解耦
当前通过 PL 执行的 SQL 语句复用了 PL 的 trace_id,导致同一个 trace_id 关联的日志量过大,通过过滤日志排查问题比较耗费时间。4.2.2 版本将 PL 和 SQL 的日志解耦,为 PL 内部的 SQL 语句赋予独立的 trace_id,并在 SQL AUDIT 增加外层 PL trace_id 记录,有效提高问题排查效率。
7. PL 执行时间统计
业务场景中,可能会遇到 PL 执行性能不符合预期的情况,目前缺少易用的手段快速分析主要耗时在内部 SQL 还是 PL 结构本身。4.2.2 版本新增 PL 结构执行时间统计,可直接通过 [G]V$OB_SQL_AUDIT 视图的 PLSQL_EXEC_TIME 列来获取。
8. 执行计划和限流同时绑定
目前 OUTLINE 支持执行计划绑定和限流绑定两种功能,但不支持同时指定。考虑部分客户场景既需要干预执行计划,又需要对高流量 SQL 限流的需求,4.2.2 版本开始允许用户在一条创建 OUTLINE 的语句中指定 max_concurrent() 和其他 HINT 绑定。
9. 动态配置 LOB 存储模式
当前 LOB 数据小于等于 4KB 时,会 inrow 存储(即行内存储),大于 4KB 时,会存入 LOB 辅助表。不超过行级存储规格限制的前提下,部分场景相比于存入辅助表,inrow 整存整取性能更好。因此该版本提供动态配置能力,用户可根据业务需求动态调整 inrow 大小。