Version information

Information	Description
Release date	November 1, 2023
Version	V4.2.1_CE_BP1
Commit number	7cb0fb4
OBServer RPM version	oceanbase-ce-4.2.1.1-101000062023110109

Overview

• This version improved the compatibility of user-defined variables with MySQL Database.

• This version added two views GV$OB_KV_CONNECTIONS and V$OB_KV_CONNECTIONS to query all active connections of the current tenant in an OBKV database.

• The maximum length of the system variable ob_tcp_invited_nodes was changed to 64 KB.

• The default value of the ls_gc_delay_time parameter was changed to 0.

• This version addressed several customer and internal testing issues to enhance product stability.

Bug fixes

• Fixed the issue where Error 5150 was constantly reported because the tablet location cache of the auto-increment column was not refreshed after the number of units was adjusted for scaling.
• Fixed the issue in V4.x_CE where a 50 ms timeout limit was set when obtaining GTS snapshot versions, causing failure to successfully obtain Global Timestamp Service (GTS) snapshot versions in high-latency networks and continuous error OB_GTS_NOT_READY.
• Fixed the issue where using the HBaseAPI of the OBKV client for batch PUT operations could potentially cause OBServer node crashes.
• Fixed the issue where performing InsertOrUpdate operations on the OBKV client with a column specified as the time-to-live (TTL) column using CURRENT_TIMESTAMP could cause OBServer node crashes.
• Fixed the issue where a core dump might be triggered when the SUBPLAN FILTER (SPF) operator is used for batch rescan. A parameter was added to disable this feature by default.
• Fixed the issue where SQL statements in user-defined functions (UDFs) failed to hit the plan cache when tx_read_only is set to True.
• Fixed the issue where Error 4002 was reported in PS mode when the default value NULL of a complex data type is used as an input parameter of a stored procedure.
• Fixed the issue where some parallel DML (PDML) features might not take effect in multi-table joins.
• Fixed the issue where memory leak ocurred in the TenantTTLMgr module after TTL tasks were executed in the HBase storage model.
• Fixed the potential issue of data and load imbalance after importing data into non-partitioned tables during parallel table creation.

版本信息

项目	描述
发布日期	2023-11-01
版本号	V4.2.1_CE_BP1
Commit 号	7cb0fb4
OBServer RPM 版本号	oceanbase-ce-4.2.1.1-101000062023110109

发版目的

• 提升用户自定义变量与 MySQL 数据库的兼容性。
• OBKV 新增视图 GV$OB_KV_CONNECTIONS、V$OB_KV_CONNECTIONS 用于查看本租户所有的 KV 活跃连接。
• 系统变量 ob_tcp_invited_nodes 长度限制调整为 64K。
• 配置项 ls_gc_delay_time 默认值调整为 0。
• 解决客户及内部测试遇到的问题，提升版本稳定性。

缺陷修复

• 修复调整 Unit Number 进行扩缩容后，自增列的 Tablet location cache 没有刷新，导致持续报错 5150 的问题。
• 修复 4.x_CE 版本在获取 GTS 快照版本时设置了 50ms 的超时限制，导致在高延迟网络下无法成功获取 GTS 快照版本，查询持续报错 OB_GTS_NOT_READY 的问题。
• 修复使用 OBKV 客户端的 HBaseAPI 进行批量 PUT 操作时，可能导致节点宕机的问题。
• 修复 OBKV 指定带 CURRENT_TIMESTAMP 的列作为 TTL 过期列时，使用 OBKV 客户端执行 InsertOrUpdate 操作导致节点宕机的问题。
• 修复 SPF 算子进行 Batch Rescan 场景下可能触发的 Core 问题，新增开关默认关闭该功能。
• 修复 tx_read_only 设置为 True 的情况下，UDF 内部 SQL 无法命中 Plan Cache 的问题。
• 修复 PS 模式下，复杂类型作为存储过程入参且默认值为 NULL 时，使用默认值报错 4002 的问题。
• 修复多表关联场景下，部分 PDML 功能可能不生效的问题。
• 修复 Hbase 存储模型执行 TTL 任务后，TenantTTLMgr 模块内存泄漏问题。
• 修复非分区表并行建表导入数据后，可能存在数据和负载不均衡的问题。

Version information

Information	Description
Release date	October 13, 2023
Version	V4.2.1_CE
Commit number	7b0f436
OBServer RPM version	oceanbase-ce-4.2.1.0-100000102023092807

Overview

OceanBase Database V4.2.1_CE is the first Long-Term Support (LTS) version of the V4.2.x_CE series. This version comes with a range of MySQL-compatible features, such as the VALUES statement and JSON_TABLE expression. It also introduced the Workload Repository (WR)-based data collection framework and enhanced end-to-end diagnostic capabilities for commercialization. In addition, this version optimized system resource utilization and supports table-level restore and Tencent Cloud Object Storage (COS). This version is recommended in production environments for regular business operations.

Key features

Compatibility with MySQL

• VALUES statement

  The VALUES statement was introduced in MySQL 8.0.19. It can be used to quickly construct a table of data or as a standalone DML statement with support for ORDER BY and Limit clauses. It can also be used as a special table in regular DML statements. OceanBase Database V4.2.1_CE is compatible with MySQL Database and supports the VALUES statement, making table value construction more convenient and easy to use.

• RENAME COLUMN

  The RENAME COLUMN syntax was supported since MySQL 8.0. It allows users to rename columns without changing their definitions, which is more lightweight than the CHANGE COLUMN syntax. OceanBase Database is compatible with the RENAME COLUMN syntax of MySQL 8.0 since V4.2.1_CE.

OBKV features

• JSON_TABLE expression

  JSON is a semi-structured data format where users can extract specific values from the JSON strings based on a path. The JSON_TABLE expression allows users to convert semi-structured data into structured data. The earlier versions of OceanBase Database already supported the JSON data type, but the JSON_TABLE expression was not implemented under the MySQL mode. To meet the needs of users who want to convert JSON data into structured data for computations, V4.2.1_CE also supports this expression under the MySQL mode.

• OBKV TTL

  Time-to-live (TTL) is a commonly used feature in NoSQL databases, designed to automatically expire data. For example, in businesses that deal with historical data, there is a need to periodically scan the data, determine its expiration time, and delete it accordingly. Many businesses currently rely on the TableAPI of OBKV. To simplify the management of periodic data, OceanBase Database provided the OBKV TTL capability since V4.2.1_CE. Users can define TTL attributes at the table or row level using the CREATE TABLE statement so that expired data is not processed during read and write operations in OBKV.

Performance improvements

• Concurrent execution of CREATE TABLE

  In the earlier versions of OceanBase Database, DDL requests were executed serially in RootService queues. Starting from OceanBase Database V4.1.0_CE, the concurrent DDL capability was introduced, with support for concurrent execution of TRUNCATE TABLE. To address the performance issues related to migrating millions of table structures, V4.2.1_CE now supports concurrent execution of CREATE TABLE, providing a performance improvement of tenfold or even more compared with serial execution.

• Improved foreign key check performance

  Prior to OceanBase Database V4.2.1_CE, foreign key checks were implemented using nested SQL statements, incurring significant overhead. From V4.2.1_CE, foreign key checks are performed using Database Autonomy Service (DAS) tasks, and batch checks in single-table DML operations is supported. Additionally, with the check result caching strategy, noticeable performance improvements have been achieved in INSERT and UPDATE scenarios. In a single-node scenario (where the parent table and child table are on the same node), the performance degradation caused by foreign key checks during INSERT and UPDATE operations on foreign key tables is generally controlled to around 10% compared with tables without foreign keys. In a distributed scenario (where the parent table and child table are on different nodes), the performance degradation is generally controlled to around 30% compared with tables without foreign keys during INSERT and UPDATE operations.

• Dynamic sampling on MemTables

  OceanBase Database V4.2.0_CE introduced the dynamic sampling feature, which samples data during the generation of an execution plan. When the number of rows in the SSTable exceeds that in the MemTable, dynamic sampling is performed on SSTable blocks. When the number of rows in the MemTable exceeds that in the SSTable, dynamic sampling is performed on the MemTable. In V4.2.0_CE, this was achieved through full read of the MemTable, which was relatively inefficient. However, in V4.2.1_CE, direct sampling for the MemTable is implemented, utilizing RANGE partitioning to perform interval reads. This enhancement significantly improves the efficiency of dynamic sampling on the MemTable.

• Parallel read of archived logs

  In OceanBase Database V4.1.0_CE, OceanBase Change Data Capture (CDC) can consume archived logs through the CDC service or directly consume logs from the archive destination. In V4.2.0_CE, a network-based standby database reuses the log pulling framework of OceanBase CDC to pull logs from the primary database by using the CDC service. After the CDC service receives a log pulling remote procedure call (RPC) request from OceanBase CDC or a network-based standby database, the service first attempts to read logs from the local disk. If the corresponding logs do not exist in the local disk due to reasons such as log stream garbage collection (GC) or log recycling, and if the tenant has enabled log archiving, the CDC service reads logs from the log archive destination, such as the network file system (NFS) or Alibaba Cloud Object Storage Service (OSS). The log reading performance of the CDC service determines the log consumption speed at the downstream. If the performance of the CDC service in reading archived logs from OSS is poor, the synchronization link or the network-based standby database may lag behind the primary database and may be unable to become synchronized with the primary database. To address this issue, V4.2.1_CE allows the CDC service to consume OSS-archived log files based on the basic capability of parallel consumption of OSS files.

Resource optimization

This version optimized the utilization of system resources in public cloud environments, including user tenant memory, memory of the SYS500 tenant, and operating system memory. For example, for Elastic Compute Service (ECS) instances with specifications of 128 GB or higher, the memory utilization of system resources has been reduced from around 30% to approximately 15%.

High availability enhancement

• Table-level restore

  Prior to OceanBase Database V4.2.1_CE, tenant-level data restore was supported. If data within a table was damaged due to a misoperation, users needed to rely on the physical restore feature to restore the tenant to a previous point in time or use the import/export feature for table-level restore. V4.2.1_CE added support for table-level restore, allowing users to specify which backup data to use, which databases or tables to restore, which tenant to operate on, and the desired recovery point in time on the target cluster.

• Support for COS

  OceanBase Database V4.1.0_CE supports OSS as the backup media. OceanBase Database V4.2.1_CE supplements this support by allowing users to back up logs and data to COS and read backup data from COS for data restore.

Security enhancement

Data integrity protection: The Security Assessment of Commercial Cryptography Application imposes requirements for confidentiality and integrity protection on stored data in information systems. In the versions earlier than V4.2.1_CE, the transparent encryption feature of OceanBase Database has already supported AES_ECD and SM4_CBC (which are named in the format of encryption algorithm_encryption mode), providing confidentiality protection for stored data. V4.2.1_CE added support for the GCM mode. In addition to data encryption, the checksum of ciphertext is calculated based on the key, and the ciphertext is checked during decryption to determine whether the ciphertext has been changed, thereby protecting data integrity.

Diagnostic capabilities improvement

• WR-based data collection framework

  The ease of use of the database performance diagnostics feature is closely related to the efficiency of system tuning. Oracle Database 10g introduces proactive automatic diagnostic capabilities such as Active Session History (ASH), Automatic Workload Repository (AWR), and Automatic Database Diagnostic Monitor (ADDM), and provides an inside-out (with information collected by internal components) and top-down (based on the database time and other metrics) database optimization and analysis framework. After decades of development, these capabilities have become industry benchmarks. OceanBase Database V4.2.1_CE implements a data collection framework similar to AWR of Oracle Database. The framework collects existing data such as ASH reports, statistics, wait events, and SQL execution details, and periodically persists performance-related views of OceanBase Database. OceanBase Database V4.2.1_CE introduces WR views and supports configuration adjustment and snapshot management by using DBMS_WORKLOAD_REPOSITORY packages. The new version also unifies, streamlines, enriches, and enhances SYSSTAT, ASH, and other statistical metrics for higher comprehensiveness and accuracy. The performance diagnostic capabilities will be further enhanced in future OceanBase Database versions.

• Enhanced ASH feature

  The ASH feature was introduced in OceanBase Database V4.0.0_CE. It samples the status of all active sessions in the system at an interval of 1 second and records the information in internal tables. In OceanBase Database V4.2.1_CE, additional sampling points related to transactions, storage, and DAS were added. The ASH data is collected into the WR internal table at a default sampling rate of 10:1 and a collection interval of 1 hour. By analyzing ASH data, you can easily identify issues such as long wait events, slow SQL statements, and resource utilization of active sessions, which helps in performance optimization.

• End-to-end diagnostics feature

  OceanBase Database V4.2.0_CE supports visualized end-to-end tracing of SQL requests, and in V4.2.1_CE, the configuration management capability for end-to-end diagnosis is further enhanced. A new view GV$OB_FLT_TRACE_CONFIG is added to record the configuration policies for end-to-end diagnostics at different levels. The GV$OB_PROCESSLIST view now includes LEVEL, SAMPLE_PERCENTAGE, and RECORD_POLICY columns to display the monitoring level, sampling frequency, and recording/printing policy that are effective for each session. Additionally, the GV$OB_SQL_AUDIT view includes a new column FLT_TRACE_ID to record the end-to-end trace information, enabling comprehensive SQL tracing. OceanBase Cloud Platform (OCP) will also provide corresponding page functionality to support this feature.

Product behavioral changes

The following table describes the product behavioral changes made in this version.

Feature	Change description
Triggers disabled for the LOAD DATA statement	The LOAD DATA statement is executed in parallel for fast data import. When parallel execution involves triggers, trigger correctness issues may occur. Therefore, triggers are disabled for the LOAD DATA statement in OceanBase Database V4.2.1_CE.
Semantic change for tenant=all	In the versions earlier than OceanBase Database V4.2.1_CE, the semantics of tenant=all was ambiguous. For example, tenant=all indicates all tenants in system parameter settings, but indicates user tenants in backup and restore settings. Since OceanBase Database V4.2.1_CE, the semantics of tenant=all is changed and specifies "to include only all user tenants and to exclude SYS and META tenants". tenant=all_user and tenant=all_meta are added, which respectively indicate all user tenants and all META tenants. After the change, tenant=all and tenant=all_user share the exact same semantics. Therefore, tenant=all will be deprecated in future versions.
Refined load balancing control	OceanBase Database V4.2.0_CE introduced the load balancing and transfer capabilities, which are specified by the tenant-level parameter enable_rebalance. However, when the enable_rebalance parameter is disabled, you cannot modify unit_num, primary_zone, and other parameters in O&M commands. OceanBase Database V4.2.1_CE introduced the tenant-level parameter enable_transfer, which allows you to disable the transfer feature for a tenant. You can use it with the enable_rebalance parameter to control the load balancing strategy for a tenant. enable_rebalance=true and enable_transfer=true: specify to dynamically adjust the number of log streams for a tenant based on the load balancing algorithm and automatically perform leader balancing and partition balancing for the tenant. enable_rebalance=true and enable_transfer=false: specify not to dynamically adjust the number of log streams or perform transfer but only to perform log stream balancing based on existing log streams. enable_rebalance=false and enable_transfer: invalid. In this case, no load balancing related O&M commands are allowed.
Case sensitivity in OceanBase CDC	OceanBase CDC is case insensitive in the versions earlier than V4.2.1_CE. The new version supports case sensitivity. The database and table names are output according to the setting of the lower_case_table_names parameter, whose valid values are 0, 1, and 2.
Transport Layer Security (TLS) protocol version for SSL encryption	In the versions earlier than V4.2.1_CE, there were no restrictions on the TLS protocol version for SSL encryption. Therefore, clients can use the TLS protocol of an early version for encrypted communication with databases. However, some scenarios require TLS1.2 and TLS1.3 for higher security. For compatibility with clients of earlier versions, OceanBase Database V4.2.1_CE introduces the sql_protocol_min_tls_version parameter, which allows you to specify the minimum version of the TLS protocol. The default value is compatible with previous versions.
Calling a stored procedure with an output parameter without returning a result set	MySQL allows you to call a stored procedure with an output parameter without returning the result set of the output parameter. In the versions earlier than OceanBase Database V4.2.1_CE, a result set of an output parameter is returned, causing the native MySQL driver to report an error. In OceanBase Database V4.2.1_CE, after you execute a CALL statement by using OBClient, the result set of the output parameter is no longer displayed.
zlib compression disabled	In OceanBase Database V4.2.1_CE, you cannot use zlib compression for new tables or change the compression algorithm of an existing table to zlib.

View changes

The following table describes the changes to views made in this version.

View	Change type	Description
CDB/DBA_WR_CONTROL	New	Stores WR-related configurations.
[G]V$OB_TENANT_RUNTIME_INFO	New	Displays the running details of tenants.
[G]V$OB_SQL_AUDIT	Modified	The FLT_TRACE_ID column is added to record end-to-end trace information.

Parameter changes

The following table describes the parameter changes made in this version.

Parameter	Change type	Description
memory_limit_percentage	Modified	The upper limit of the percentage of available memory for OBServer nodes is changed from 90% to 95%. OBServer nodes are allowed to use a higher percentage of resources in servers with high specifications.
sql_protocol_min_tls_version	New	The minimum version of the SSL/TLS protocol used by SSL connections for SQL statements. This is a cluster-level parameter. The default value is none, which means there are no restrictions on the TLS version for connections. NoteThis parameter controls only the version number of SSL. To enable SSL, you must set the ssl_client_authentication parameter.
enable_transfer	New	Specifies whether to allow transfer within the tenant. This is a tenant-level parameter. This parameter is invalid when enable_rebalance is disabled. The default value is True, which indicates that transfer within the tenant is allowed.
compaction_dag_cnt_limit	New	The maximum number of directed acyclic graphs (DAGs) in a compaction DAG queue. This parameter is a tenant-level parameter. The default value is 15000. In scenarios with millions of partitions, you can increase the value of this parameter to speed up compaction, which however increases memory consumption.
compaction_schedule_tablet_batch_cnt	New	The maximum number of partitions that can be scheduled in each batch for batch compaction scheduling. This parameter is a tenant-level parameter. The default value is 50000. In scenarios with millions of partitions, you can increase the value of this parameter to speed up compaction, which however increases CPU consumption and results in longer thread scheduling time.
server_cpu_quota_min	Modified	The default value is changed from 1 to 0, and the value range is changed to [0, 16]. The value 0 indicates that the specifications of the sys tenant are adaptive.
server_cpu_quota_max	Modified	The default value is changed from 1 to 0, and the value range is changed to [0, 16]. The value 0 indicates that the specifications of the sys tenant are adaptive.

Recommended versions of tools

The recommended platform tool versions for OceanBase Database V4.2.1_CE are described in the following table:

Tool	Version
OceanBase Database Proxy (ODP)	V4.2.1
OCP	V4.2.0
OceanBase Deployer (OBD)	V2.3.1
OceanBase All in One	V4.2.1
OceanBase Developer Center (ODC)	V4.2.2
OceanBase CDC	V4.2.1
OceanBase Migration Service (OMS)	V4.2.0
OBClient	V2.2.3
OceanBase Connector/C	V2.2.3

Upgrade notes

• An online upgrade of OceanBase Database Community Edition from V4.2.0_CE to V4.2.1_CE is supported.
• An online upgrade of OceanBase Database Community Edition from V4.1.0_CE to V4.2.1_CE is supported.
• We recommend that you upgrade OceanBase Database before you upgrade ODP.
• During the upgrade, the system automatically disables major compactions and DDL operations. After the upgrade is complete, the system resumes normal operation.
• An online upgrade of OceanBase Database Community Edition from V3.x_CE to V4.2.1_CE is not supported.
• You can upgrade OceanBase Database Community Edition from V3.x_CE to V4.2.1_CE through logical data migration by using OMS.

版本信息

项目	描述
发布日期	2023-10-13
版本号	V4.2.1_CE
Commit 号	7b0f436
OBServer RPM 版本号	oceanbase-ce-4.2.1.0-100000102023092807

版本定位

OceanBase 数据库 V4.2.1_CE 版本是 V4.2.x_CE 版本系列的第一个长期支持版本（LTS），该版本新增了 VALUES 语句、JSON_TABLE 表达式等与 MySQL 兼容的功能，推出了 WR 数据采集框架和增强全链路诊断的产品化。同时，该版本还优化了系统资源的使用，并增加了表级恢复能力和对备份介质 COS 的支持。推荐将其用于常规业务的生产环境中。

关键特性说明

MySQL 兼容

• VALUES Statement

  MySQL 8.0.19 引入 VALUES Statement。它可以用于快速地构建一组数据的 “表”；可以作为独立 DML 语句，支持配合 ORDER BY 和 Limit 使用；也可以作为特殊的 “表” 混合到普通的 DML 语句中。OceanBase 数据库 V4.2.1_CE 版本兼容 MySQL 模式支持了 VALUES Statement 功能，使得表值构造更加便捷易用。更多信息请参见 VALUES Statement。

• Rename Column

  MySQL 数据库从 8.0 开始支持 RENAME COLUMN 语法，方便用户在不改变列定义的前提下为列重新命名，比 CHANGE COLUMN 更加轻量。OceanBase 数据库从 V4.2.1_CE 版本开始兼容 MySQL 8.0 RENAME COLUMN 的语法。更多信息请参见 RENAME COLUMN。

多模特性

• JSON_TABLE 表达式

  JSON 是一种半结构化数据，用户可根据 Path 从 JSON 中抽取特定的 Value 值，也可通过 JSON_TABLE 表达式将半结构化数据转为结构化数据。OceanBase 数据库早期版本已经支持 JSON 数据类型，但 MySQL 模式下尚未实现 JSON_TABLE 表达式。为了解决部分用户将 JSON 转结构化数据参与运算的需求，V4.2.1_CE 版本在 MySQL 模式下也支持该表达式。详细使用说明见 JSON_TABLE。

• OBKV TTL

  TTL（Time To Live）是 NoSQL 数据库比较常用的功能，主要用于数据的自动过期老化。例如历史库业务, 需要周期性扫描数据, 判断过期时间，删除数据。目前有很多业务依赖 OBKV 的 Table 模型，为了方便周期数据管理，OceanBase 数据库从 V4.2.1_CE 版本支持了 OBKV TTL 能力。用户可通过建表语句定义表级/行级的 TTL 属性，做到 OBKV 读写不感知过期数据。更多信息请参见 TTL。

性能提升

• 并发 CREATE TABLE

  OceanBase 数据库早期版本 DDL 为串行设计，DDL 请求在 RootService 队列中串行执行。OceanBase 数据库 V4.1.0_CE 版本开始提供并发 DDL 能力，并支持了 TRUNCATE TABLE 的并发执行。为了解决百万表结构迁移的性能问题，V4.2.1_CE 版本支持了并发 CREATE TABLE，相对串行执行，带来十倍甚至数十倍的性能提升。

• 外键检查性能优化

  OceanBase 数据库 V4.2.1_CE 版本之前，外键检查采用 INNER SQL 实现，开销较大。V4.2.1_CE 版本开始，通过 DAS TASK 进行外键查询，并支持单表 DML 的外键查询批处理，同时结合外键检查结果缓存策略，在 INSERT/UPDATE 场景下有明显性能提升。在单机场景下（父表和子表分布在同一台机器），和无外键表相比，外键表 INSERT/UPDATE 进行外键检查带来的性能回退基本可控制在 10% 左右；在分布式场景下（父表和子表分布在不同机器），和无外键表相比，外键表 INSERT/UPDATE 进行外键检查带来的性能回退基本可控制在 30% 左右。

• MemTable 支持动态采样

  OceanBase 数据库 V4.2.0_CE 版本支持了一种在执行计划生成阶段对数据做采样的优化方案，即动态采样特性。当 SSTable 中的行数大于 MemTable 时，动态采样会选择使用 SSTable 的块采样。反之，当 MemTable 中的行数大于 SSTable 时，选择对 MemTable 做采样。V4.2.0_CE 版本是通过 MemTable 全量读取来实现的，效率相对较低，V4.2.1_CE 版本实现了 MemTable 的直接采样功能，通过 Range 切分完成区间读，使得 MemTable 动态采样更加高效。

• 并行读取归档日志

  在 OceanBase 数据库 V4.1.0_CE 版本，OBCDC 支持了通过 CDCService 消费归档日志以及直接消费归档目的端的日志。在 V4.2.0_CE 版本中，网络直通备库复用了 CDC 拉取日志的协议框架，通过 CDCService 来拉取主库上的日志。CDCService 收到 OBCDC 或网络备库的拉取日志 RPC 请求后，会先尝试从本地磁盘上读取日志，如果因为日志流 GC 或者日志回收等原因，本地磁盘中对应的日志不存在，且租户开启了归档日志，那么 CDCService 便会读取归档目的端（如 NFS 或 OSS）上的日志。CDCService 读取日志的性能决定了下游消费日志的速率，如果读取 OSS 中的归档日志性能较差，可能导致同步链路或网络备库延时且难以追上。因此，基于并行消费 OSS 文件的基础能力，V4.2.1_CE 版本新增支持了 CDCService 并行消费 OSS 归档日志文件的功能。

资源优化

系统资源优化：该版本专项优化了公有云系统资源使用，包括用户租户内存、500 租户内存、操作系统内存等，典型的 128G 规格及以上的 ECS，系统资源使用的内存比例从 30% 降到 15% 左右。

高可用增强

• 表级恢复

  OceanBase 数据库 V4.2.1_CE 版本之前，支持租户级数据恢复，如果误操作导致表的数据损坏，需要使用数据库的物理恢复功能将租户恢复到损坏之前的某个时间点，或者依赖导入导出功能实现表级数据恢复。新版本增加了对表级恢复功能的支持，用户可以在目标集群上指定使用哪个备份数据，恢复哪些库或表，在哪个租户下，以及恢复到哪个时间点。详细使用说明见 表级恢复。

• 备份介质 COS

  OceanBase 数据库 V4.1.0_CE 版本已支持 OSS 备份介质，V4.2.1_CE 版本补充支持 COS 备份介质。用户可将日志和数据信息备份到腾讯云的对象存储 COS 中，并支持从 COS 上读取备份数据完成数据恢复。

安全强化

数据完整性保护：信息系统商用密码应用安全性评估（简称密评）中对存储有数据的机密性和完整性保护要求。V4.2.1_CE 之前版本，OceanBase 数据库透明加密已支持 AES_ECD、SM4_CBC（加密算法_工作模式），对存储数据提供了机密性保护。V4.2.1_CE 版本扩展支持了 GCM 模式。在对数据加密的基础上，结合密钥计算密文的校验和，在解密时对密文做校验，判断密文是否发生变化，以支持数据的完整性保护。

诊断能力提升

• WR 数据采集框架

  数据库性能诊断的易用性直接影响了系统的调优效率。Oracle 数据库自 10g 起，提供了 ASH、AWR、ADDM 等自诊断的重要特性，提供了由内而外（不由外部组件采集）、自顶向下（DB Time）的数据库优化分析框架，经过几十年发展，已经成为行业标杆。OceanBase 数据库 V4.2.1_CE 版本开始实现了类似 Oracle AWR 的数据采集框架，对已有的 ASH、统计、等待事件、SQL 执行详情等数据进行采集，周期性地持久化 OceanBase 数据库性能相关视图。提供了 WR 视图供用户查询，支持通过 DBMS_WORKLOAD_REPOSITORY 包进行配置调整和快照管理。同时，新版本对 SYSSTAT、ASH 等统计指标进行了统一梳理、补充和强化，使之更加全面和精准。后续的版本也会在此基础上逐步提升 OceanBase 数据库的性能诊断能力。更多信息请参见 WR 概述。

• ASH 特性增强

  Active Session History(ASH) 是 OceanBase 数据库 V4.0.0_CE 版本引入的新特性，它能够以 1 秒为周期采样系统中所有 Active Session 状态，并记录进内部表中。在 V4.2.1_CE 版本更进一步，增加了事务、存储、DAS 相关采样点，并将 ASH 数据以 10:1 的采样率默认 1 小时为周期收集到 WR 内部表中。通过分析 ASH 数据，我们可以方便定位到长时间等待事件、慢 SQL 语句、活动会话的资源利用率等问题，从而进行性能优化。

• 全链路诊断产品化

  OceanBase 数据库 V4.2.0_CE 版本已支持 SQL 请求的可视化全链路追踪，在此基础上 V4.2.1_CE 版本完善了全链路诊断的配置管理能力。新增 GV$OB_FLT_TRACE_CONFIG 视图，用于记录全链路诊断的各级别配置策略。在 GV$OB_PROCESSLIST 视图增加 LEVEL、SAMPLE_PERCENTAGE、RECORD_POLICY 列，用于展示 SESSION 上生效的监控级别、采样频率、记录打印策略等。同时在 GV$OB_SQL_AUDIT 视图中也新增了 FLT_TRACE_ID 列，记录全链路 TRACE 信息，做到 SQL 全方位追踪。OCP 也会配套提供页面功能。

产品行为变更

新增如下变更：

功能	变更点说明
Load Data 禁用 Trigger	Load Data 并行执行，用于快速导入数据。并行执行和 Trigger 正交场景，可能存在 Trigger 正确性问题，因此在 V4.2.1_CE 版本已禁用。
tenant = all 语义变更	V4.2.1_CE 版本之前，tenant=all 语义不明确，在具体的使用场景，如配置项设置代表所有租户，备份恢复代表用户租户。V4.2.1_CE 版本开始，修改 tenant=all 语义，改为 “仅包括所有用户租户，排除 SYS 和 META 租户”。新增语法，tenant=all_user，tenant=all_meta，分别对应所有用户租户和所有 META 租户。修改后，tenant=all 和 tenant=all_user 的语义完全相同，并计划在后续版本废弃 tenant=all 用法。
负载均衡开关细化	V4.2.0_CE 版本新增负载均衡与 Transfer 能力，可通过租户级配置项 enable_rebalance 进行控制。但 enable_rebalance 关闭时，也限制了用户 unit_num、primary_zone 等运维命令的修改，使用不够方便。 V4.2.1_CE 版本新增租户级配置项 enable_transfer，提供单独关闭租户下 Transfer 功能，与 enable_rebalance 共同控制租户均衡策略。enable_rebalance=true, enable_transfer=true：根据负载均衡算法动态调整租户日志流数量，自动进行租户下的 Leader 均衡和分区均衡。 enable_rebalance=true, enable_transfer=false：不会产生 Transfer 和日志流数量动态变化，只在现有日志流基础上尽量做日志流均衡。 enable_rebalance=false, enable_transfer 无效： 不允许任何负载均衡相关运维命令。
OBCDC 大小写敏感	OBCDC 在 V4.2.1_CE 版本之前不区分大小写，新版本开始会支持大小写敏感策略。按照 lower_case_table_names=0/1/2 对应输出正确的库、表的大小写样式。
SSL 通信加密使用的 TLS 版本	在 V4.2.1_CE 版本之前，SSL 通信加密使用的 TLS 版本号没有限制，这意味着客户端可以通过较低版本号的 TLS 协议与数据库进行加密通信。然而，某些场景需要更高安全性的 TLS1.2 和 TLS1.3 协议。为了兼容旧版本客户端的需求，从 V4.2.1_CE 版本开始，可以通过配置项 sql_protocol_min_tls_version 来指定所使用的 TLS 协议的最低版本号。默认行为与之前的版本兼容。
调用带出参的存储过程不返回结果	MySQL 调用带出参的存储过程，返回结果不返回出参结果集。 V4.2.1_CE 版本之前会返回出参结果集，导致原生 MySQL 驱动执行报错。 V4.2.1_CE 版本进行了 MySQL 行为兼容，通过 OBClient 执行 CALL 语句后，不会再展示出参结果集。
禁用 zlib 压缩	V4.2.1_CE 版本禁止新建表使用 zlib 压缩，禁止已存在的表改成 zlib 压缩算法。

视图变更

新增如下变更：

视图	变更类型	变更说明
CDB/DBA_WR_CONTROL	新增	用于存储 WR 相关配置。
[G]V$OB_TENANT_RUNTIME_INFO	新增	用于展示租户运行详情。
[G]V$OB_SQL_AUDIT	新增列	新增 FLT_TRACE_ID 列，记录全链路 TRACE 信息。

配置项变更

新增如下变更：

配置项	变更类型	变更说明
memory_limit_percentage	修改取值范围	将 OBServer 可用的内存比例上限从 90% 调整到 95%。大规格机器，允许 OBServer 使用更多资源。
sql_protocol_min_tls_version	新增	集群级配置项，用于设置 SQL 语句进行 SSL 连接时，使用的 SSL/TLS 协议的最低版本号。默认为 none，表示不对连接使用的 LTS 版本号进行限制。说明该配置项只是对于 SSL 选择的版本号进行控制，具体开启 SSL 还是需要通过 ssl_client_authentication 设置。
enable_transfer	新增	租户级配置项，用于控制是否允许在租户内进行 Transfer。关闭配置项 enable_rebalance 时此配置项无效。默认为 True，表示开启。
compaction_dag_cnt_limit	新增	租户级配置项，配置 Compaction DAG 队列的 DAG 数量上限。默认为 15000。在百万分区场景，调大该配置项，可以适当提高 Compaction 速度，但会多占用一些内存。
compaction_schedule_tablet_batch_cnt	新增	租户级配置项，配置 Compaction 分 Batch 调度时，每个 Batch 调度的分区数上限。默认为 50000。在百万分区场景，调大该配置项，可以适当提高 Compaction 速度，但调度线程工作时间会变长，CPU 占用会更高。
server_cpu_quota_min	修改默认值/取值范围	默认值从 1 变更为 0，取值范围变更为 [0, 16]。取值为 0 时，代表 sys 租户规格自适应调整。
server_cpu_quota_max	修改默认值/取值范围	默认值从 1 变更为 0，取值范围变更为 [0, 16]。取值为 0 时，代表 sys 租户规格自适应调整。

周边配套

OceanBase 数据库 V4.2.1_CE 版本推荐使用的平台工具版本如下：

组件	版本
ODP	V4.2.1
OCP	V4.2.0
OBD	V2.3.1
All in One	V4.2.1
ODC	V4.2.2
OBCDC	V4.2.1
OMS	V4.2.0
OBClient	V2.2.3
LibOBClient	V2.2.3

升级说明

• 支持 OceanBase 数据库 V4.2.0_CE 版本在线升级到 OceanBase 数据库 V4.2.1_CE 版本。
• 支持 OceanBase 数据库 V4.1.0_CE 版本在线升级到 OceanBase 数据库 V4.2.1_CE 版本。
• OceanBase 数据库和 ODP 升级顺序：建议先升级 OceanBase 版本，再升级 ODP 版本。
• 升级期间，系统会自动禁用合并和 DDL 操作，升级完成后恢复正常使用。
• 不支持从 OceanBase 数据库 V3.x_CE 版本在线升级到 OceanBase 数据库 V4.2.1_CE 版本。
• 支持通过 OMS 将 OceanBase 数据库 V3.x_CE 版本数据使用逻辑迁移升级到 OceanBase 数据库 V4.2.1_CE 版本。

Version information

Information	Description
Release date	October 8, 2023
Version	V4.1.0_CE_BP4_HF1
Commit number	c8a22da
OBServer RPM version	oceanbase-ce-4.1.0.2-104010012023100710

Overview

This version addressed several customer and internal testing issues to enhance product stability.

Bug fixes

Fixed the issue where the query results might be incorrect when the query plan included the EXCHANGE OUT DISTR (PKEY) field. This issue occurred when parallel JOIN operations were performed on partitioned tables during the upgrade where multiple versions were running at the same time.

版本信息

项目	描述
发布日期	2023-10-08
版本号	V4.1.0_CE_BP4_HF1
Commit 号	c8a22da
OBServer RPM 版本号	oceanbase-ce-4.1.0.2-104010012023100710

发版目的

解决客户及内部测试遇到的问题，提升版本稳定性。

缺陷修复

修复在升级期间（不同版本同时运行），对分区表并行执行 JOIN 操作的场景下，当查询计划中包含 EXCHANGE OUT DISTR (PKEY) 时，查询结果可能不正确的问题。

Version information

Information	Description
Release date	September 25, 2023
Version	V4.1.0_CE_BP4
Commit number	6059cef

Overview

This version addressed several customer and internal testing issues to enhance product stability.

Bug fixes

• Fixed the issue where a size overflow problem might occur in a SQL statement if there were a large number of OR conditions or if a large number of OR conditions were generated after the SQL statement was rewritten.
• Fixed the issue where the index skip scan plan was used to query partitioned tables due to inaccurate statistics, resulting in memory bloat in the TableRescanCtx module.
• Fixed the issue where new backup tenants might encounter a request queue backlog problem during the switchover between primary and backup nodes.
• Fixed the issue where there was an inconsistency between the data obtained through vectorized table scan and non-vectorized table scan due to vectorized decoding exceptions.
• Fixed the issue where after creating a function index, if the result of the function index expression depended on system variables, Error 4377 might be reported when modifying the system variables and then performing update or delete operations. Added Error code 5500 to distinguish this type of issue.
• Fixed the issue where a disconnection problem might occur during the upgrade from OceanBase Database Community Edition V4.1.0 to V4.2.0. If the source version is earlier than V4.1.0 BP4, this issue can be avoided by first upgrading OceanBase Database and then upgrading OceanBase Database Proxy (ODP).
• Fixed the issue where the disk space calculation error after migration caused the unit to be migrated back and forth.
• Fixed the issue where OBKV failed to use local indexes for queries when partitioned tables were used.
• Fixed the issue of continuous reporting of Error 4013 and inability to successfully refresh the schema when the OBServer node was restarted. The cause of this issue was that the number of records in the __all_virtual_table_history table of a tenant in the cluster exceeded 4 million.
• Fixed the following issue: When performing a Partition Wise Join operation on two partitioned tables with slightly different partitioning methods, but with the same partitioning method after partition pruning, different results might be returned under different degrees of parallelism.
• Fixed the issue where MySqlConnector (a .NET driver) encountered an error when connecting to OceanBase Database and executing statements related to stored procedure.

版本信息

项目	描述
发布日期	2023-09-25
版本号	V4.1.0_CE_BP4
Commit 号	6059cef

发版目的

解决客户及内部测试遇到的问题，提升版本稳定性。

缺陷修复

• 修复在 SQL 语句中，当包含大量 OR 条件或进行改写后产生大量 OR 条件的场景下，可能会触发 Size Overflow 的问题。
• 修复在统计信息不准确的情况下，分区表可能会出现查询错误选择了 Index skip scan 计划，导致 TableRescanCtx 模块内存膨胀的问题。
• 修复在主节点和备节点切换的过程中，可能出现新的备租户请求队列积压的问题。
• 修复向量化解码异常可能导致的，Table Scan 向量化查到的数据和非向量化不一致的问题。
• 修复创建函数索引后，若函数索引表达式的结果依赖于系统变量，修改系统变量后再执行 Update/Delete 操作时可能报 4377 的问题。新增 5500 错误码用于区分该类问题。
• 修复在 V4.1.0 版本升级 V4.2.0 版本的过程中，可能会出现断开连接的问题。对于 V4.1.0 BP4 之前的版本，可以通过先升级 OceanBase 数据库，再升级 ODP 的方式来规避该问题。
• 修复迁移后的磁盘空间计算错误导致 Unit 来回迁移的问题。
• 修复分区表场景下，OBKV 使用本地索引查询失败的问题。
• 修复了 OBServer 节点重启时，Schema 刷新持续报 4013 错误，无法刷新成功的问题。导致该问题生成的原因是集群中某个租户的 __all_virtual_table_history 表中记录的数量超过了 400 万条。
• 修复两个分区表分区方式不完全相同，但分区裁剪后分区方式相同在进行 Partition Wise Join 操作时，可能出现的不同并行度下返回结果不相同的问题。
• 修复使用 .NET 驱动 MySqlConnector 连接 OceanBase 数据库时，在执行存储过程中遇到的驱动程序报错问题。

Version information

Information	Description
Release date	September 14, 2023
Version	V4.2.0_CE_BP1
Commit number	600ea45

Overview

This version addressed several customer and internal testing issues to enhance product stability.

Bug fixes

• Fixed the issue where the query results were incorrect if INDEX SKIP SCAN was used in the query plan and parallel query was enabled.

• Fixed the issue where data inconsistency would occur between the main table and the index table when the REPLACE INTO statement was used.

• Fixed the issue where the OBServer node would encounter exceptions upon a restart when _optimizer_better_inlist_costing was explicitly set to true.

• Fixed the issue where the max_ls_id field in the __all_tenant_info table was not correctly updated during the upgrade from OceanBase Database V4.1.0_CE to OceanBase Database V4.2.0_CE. This issue could result in continuous transaction retries after the upgrade until a timeout error occurred.

Considerations

1. In versions between V4.1.0_CE_BP3 and V4.2.0_CE, if the default value of the hidden parameter _optimizer_better_inlist_costing was changed from False to True, it needs to be changed back to False. Otherwise, the OBserver node might encounter exceptions after a restart.

2. If you want to upgrade the Community Edition from V4.1.0 to V4.2.0, it is recommended that you directly upgrade to V4.2.0_CE_BP1 or higher to avoid potential transaction timeout issues that may be triggered during the upgrade process.

版本信息

项目	描述
发布日期	2023-09-14
版本号	V4.2.0_CE_BP1
Commit 号	600ea45

发版目的

解决用户及内部测试遇到的问题，提升版本稳定性。

BUG 修复

• 修复在查询计划中包含 INDEX SKIP SCAN，并且在开启并行查询的场景下可能导致查询结果不正确的问题。
• 修复在使用 REPLACE INTO 的场景下，可能出现的主表和索引表数据不一致问题。
• 修复显式设置 _optimizer_better_inlist_costing=true 场景下，可能导致 OBServer 重启后运行异常问题。
• 修复从 V4.1.0_CE 版本升级到 V4.2.0_CE 版本的场景中，__all_tenant_info 表中 max_ls_id 字段未正确更新，可能导致升级后事务持续重试直到报超时的问题。

注意事项

1. V4.1.0_CE_BP3 版本到 V4.2.0_CE 之间的版本，如果将隐藏配置项 _optimizer_better_inlist_costing 的默认值 False 改为 True，那么需要将其改回 False。否则，可能会导致重启后运行异常的问题。
2. 如果您想从 V4.1.0 版本升级到 V4.2.0 版本，建议您直接升级到 V4.2.0_CE_BP1 或更高版本，以避免因升级可能触发的事务超时问题。

Version information

Information	Description
Release date	September 12, 2023
Version	V3.1.5_CE_HF2
Commit number	8a9dc4b

Overview

This version fixed some bugs and improved stability.

Bug fixes

• Added the role_change_timeout parameter to fix the issue where the partition role was changed due to frequent timeouts in large transaction scenarios.
• Fixed the issue where, in special scenarios, the Time to Live (TTL) timer failed to start after the cluster was restarted from a crash, resulting in a leaderless partition and the inability to recover the cluster.
• Fixed the following issue: The RootService leader switchover was triggered in high traffic scenarios. However, the partition with the TTL timer failed to be elected as the new leader, causing the new leader of the RootService could not start.

版本信息

项目	描述
发布日期	2023-09-12
版本号	V3.1.5_CE_HF2
Commit 号	8a9dc4b

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

BUG 修复

• 添加 role_change_timeout 配置项，修复大事务场景分区出现频繁超时卸任的问题。
• 修复特殊场景下宕机重启，TTL 定时器启动失败导致分区无主集群无法恢复的问题。
• 修复大压力下 RootService 切主，TTL 分区上任失败导致 RootService Leader 启动一直失败的问题。

Version information

Information	Description
Release date	September 4, 2023
Version	V4.2.0_CE
Commit number	7e912e0

Overview

• This version addressed several customer and internal testing issues to enhance product stability.
• This version now supports data reads between OceanBase MySQL tenants by using a DBLink.

Bug fixes and improvements

• Fixed the issue where the garbage collection (GC) thread would skip partition checks and cause excessive storage consumption when there were no multi-version SSTables available.
• Fixed the issue where major compaction would get stuck due to Error 4012 when the system attempted to read tablets from the disk.
• Fixed the bypass import timeout issue caused by excessive load on the Clog disk.
• Fixed the issue where high-priority RPC requests were unable to enter the queue and could trigger Error 4019 when normal-priority RPC requests reached the limit.
• Fixed the issue where creating unique indexes in parallel on a table that contains duplicate rows of data could cause core dump.
• Fixed the issue where reading from the leader node forcefully would cause its CPU resources to be occupied by traffic from the follower nodes during the retry of weak consistency reads.
• Fixed the issue where the cluster would encounter Error 4184 due to temporary file I/O exceptions in high disk load scenarios.
• Fixed the issue where the SqlExecutor module encountered memory bloat due to improper memory allocation during MERGE JOIN operations.
• Fixed the issue where the cluster could encounter exceptions in some clock drift scenarios.
• Optimized the online statistics collection strategy by only collecting global statistics for partitioned tables and not collecting partition-level statistics, so as to help alleviate the problems of excessive RPC requests and high memory usage.
• Improved the efficiency of reloading configurations during the restart process in scenarios with a large number of partitions.

版本信息

项目	描述
发布日期	2023-09-04
版本号	V4.2.0_CE
Commit 号	7e912e0

发版目的

• 解决客户及内部测试遇到的问题，提升版本稳定性。
• 社区版支持 MySQL 租户间的 DBLINK 读功能。

缺陷修复

• 修复在没有多版本 SSTable 的情况下，GC(Garbage Collection) 线程跳过相关分区检查，导致用户存储空间放大的问题。
• 修复从磁盘读 Tablet 返回 4012 超时，可能导致的合并卡住问题。
• 修复 Clog 盘负载过高可能导致的旁路导入执行超时问题。
• 当普通优先级的 RPC 队列积压到队列上限后，导致高优先级的 RPC 无法进入队列并可能触发查询报错 4019 的问题。
• 修复表中包含重复行数据，并行创建唯一索引时可能触发的 Core 问题。
• 修复弱读重试时，强制读 Leader 导致备机流量占用 Leader CPU 的问题。
• 修复在磁盘负载过高的场景下，临时文件 I/O 异常可能导致的集群报错 4184 磁盘满的问题。
• 修复 Merge Join 的内存分配不当，导致 SqlExecutor 模块内存膨胀问题。
• 修复部分时钟跳变场景下，可能导致集群使用异常的问题。
• 优化在线统计信息收集策略，分区表只收集全局统计信息，不收集分区级统计信息，从而缓解 RPC 过大、内存占用高的问题。
• 优化分区数量较大的场景下，重启过程中重新加载配置的耗时时间。

Version information

Information	Description
Release date	August 28, 2023
Version	V4.1.0_CE_BP3_HF1

About this version

This version addressed several issues encountered by customers and discovered during internal testing to improve the product's stability.

Fixed issues

• Fixed an issue where modifying tenant specifications caused a limitation of 100 connections for non-root users.
• Fixed an issue where concurrent access to the plan_cache_plan_stat table during the deletion of an execution plan could trigger a core dump.
• Added new parameters to control the optional plan paths for the JOIN operator.

Considerations

OceanBase Database Community Edition can be directly upgraded from V4.1.0_CE_BP3_HF1 to V4.2.0_CE_GA but not to V4.2.0_CE_BETA.

版本信息

项目	描述
发布日期	2023-08-28
版本号	V4.1.0_CE_BP3_HF1

发版目的

解决客户及内部测试遇到的问题，提升版本稳定性。

缺陷修复

• 修复变更租户规格，导致非 root 用户连接数受限为 100 个的问题。
• 修复删除执行计划的过程中, 并发访问 plan_cache_plan_stat 表可能触发 Coredump 的问题。
• 新增配置项，用于控制 JOIN 算子可选的计划路径。

注意事项

V4.1.0_CE_BP3_HF1 版本不支持直接升级到 V4.2.0_CE_BETA 版本，但支持升级到 V4.2.0_CE_GA 版本。

Version information

Information	Description
Release date	August 21, 2023
Version	V4.2.0_CE_BETA_HF1

About this version

This version fixes some bugs and improves stability.

Fixed issues

• Fixed an issue where core dump would occur during the startup of OceanBase Database if it was deployed in a CPU environment that does not support Advanced Vector Extensions (AVX) instruction set.
• Fixed an issue where exceptions occurring during the sending of RPC packets could result in all nodes in the cluster becoming inactive.

版本信息

项目	描述
发布日期	2023-08-21
版本号	V4.2.0_CE_BETA_HF1

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

缺陷修复

• 修复在不支持 AVX 指令集的 CPU 环境中部署 OceanBase 数据库，启动时触发 Coredump 的问题。
• 修复 RPC 发包异常，可能导致的集群节点状态均为 INACTIVE 的问题。

Version information

Information	Description
Release date	August 14, 2023
Version	V4.1.0_CE_BP3
Commit number	694f84c

About this version

1. OBKV supports aggregate functions such as MIN, MAX, and COUNT, auto-increment columns, and row data verification during data insertion.
2. The _ha_get_tablet_info_batch_count and _ha_rpc_timeout hidden parameters are added to control the number of tablets obtained by an RPC call at a time and the RPC timeout during operations such as migration, replication, rebuild, and physical restore. If the I/O operations on the SATA disk are slow, you can use the two parameters.
3. The DBMS_RESOURCE_MANAGER system package is provided in the community edition.
4. Issues encountered by customers and during internal tests are resolved to improve the stability of the product.

Fixed issues

• Fixed an issue that after the LIMIT pushdown statement is rewritten, the execution result of a LIMIT clause containing the RAND function is incorrect.
• Fixed an issue that if an expression contains functions such as USERENV and SYSDATE, the query result is inaccurate due to an incorrect query range.
• Fixed an issue that in the Prepared Statement (PS) protocol, a zero datetime value of the DATETIME type is not fully compatible with MySQL when an OBServer node sends a packet to the client. As a result, the query result on the client of the Go driver is abnormal.
• Fixed an issue that when the GROUP BY clause is used in a join of two tables, the returned result set does not meet the expectations.
• Fixed an issue that in a scenario where the cgroup feature is enabled and sql_nio is disabled, a core dump may occur due to the use of the PS protocol.
• Fixed an issue that if the CPU resources remain exhausted for a period of time, an OBKV request may time out and thereby cause a core dump.
• Fixed an issue that after the character set of a tenant is changed by using the ALTER DATABASE statement, the character set displayed in the information_schema.SCHEMATA view is incorrect.
• Fixed an issue that when a large number of DDL operations are performed on a single table, the minor compaction threads may be stuck due to too many involved partitions or intensive writes, which results in an out of memory (OOM) error.
• Fixed an issue that after the DOUBLE type is converted into the INT type in a query statement, the query result is inaccurate due to an incorrect query range.
• Fixed an issue that when an INSERT operation is performed in a scenario with a large data volume, a minor or major compaction will trigger a retry of the INSERT operation, which may result in discontinuous auto-increment IDs.
• Fixed an issue that during bypass import, the memory is used up because data of the ObArray type occupies memory of the sys500 tenant.
• Fixed an issue that when too many sessions exist in the sys tenant, the client may return the error session already exists.
• Fixed an issue that SqlExecutor memory bloats when a tenant with minimum specifications obtains the schemas.
• Optimized the performance in CPU over-allocation scenarios after the cgroup feature is enabled.

Considerations

OceanBase Database Community Edition can be directly upgraded from V4.1.0_CE_BP3 to V4.2.0 GA but not to V4.2.0_CE_Beta.

版本信息

项目	描述
发布日期	2023-08-14
版本号	V4.1.0_CE_BP3
Commit 号	694f84c

发版目的

1. OBKV 支持 min、max、count 等汇聚函数，同时支持自增列和插入数据时的行数据校验。
2. 新增了两个隐藏配置项 _ha_get_tablet_info_batch_count 和 _ha_rpc_timeout，用于控制迁移复制、Rebuild 和物理恢复等操作中一次 RPC 批量获取 Tablet 的数量和 RPC 超时时间。这些配置项适用于 SATA 盘 IO 较慢的场景。
3. 开放 DBMS_RESOURCE_MANAGER 系统包到开源版本。
4. 解决客户及内部测试遇到的问题，提升版本稳定性。

缺陷修复

• 修复 limit push down 改写导致的带有 Rand 函数的 Limit 语句结果错误问题。
• 修复表达式中包含 USERENV、SYSDATE 等函数时，Query Range 错误导致查询结果不准确的问题。
• 修复在 PS 协议下，DATETIME 类型的 zero datetime 值在 OBServer 节点给客户端发包时没有完全与 MySQL 兼容，导致 Go 驱动客户端查询结果异常的问题。
• 修复两表 JOIN 使用 GROUP BY 语句时，返回结果集不符合预期的问题。
• 修复在开启 cgroup、关闭 sql_nio 场景下，使用 PS 可能触发的 Core 问题。
• 修复了 CPU 持续打爆的情况下，进行 OBKV 请求操作可能会导致超时并触发的 Core 问题。
• 修复 ALTER DATABASE 修改租户字符集后，information_schema.SCHEMATA 中字符集展示不正确问题。
• 修复在进行单表大量 DDL 操作时，同时分区数目较多或写入较多可能会触发转储线程卡住导致内存爆满的问题。
• 修复在查询语句中将 DOUBLE 类型转换为 INT 类型后，由于 Query Range 错误导致查询结果不正确的问题。
• 修复在大数量场景下进行 INSERT 操作时，触发某些转储/合并动作导致 INSERT 重试，可能导致自增 ID 跳变的问题。
• 修复在旁路导入时，由于 ObArray 类型使用了 500 租户的内存，导致内存爆满的问题。
• 修复 sys 租户积压场景下可能导致的客户端报错 session already exists 问题。
• 优化小规格租户在获取 Schema 过程中，SqlExecutor 内存膨胀问题。
• 优化开启 Cgroup 后，在 CPU 超卖场景下的性能表现。

注意事项

V4.1.0_CE_BP3 版本不支持升级到 V4.2.0_CE_Beta 版本，但支持升级到 V4.2.0 GA 版本。

V4.2.0_CE_Beta

版本信息

项目	描述
发布日期	2023-08-02
版本号	V4.2.0_CE_Beta
Commit 号	8024d8f

版本定位

OceanBase 数据库 V4.2.0_CE 版本是在 V4.1.0_CE 版本基础上进一步健全完善核心特性，补齐了 V3.x 系列的全部主要功能，提升产品可扩展性，优化资源使用，提高性能，增强兼容性与易用性。目前发布的为 V4.2.0_CE Beta 版本，而后续的 V4.2.x 版本也会作为 长期支持版本（LTS） 对外提供服务。
V4.2.0 版本核心特性如下：

• MySQL兼容
  • 函数索引：新版本在 MySQL 模式下也支持了兼容 MySQL 8.0 的函数索引，同时进一步增强了函数索引的使用稳定性。
  • OBCDC：行数据支持按照列的定义序输出，满足 MySQL Binlog Service 的兼容性需求。取消系统租户依赖，支持普通租户同步，支持无主键表同步。
• 性能提升
  • 优化器/执行器/ PL 能力增强：新版本针对查询改写、查询优化能力做了一系列增强，也重点优化了执行器算子性能。PL 优化了 Plan Cache 和并行执行逻辑，支持 SQL 语句返回复杂数据类型。
  • 统计信息强化：增强统计信息功能的稳定性和可用性。同时增加了统计信息收集监控诊断功能，优化了统计信息收集的性能和内存开销。
  • 动态采样：支持了优化器动态采样功能，在 SQL 运行时收集统计信息，生成更优的执行计划，提升查询性能。
  • 查询计划演进：支持查询计划演进功能，有效避免执行计划性能回退。
  • Runtime Filter：完整支持 Runtime Filter，提升 AP 处理性能。
  • 4C 小规格性能优化：4C 环境默认参数下，OLTP 各个场景性能提升 20%+。
  • 读事务数据性能优化：优化读转储未提交数据时的查事务表性能。
  • 事务数据表并行转储：V4.1.0 版本已经支持了并行的 MINOR_MERGE（表示多个 Mini SSTable 合成一个 Minor SSTable），V4.2.0 版本新增支持对事务数据表做并行的 MINI_MERGE（表示冻结 MemTable 通过转储变成 Mini SSTable）。
  • 快速随机数据生成：新增 GENERATOR(N) 内置函数，可配合 RANDOM([N])、RANDSTR(N, gen) 随机函数或 NORMAL(<mean> , <stddev> , <gen>)、UNIFORM(<min> , <max> , <gen>)、ZIPF(<s> , <N> , <gen>) 等分布控制函数使用。相对 MySQL Recursize CTE，Table Generator 具备明显的性能优势。
• OLAP能力
  • 只读外表：创建、读取，减少数据入库开销。
• 扩展性增强
  • Transfer和负载均衡：采用 Transfer 技术实现日志流的分裂和合并，支持以分区为单位进行跨节点的数据搬迁，提供了灵活的扩缩容能力和数据动态均衡能力。
  • 复制表：新版本基于单机日志流的新架构对复制表进行了重构，构建了基于分区的可读版本号校验以及基于日志流的 Lease 授予机制，用于保证强一致性读的正确性。另外，新版本完善了切主不杀事务的能力，在用户或负载均衡发起 Leader 切换时未提交的复制表事务可以在切主后继续执行。相比于 V3.x 版本，V4.2.0 版本的复制表也有着更好的写事务性能和更强的容灾能力，副本宕机对于读操作的影响更低。
• 高可用增强
  • 物理备库：OceanBase 数据库 V4.1.0 版本支持了基于归档的主备库，配置灵活且不要求主备租户之间网络。但仍然有不少场景需要基于网络直通的主备库方案，来降低存储及网络成本，缩减备份恢复链路，V4.2.0 版本进行了扩展支持。
  • 日志写入限速：日志提交写盘的速度大于转储速度时会导致日志盘满。V4.2.0 版本在日志盘使用量达到一定水位时，通过限制日志提交写盘的速度，来避免写入压力特别大的集群频繁出现日志盘满的现象。相关用法请参考 log_disk_throttling_percentage/log_disk_throttling_maximum_duration 配置项。
• 资源使用优化
  • 空载 CPU 优化：针对高频、耗时长的 SQL、后台线程做了一些针对性的优化，以降低内部 SQL 执行和后台线程定期执行的 CPU 开销。经测试，单个业务租户，30 张压测表，单表数据 100w 行的空载环境下，CPU 默认开销 0.2C 左右。
  • 磁盘数据文件按需扩展：支持渐进磁盘扩容方式，先预分配一个合适的磁盘大小，然后根据实际使用情况自动扩容。
  • 共享内存识别机制：在技术手段上增加防御机制，对真正预期使用共享内存的代码进行打标，优化随代码合入出现的共享资源增多情况。
• 易用性提升
  • Auto DOP：支持 Auto DOP 自动计算查询并行度，降低并行执行使用门槛。
  • 全链路诊断能力增强：V4.1.0 版本提供了全链路诊断能力，V4.2.0 版本基于全链路诊断框架, 又补充了部分 Trace 打点信息。同时提供了面向事务+SQL 维度的可交互的 Show Trace 能力。
  • 逻辑计划管理：V4.2.0 版本为逻辑计划易用做了很多改进。比如保存 EXPLAIN 计划信息、逻辑计划的执行反馈信息、查询运行中 SQL 的实时计划；提供丰富的 DBMS_XPLAN 包接口，展示指定查询的计划、Baseline 计划、及 Session 的实时计划，并以格式化方式输出。
  • 后台线程统计：V4.2.0 之前版本更倾向以客户端为视角，记录前台线程诊断信息。但对OceanBase 数据库来讲，后台线程占了绝大部分，不论排查问题还是诊断性能，都需要了解后台线程的状态。V4.2.0 版本新增视图 [G]V$OB_THREAD，用于记录全量线程的状态信息。
• 国家标准

GB18030-2022 字符集：OceanBase 数据库在 V4.2.0 版本开始支持 GB18030-2022 字符集。GB18030-2022 在 2022 年 7 月 19 日发布，2023 年 8 月 1 日正式实施，支持了更多的生僻汉字及少数民族文字，成为信息系统的全文强制执行标准。

• 产品形态
  • 产品主备库：V4.1.0 支持了单机形态，V4.2.0 补充支持单机主备库形态。
  • 只读副本（R 副本）：V4.2.0 版本补齐了只读副本功能，区别于全功能副本，提供只读能力。

关键特性说明

MySQL兼容

支持函数索引： MySQL 8.0 新增函数索引功能，主要用于优化查询语句的性能。通常情况下，如果对查询列使用了函数或表达式，那么无法使用普通的索引进行优化，需要使用函数索引来提高查询性能。函数索引可以将函数的返回值作为索引的一部分，从而加快查询速度。OceanBase 数据库 V4.2.0 版本开始也在 MySQL 租户下支持了 MySQL 8.0 兼容的函数索引，支持通过 create table/create index/alter table 等语句创建。另外，V4.2.0 版本也强化了索引的抽取能力，在索引表达式外层存在隐式转换、前缀索引的引用列上存在 Like 谓词等多数场景可以有效使用到索引。更多信息请参见 创建索引。

性能提升

统计信息强化

V4.0.0 版本之后统计信息的收集完全由 SQL 层发起和维护，合并时不再收集统计信息。但由于统计信息收集功能不够完善，在收集的性能和内存消耗上等方面存在一些问题，进一步影响到 SQL 计划的生成。同时由于统计信息的收集缺乏有效的监控手段，用户难以确定各个数据表上统计信息收集的状态、是否过期等信息，会造成运维困难。V4.2.0 版本重点增强了统计信息功能的稳定性和可用性。在线统计信息收集优化了数据结构和收集性能，INSERT INTO SELECT 和 LOAD DATA 两种导数方式使用在线统计信息收集时性能提升 10% 左右。离线统计信息收集优化了计划生成路径和内存使用，在 tpcds_100g 分区表、64 并发离线收集场景，性能提升 10%-20%。另外还支持了统计信息收集监控诊断，新增 [G]V$OB_OPT_STAT_GATHER_MONITOR 动态性能视图用于查询统计信息收集任务实时状态，新增 DBA_OB_TASK_OPT_STAT_GATHER_HISTORY 字典视图用于查询历史收集任务执行情况，新增 DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY 字典视图用于查询表的历史收集执行情况。

动态采样

在执行 SQL 查询时，OceanBase 数据库优化器需要收集表和索引的统计信息，以便能够选择最佳的执行计划。如果统计信息不准确或者不完整，使用的执行计划就可能不是最优的，导致查询性能下降。基础的统计信息通常是通过自动收集或者手动收集等方式获取到。但是，如果数据分布发生变化，没有收集统计信息或者遇到一些复杂的 SQL 查询，统计信息就可能不再准确。V4.2.0 版本提供了动态采样功能，在计划生成阶段针对数据库对象进行提前采样，通过采样的方式进行行数估计，从而用于代价模型中，生成更好的执行计划。目前提供了系统变量、查询 HINT 及系统配置项三种方式进行动态采样功能的控制，同时采样集的大小受限于并行度的控制。更多信息请参见 优化器动态采样。

Runtime Filter

OceanBase 数据库自 V3.1.0 版本以来, 支持了 Join Bloom Filter 用于在 Join 中执行期扫描数据时快速过滤数据, 在 V4.0.0 版本上对于 Join 键为分区列或者分区列前缀场景支持了Partition Bloom FIlter可以动态过滤分区，在 V4.1.0 版本支持了多发 Bloom Filter 使得相邻 DFO 和单个 DFO 内部均可以生成多对 Bloom Filter。 In/Range/Bloom Filter 这一类在执行期动态过滤数据的 Filter 统一称为 Runtime Filter(RF)，V4.2.0 版本完整支持了 Runtime Filter，提升 AP 处理性能。可以通过px_join_fitler / px_part_join_filter 来手动打开 runtime filter/part filter；通过no_px_join_filter / no_px_part_join_filter 来手动关闭 runtime filter/part filter。并提供了 4 个系统变量用于在需要场景下调整 Runtime Filter 执行相关策略。更多信息见 Runtime Filter。

4C 小规格性能优化

结合自增 ID 优化、New Sort 自适应优化、PDML 场景下 Callback Allocator 优化、时间函数调用优化、单日志流语句快照获取优化、租户级别获取优化、enable_trace_log/enable_sql_audit 优化等优化手段，V4.2.0 版本对 4C16G 小规格场景的 Sysbench 压测性能提升 20%+。

快速随机数据生成

Table function 是一种能够返回一张数据表作为结果的函数。在此基础上，V4.2.0 版本新增 Table Generator 功能，即 generator(N) 内置函数，并允许在 Table Function 中调用它，表现为 table(generator(N))。同时新增 RANDOM([N])、RANDSTR(N, gen) 随机函数，和 NORMAL(<mean> , <stddev> , <gen>)、UNIFORM(<min> , <max> , <gen>)、ZIPF(<s> , <N> , <gen>) 分布控制函数，与 Table Generator 配合使用生成数据。相对 MySQL Recursize CTE，Table Generator 具备明显的性能优势。更多信息请参见 GENERATOR。

OLAP 能力

只读外表

数据库中的表会存放于数据库的存储空间中，而外表的数据存储于外部存储服务中。外部表可以像普通表一样查询，但局限于读，不能执行 DML 操作。通常情况下，处理外部数据，需要先通过 ETL 工具将数据导入数据库。在这个过程中，数据库需要消耗存储空间、磁盘 I/O 和 CPU 等资源。而外部表省略了数据导入的流程，可以直接读取外部数据源进行查询分析。使用方法和限制见 创建外表。

扩展性增强

Transfer 和负载均衡

OceanBase 数据库 V4.0.0 版本进行了架构升级，引入了自适应日志流概念，目标是实现单机分布式一体化架构，提供更加灵活的扩展性能力，支持单机和分布式形态的动态变换。已发布的 V4.1.0 版本在扩展性能力方面还不够完善，分区和日志流是静态的绑定关系，不支持动态调整分区分布，从而限制了自动负载均衡的能力，不支持部署形态的灵活变换。OceanBase 数据库 V4.2.0 版本是首个完整实现单机分布式一体化架构的版本，采用 Transfer 技术实现了日志流的分裂和合并，支持了以分区为单位进行跨节点的数据搬迁，完善了可扩展性能力，真正实现了单机和分布式形态的动态变换。租户级别的负载均衡特性主要体现在以下两个方面：

• 租户水平扩缩容：用户通过动态调整 Unit Number（每个 Zone 上提供服务的 Unit 个数）和 Primary Zone（提供读写服务的 Zone 列表），可以实现租户的读写服务能力在 Zone 内和 Zone 间的水平扩缩容。负载均衡模块将根据用户服务能力的配置自适应调整日志流和分区分布。
• 分区均衡：在表和分区动态变化的情况下，通过动态调整分区分布，实现分区个数以及存储空间在服务节点上的均衡。

更多信息请参见 负载均衡。

复制表

复制表是 OceanBase 数据库的一种特殊表，可以在任意一个 “健康” 的副本上读取到数据的最新修改。对于写入频率较低、更关心读操作延迟和负载均衡的用户来说，复制表是一个很好的选择，在牺牲小部分事务提交性能的前提下复制表可以在任意一个 “健康” 的 Follower 上读到最新数据。此处所提到的“健康”是指 Follower 与 Leader 之间的网络通畅、回放进度差距不大。在 V3.2.0 版本中，OceanBase 数据库已经支持复制表功能，通过复制表可以在指定租户的每台机器上都有一个备副本，并且主副本与所有备份的数据使用全同步策略保持强同步。V4.2.0 版本的复制表相较于旧版本又做出了一些改进，完善了切主不杀事务的能力，在用户或负载均衡发起 Leader 切换时，可以在切主后继续执行。同时，新版本的复制表也有着更好的写事务性能和更强的容灾能力，副本宕机对于读操作的影响更低。
更多信息请参见 创建表。

高可用增强

物理备库

V4.1.0 版本支持了基于三方介质归档的主备库，该方案解决了主备库基本需求，并且配置灵活，比如不要求主备租户之间网络互通等。但是相比网络直连备库存在一些劣势，比如存储以及网络成本上升、性能以及稳定性上的损耗、运维难度上升、使用限制如 Switchover 要求备库先开启归档等。从这些方面考虑，基于网络直通的物理备库缩短了主备库间日志同步链路，对单机用户、中小用户等更加友好。另外考虑备库通信的可用带宽限制和不稳定性因素，V4.2.0 版本也支持了备库限速能力，避免在网络带宽受限制时部分备库流量占用过高影响其他节点的情况。物理备库具体使用方式见 物理备库概述。

资源使用优化

磁盘数据文件按需扩展

OceanBase 数据库采用预分配磁盘空间的策略，好处是可以保证占有一段尽可能连续的磁盘空间，避免其他应用程序对磁盘的抢占引起的磁盘资源不足，并且可以在其基础上定制文件系统，提高数据访问效率。但用户数据量很小的情况下，会存在磁盘空间浪费的情况。V4.2.0 版本新增加一种渐进磁盘扩容的用户配置选项，即预分配一个合理的磁盘大小，根据磁盘的实际使用情况自动感知并扩容，降低磁盘开销具体使用方式见 配置磁盘数据文件的动态扩容。

易用性提升

Auto DOP

并行执行是优化大数据量查询的关键能力，优化器中一般会使用并行度（DOP：Degree of Parallel）来描述并行资源量。在实际业务场景中，是否需要开启并行以及所需的 DOP 大小，历史版本需要考虑执行情况、业务响应时间要求、系统资源等，靠经验通过系统变量或 HINT 来手工调整。在保留手工调整并行度能力的基础上，V4.2.0 版本新增 Auto DOP 功能，在生成查询计划时评估查询需要执行的时间，自动确定是否开启并行，以及对当前查询合适的并行度。并可通过系统变量 parallel_degree_policy 控制 DOP 选择策略。更多信息见 Auto DOP。

全链路诊断能力增强

OceanBase 数据库 V4.2.0 版本在诊断能力上有了显著提升，其中包括首次实现对 SQL 请求的可视化全链路追踪，能够帮助用户快速追踪并定位具体问题发生在哪个执行阶段、哪台机器以及哪个模块，并提供具体的执行信息。提供了面向用户的事务 + SQL 维度的 Show Trace 能力。对于业务部门而言，更关心的往往是一笔业务服务总的耗时情况。例如在 OLTP 系统中，一笔业务服务一般由一个或多个事务组成。因此，我们把事务作为追踪单位会更贴合用户的实际业务，一个事务形成一个追踪的 Trace，并对事务中每条 SQL 请求记录 OBClient > ODP > OBServer 内部全链路过程中相关执行信息，用户可以通过一个 Trace 快速找到该事务执行了哪些语句，以及这些语句从客户端视角看到的执行情况。Show Trace 也可以为用户提供便捷的业务系统关联能力，用户通过 JDBC 接口/ SQL 接口，能够在业务数据库连接上设置调用请求对应的 app trace id, 该 app trace id 会记录到 OceanBase 数据库全链路追踪对应的信息中, 并在 Show Trace 中展示出来。当用户发现某个 app trace id 对应的请求或服务数据库调用有报错时, 可以使用该 app trace id在全链路诊断系统中快速搜索到对应的 app trace id 关联的数据库 Trace，然后直接查看该请求在数据库链路中各阶段耗时情况及报错点，快速确定触发问题的组件。更多信息见 全链路追踪展示。

逻辑计划管理

V4.2.0 版本在逻辑计划管理方面做了很多增强功能，包括：

• 通过 EXPLAIN 语法获取某条查询的计划信息后，在当前 Session 未断开之前，用户可以通过 DBMS_XPLAN.display 查询历史，或者可以通过 EXPLAIN INTO 语法指定保存到目标表。
• 自动保存执行过的所有查询的计划，包括物理计划以及逻辑计划，方便后续排查问题。重启集群时，数据库会清理保存的查询计划。
• 通过 DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE 查看 SPM 的基线计划。
• 通过 DBMS_XPLAN.DISPLAY_ACTIVE_SESSION_PLAN 和 SESSION_ID 查看执行中的查询的计划信息。

更多信息见 DISPLAY_ACTIVE_SESSION_PLAN。

国家标准

GB18030-2022 字符集

GB18030-2022 在 2022 年 7 月 19 日发布，2023 年 8 月 1 日正式实施，并成为信息系统的全文强制执行标准。与 GB18030-2005 标准相比，新标准支持了更多的生僻汉字及少数民族文字。OceanBase 数据库 V4.2.0 版本支持了新标准的字符集 GB18030_2022，也配套更新了相应的排序方法。MySQL 模式下字符集名称为 GB18030_2022，也配套更新了相应的排序方法。。更多信息请参见 字符集。

产品形态

单机主备库

V4.1.0 版本支持了单机形态，V4.2.0 版本补充支持单机主备库形态。

只读副本（R 副本）

只读副本不参与一致性协议的投票，无法成为 Leader，只有回放 Leader 产生的日志在本地生成相应的数据。简而言之，只读副本只可能提供读服务，不可能提供写服务。OceanBase 数据库 V4.2.0 版本补齐只读副本功能，结合复制表广播日志流，在不需要参与投票的 OBServer 节点上部署只读副本，在需要参与投票的 OBServer 上部署常规的全功能副本（F 副本），保证在理想情况下复制表可以在任意一个 OBServer 节点上提供强一致性读。
只读副本与全功能副本对比如下：

副本类型	选举投票	日志投票	SSTable	Clog	MemTable
全功能副本	参与	参与	有	有	有
只读副本	不参与	不参与	有	有	有

性能报告

参考社区版本 V4.2.0_CE Beta 的性能测试数据如下：
测试环境规格：

CPU 平台架构	x86_64
ECS 类型	ecs.g7.8xlarge
计算资源	32 核
内存资源	128GB
磁盘资源	300G 系统盘，2*400G 云盘
操作系统	CentOS Linux release 7.9.2009 (Core)

测试版本：

版本	描述
OBServer (V4.2)	OBServer (OceanBase_CE 4.2.0.0)REVISION: 1-b274f1768fb31f46c38e691b2883324b01605b4bBUILD_TIME: Jul 19 2023 08:31:51
ODP (V4.2)	ODP (OceanBase 4.2.0.0 3883.el7)REVISION: 3883-local-b6e947efa65fec48be04f5fb78d70019651503cfBUILD_TIME: Jul 20 2023 09:36:15
OBServer (V4.1)	OBServer (OceanBase_CE 4.1.0.0)REVISION: 100000172023031416-6d4641c7bcd0462f0bf3faed011803c087ea1705BUILD_TIME: Mar 14 2023 16:53:58
ODP (V4.1)	ODP (OceanBase 4.1.0.0 1)REVISION: 5617-local-e6798c479feaab9f9a60b89f87e4df5e284250b6BUILD_TIME: Mar 11 2023 21:42:11

测试调优说明：
为了提升用户体验和易用性，以下测试仅基于少量基础常用参数调优，没有进行大范围调优和点对点优化。

SYSBENCH OLTP负载测试

测试方案：

1. 通过 OBD 部署 OceanBase 集群，ODP 和 Sysbench 分别安装在两台机器上, 作为客户端的压力机器，避免资源抢占。其中ODP单独部署在64c128g的机器上（机型ecs.c7.16xlarge ）
2. OceanBase 集群规模为 1：1：1，部署成功后先新建跑 Sysbench 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），两次测试分别设置租户的 Primary Zone为 RANDOM 和 Zone1，RANDOM 表示新建表分区的 leader 随机到这 3 台机器，Zone1 表示新建表分区的 leader 集中在 Zone1 的 1 台机器上。
3. 启动 Sysbench 客户端，进行 point_select、read_write、read_only 和 write_only 测试。
4. 每轮测试 --time 设置为 60s，线程数取值可以为 32/64/128/256/512/1024。
5. 测试数据量为 30 张非分区表，100 万行数据，即 --tables=30，--table_size 设置为 1000000 。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

参数调优：

ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

测试结果：

• Point Select 性能

  Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
  32	135146.05	0.27	138746.60	0.26	137423.12	0.27
  64	252277.60	0.30	252231.37	0.29	246275.56	0.31
  128	431564.13	0.36	447755.19	0.34	377949.26	0.50
  256	686271.21	0.55	730315.66	0.48	461791.47	0.94
  512	937428.74	0.95	1009966.93	0.90	535462.87	1.67
  1024	985232.01	2.35	1012734.80	2.66	537828.40	3.89

• Read Only 性能

  Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
  32	115232.45	4.74	121733.00	4.65	119054.75	4.74
  64	214733.98	5.18	221563.16	5.09	208659.70	5.37
  128	366616.03	6.09	392138.56	5.67	282377.72	8.43
  256	553922.27	8.74	577951.13	8.58	316931.91	23.10
  512	662368.79	15.83	763726.51	17.01	317668.32	42.61
  1024	653733.97	54.83	740835.95	38.94	315535.24	80.03

• Write Only 性能

  Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
  32	36840.88	5.37	43984.28	7.17	60851.38	4.10
  64	62582.56	8.13	82554.92	6.55	110359.75	4.49
  128	107054.05	9.56	114874.89	10.09	167415.76	5.99
  256	155494.00	13.70	181982.10	12.52	209163.02	10.27
  512	242458.53	17.32	253635.91	19.29	238568.50	18.28
  1024	291343.40	31.94	292482.33	36.89	249176.87	37.56

• Read Write 性能

  Threads	V4.1 QPS【RANDOM】	V4.1 95% Latency (ms)【RANDOM】	V4.2 QPS【RANDOM】	V4.2 95% Latency (ms)【RANDOM】	V4.2 QPS【Zone1】	V4.2 95% Latency (ms)【Zone1】
  32	66669.18	11.45	72554.47	11.87	92995.95	7.84
  64	124559.80	12.52	139369.33	11.65	162191.70	9.22
  128	209150.84	15.27	247061.25	12.30	219285.86	13.70
  256	309329.85	20.00	313660.08	23.95	246672.33	25.74
  512	395940.95	33.12	497734.89	25.74	270444.49	57.87
  1024	454400.54	64.47	547816.87	54.83	256076.76	121.08

BMSQL TPCC 测试

测试方案：

1. 通过 OBD 部署 OceanBase 集群，ODP 和 TPC-C 单独部署在一台机器上, 防止客户端的压力不足成为性能瓶颈。
2. 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPC-C 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），两次测试分别设置租户的 Primary Zone 为 RANDOM 和 Zone1，RANDOM 表示新建表分区的 Leader 随机到这 3 台机器，Zone1 表示新建表分区的 Leader 集中在 Zone1 的 1 台机器上。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

参数调优：

#obproxy
ALTER proxyconfig SET proxy_mem_limited='4G';
ALTER proxyconfig set enable_compression_protocol=false;

#sys
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

软件版本：
mysql-connector-java-5.1.47
Benchmark SQL V5.0
测试配置：

• warehouse = 1000
• loadWorder=40
• terminals=800
• runMins=5
• newOrderWeight=45
• paymentWeight=43
• orderStatusWeight=4
• deliveryWeight=4
• stockLevelWeight=4

测试结果：

测试类型	V4.1 RANDOM	V4.2 RANDOM	V4.2 Zone1
tpmC (NewOrders)	293350.85	289711.96	139886.99
tpmTOTAL	652025.02	644025.66	310953.51
Transaction Count	3260125	3221995	1555658

TPCH 测试

测试方案：

• 使用 OBD 部署 OceanBase 数据库集群。TPC-H 客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 ODP，测试时直连任意一台机器即可。
• 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCH 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone为 RANDOM。先执行数据装载， 然后多次顺序执行 22 个 SQL 后取均值。
• 测试数据量：100GB。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

参数调优：

#sys
ALTER system flush plan cache GLOBAL;
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

#测试租户
SET GLOBAL ob_sql_work_area_percentage = 80;
SET GLOBAL ob_query_timeout = 36000000000;
SET GLOBAL ob_trx_timeout = 36000000000;
SET GLOBAL max_allowed_packet = 67108864;
SET GLOBAL parallel_servers_target = 624;

测试结果：

Query	V4.1（s）	V4.2（s）
Q1	2.18	2.24
Q2	0.23	0.48
Q3	1.48	1.49
Q4	0.53	0.66
Q5	0.98	0.95
Q6	0.13	0.14
Q7	1.46	1.35
Q8	0.92	1.09
Q9	2.82	4.46
Q10	1.10	0.95
Q11	0.17	0.19
Q12	1.36	1.34
Q13	1.89	1.86
Q14	0.29	0.41
Q15	0.88	0.88
Q16	0.66	0.67
Q17	1.62	1.57
Q18	0.82	0.91
Q19	0.61	0.64
Q20	1.07	1.12
Q21	2.54	2.52
Q22	1.08	1.11
Total	24.82	27.03

TPC-DS 测试

测试方案：

• 使用 OBD 部署 OceanBase 数据库集群。客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 ODP，测试时直连任意一台机器即可。
• 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCDS 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM。先执行数据装载，然后多次顺序执行 99 个 SQL 后取均值。
• 测试数据量：100GB。

租户信息：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

参数调优：

#sys
ALTER system flush plan cache GLOBAL;
ALTER system SET enable_sql_audit=false;
ALTER system SET enable_perf_event=false;
ALTER system SET syslog_level='PERF';
ALTER system SET enable_record_trace_log=false;

#测试租户
SET GLOBAL ob_sql_work_area_percentage = 80;
SET GLOBAL ob_query_timeout = 36000000000;
SET GLOBAL ob_trx_timeout = 36000000000;
SET GLOBAL max_allowed_packet = 67108864;
SET GLOBAL parallel_servers_target = 624;

测试结果：

Query	V4.1（s）	V4.2（s）
Q1	0.63	0.64
Q2	3.46	1.17
Q3	0.16	0.17
Q4	9.43	9.76
Q5	1.63	1.71
Q6	0.37	0.42
Q7	0.28	0.31
Q8	0.39	0.26
Q9	1.89	1.90
Q10	0.50	0.51
Q11	5.79	6.02
Q12	0.28	0.23
Q13	2.04	0.57
Q14	11.38	11.22
Q15	0.23	0.23
Q16	0.92	0.95
Q17	0.52	0.46
Q18	0.32	0.37
Q19	0.17	0.28
Q20	0.19	0.19
Q21	0.29	0.31
Q22	1.11	1.23
Q23	14.20	14.55
Q24	1.56	1.41
Q25	0.62	0.49
Q26	0.21	0.22
Q27	0.35	0.42
Q28	7.44	6.58
Q29	0.64	0.53
Q30	0.27	0.31
Q31	0.62	0.67
Q32	0.11	0.11
Q33	0.77	0.55
Q34	0.37	0.56
Q35	0.87	0.90
Q36	0.31	0.32
Q37	0.42	0.46
Q38	1.49	1.60
Q39	2.31	0.85
Q40	0.16	0.17
Q41	0.18	0.08
Q42	0.11	0.13
Q43	0.64	0.65
Q44	0.45	0.49
Q45	0.39	0.32
Q46	0.81	0.65
Q47	1.16	1.21
Q48	0.61	0.66
Q49	0.86	0.92
Q50	0.81	0.68
Q51	2.82	2.83
Q52	0.11	0.12
Q53	0.24	0.25
Q54	1.05	1.04
Q55	0.11	0.11
Q56	1.01	0.56
Q57	0.79	0.80
Q58	0.60	0.65
Q59	13.64	3.11
Q60	1.13	0.69
Q61	0.30	0.33
Q62	0.40	0.42
Q63	0.23	0.24
Q64	1.84	1.89
Q65	2.70	2.77
Q66	0.46	0.49
Q67	16.12	9.59
Q68	0.67	0.48
Q69	0.44	0.46
Q70	1.18	1.36
Q71	0.54	0.54
Q72	1.47	1.34
Q73	0.31	0.41
Q74	6.36	4.36
Q75	2.26	2.55
Q76	0.49	0.50
Q77	0.71	0.74
Q78	3.64	3.46
Q79	0.65	0.70
Q80	1.78	3.45
Q81	0.30	0.26
Q82	0.67	0.79
Q83	0.69	0.76
Q84	0.19	0.20
Q85	0.84	0.92
Q86	0.36	0.33
Q87	1.59	1.70
Q88	0.65	0.85
Q89	0.30	0.32
Q90	0.19	0.47
Q91	0.13	0.16
Q92	0.10	0.10
Q93	0.75	0.76
Q94	0.62	0.65
Q95	6.37	6.36
Q96	0.38	0.44
Q97	0.93	0.94
Q98	0.30	0.30
Q99	0.70	0.80
Total Time	160.83	138.75

兼容性变更

产品行为变更

新增如下变更：

功能	变更版本	变更点说明
TableGroup	4.2	不再支持 TableGroup 上的分区属性，不再通过分区属性限制一个 Table Group 里面的表的分区方式，也不再支持 TableGroup 相关的分区管理操作；TableGroup 内分区的聚集和打散语义不再相同，V4.2.0 版本为 TableGroup 引入了 SHARDING 属性，用于控制 TableGroup 内表数据的聚集和打散关系。TableGroup SHARDING 属性有三种取值：NONE、PARTITION、ADAPTIVE。
Cap 类配置项	4.2	Cap 类配置项的默认单位是 Mb，常被用户误以为是 byte，导致设置的结果远超限制。为了消除不带单位更新配置项导致的非预期结果，在更新 Cap 类配置项时需要指定 Value 的单位，未带单位的更新行为会失败。

视图变更

新增如下变更：

视图	变更版本	变更类型	变更说明
CDB/DBA_OB_TABLEGROUPS	4.2	修改	分区属性字段将不再有含义，展示为 NULL。
CDB/DBA_OB_TABLEGROUP_PARTITIONS	4.2	废弃	视图将废弃，不再展示数据。
CDB/DBA_OB_TABLEGROUP_SUBPARTITIONS	4.2	废弃	视图将废弃，不再展示数据。
CDB/DBA_OB_BALANCE_JOBS	4.2	新增	展示租户下当前正在执行的负载均衡工作。租户下同一时间只有一个负载均衡工作（JOB），每个工作会生成多个负载均衡任务（TASK）。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_JOB_HISTORY	4.2	新增	展示租户下所有执行负载均衡工作的历史。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_TASKS	4.2	新增	展示租户下当前正在执行的负载均衡任务。同一时间可能有多个负载均衡任务正在执行，这些任务（TASK）都属于同一个负载均衡工作（JOB）。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_BALANCE_TASK_HISTORY	4.2	新增	展示租户下所有执行负载均衡任务的历史。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TRANSFER_TASKS	4.2	新增	展示租户下当前正在执行的Transfer任务。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TRANSFER_TASK_HISTORY	4.2	新增	展示租户下所有执行Transfer任务的历史。CDB 展示所有租户数据，仅系统租户可访问。
CDB/DBA_OB_TABLE_LOCATIONS	4.2	修改	修改视图，新增列 DUPLICATE_SCOPE、OBJECT_ID、TABLEGROUP_NAME、TABLEGROUP_ID、SHARDING。用以更好地观察集群/租户的负载均衡状态。
DBA_OB_TENANTS	4.2	修改	修改视图，新增列 UNIT_NUM、COMPATIBLE。用以展示集群/租户下租户的 UNIT 数量。
[G]V$OB_THREAD	4.2	新增	记录全量线程的状态信息，每行表示一个线程。
[G]V$OB_LOCKS	4.2	新增	基于 Oracle 的 V$LOCK 视图实现 OceanBase 数据库自有锁视图 [G]V$OB_LOCKS。同时，在 Oracle 的锁视图的基础上增加 TR 类型的锁，用以描述“行锁”，即未发生转储前的锁。
[G]V$OB_ARBITRATION_SERVICE_STATUS	4.2	新增	展示 OceanBase 集群和仲裁服务之间的联通状态。
[G]V$OB_ARBITRATION_MEMBER_INFO	4.2	新增	展示本集群的仲裁成员信息。
[G]V$OB_OPT_STAT_GATHER_MONITOR	4.2	新增	查询统计信息收集任务实时状态。
DBA_OB_TASK_OPT_STAT_GATHER_HISTORY	4.2	新增	查询历史收集任务执行情况。
DBA_OB_TABLE_OPT_STAT_GATHER_HISTORY	4.2	新增	查询表的历史收集执行情况。
[G]V$OB_UNITS	4.2	修改	新增列 ZONE_TYPE、REGION。
CDB/DBA_OB_DATA_DICTIONARY_IN_LOG	4.2	修改	记录数据字典在系统日志流中的位置范围，方便 CDC 消费数据字典。
[G]V$OB_LOCKS	4.2	新增	显示当前用户各表持锁或请求锁的情况。
CDB/DBA_OB_LOG_RESTORE_SOURCE	4.2	新增	展示物理恢复租户、备租户的日志恢复源。
V$OB_LS_LOG_RESTORE_STATUS	4.2	新增	展示日志流级别日志恢复状态。
V$OB_TIMESTAMP_SERVICE	4.2	新增	显示租户时钟服务的 GTS/STS 值、时钟服务所在的节点信息和时钟源类型。
[G]V$OB_PX_P2P_DATAHUB	4.2	新增	展示并行执行的数据传输操作的相关信息。
[G]V$SQL_JOIN_FILTER	4.2	新增	动态展示 Join Filter 执行相关信息。
DBA_OB_TABLE_STAT_STALE_INFO	4.2	新增	展示自上次收集统计信息以来每个表发生的 DDL 操作次数，以及当前统计信息是否已过期。
CDB/DBA/ALL_OB_EXTERNAL_TABLE_FILES	4.2	新增	展示当前租户下所有已创建的外表所对应的文件列表。
CDB/DBA_OB_ACCESS_POINT	4.2	新增	展示租户入口的 Server 列表。
[G]V$OB_SQL_PLAN	4.2	新增	显示用户通过执行 EXPLAIN PLAN 收集到的计划信息。
[G]V$OB_LOG_STAT	4.2	修改	新增列 ARBITRATION_MEMBER、DEGRADED_LIST、LEARNER_LIST。

系统变量变更

新增如下变更：

系统变量	变更版本	变更类型	变更说明
runtime_filter_type	4.2	新增	SESSION/GLOBAL 级别系统变量，设置租户级别的 Runtime Filter 类型, 包含 BLOOM_FILTER、RANGE、IN 三种类型, 若取值为空字符串，则表示关闭 Runtime Filter 功能。
runtime_filter_wait_time_ms	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 runtime filter 的最大等待时间。默认10ms。
runtime_filter_max_in_num	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 Runtime In Filter 中最大 NDV 个数。默认1024。
runtime_bloom_filter_max_size	4.2	新增	SESSION/GLOBAL 级别系统变量，设置 runtime bloom filter 的最大使用内存, 单位为字节。默认为 2 1024 1024 * 1024 (2G)。
optimizer_dynamic_sampling	4.2	新增	SESSION/GLOBAL 级别系统变量，用于控制动态采样的等级，目前仅支持 0 和 1，0 为关闭动态采样功能，1 为开启动态采样功能。默认为 1。
parallel_degree_policy	4.2	新增	SESSION/GLOBAL 级别系统变量，用于控制 SQL 并行执行的并行度选择策略。默认为 MANUAL，表示启用 Auto DOP。
parallel_degree_limit	4.2	新增	SESSION/GLOBAL 级别系统变量，使用 Auto DOP 策略时，限制优化器选择的并行度上限值。默认值为 0，此时不对计算得到的并行度进行限制。
parallel_min_scan_time_threshold	4.2	新增	SESSION/GLOBAL 级别系统变量，使用 Auto DOP 策略计算基表并行度时，基表扫描估计执行时间超过 parallel_min_scan_time_threshold 设定值时，增加并行度开启并行。默认值 1000ms。
secure_file_priv	4.2	修改	GLOBAL 级别系统变量，安全原因，修改为限制只能使用通过本地 Unix Socket 连接的 Client 执行修改该全局变量的 SQL 语句。

配置项变更

配置项	变更版本	变更类型	变更说明
enable_rebalance	4.2	修改	调整为租户级配置项。系统租户下控制是否进行租户间均衡；普通租户下控制是否进行租户内均衡。
balancer_idle_time	4.2	修改	调整为租户级配置项。系统租户下表示容灾线程和均衡线程的时间间隔；普通租户下租户下表示日志流均衡线程的时间间隔。
partition_balance_schedule_interval	4.2	新增	租户级配置项，用于设置分区均衡调度周期。
log_disk_throttling_percentage	4.2	新增	租户级配置项，表示触发日志写入限速的不可回收日志盘空间占比。当日志盘不可回收空间比例达到 log_disk_throttling_percentage/100 时，即触发日志写入限速；当日志盘不可回收空间比例回落到 log_disk_throttling_percentage/100 以下后，日志写入限速会停止。当该配置项取值为 100 时，表示关闭日志写入限速。默认值为 60。
log_disk_throttling_maximum_duration	4.2	新增	租户级配置项，表示触发日志写入限速后，日志盘预期最大可用时间，即剩余可用日志盘空间预计在 log_disk_throttling_maximum_duration 后才会被消耗完。设置的越大，则预期日志限速支撑的时间越长，限速的力度越大。默认值为 2h。
_optimizer_ads_time_limit	4.2	新增	租户级隐藏配置项，控制优化器动态采样的采样时间上限，单位秒。默认为 10。
datafile_maxsize	4.2	新增	集群级配置项，控制磁盘数据文件自动扩容的上限值。默认为 0。
datafile_next	4.2	新增	集群级配置项，控制磁盘数据文件自动扩容的步长。默认为 0。
_datafile_usage_upper_bound_percentage	4.2	新增	集群级配置项，控制磁盘文件自动扩容的触发时机，当数据文件使用率超过该值则触发扩容。默认为 90。
standby_db_fetch_log_rpc_timeout	4.2	新增	租户级配置项，用于设置备库拉取日志 RPC 超时时间，以控制备库日志传输服务检测主库某台 Server 不可用并切换到其他 Server。默认为 15s。
location_refresh_thread_count	4.2	修改	默认值由 4 调整为 2。
enable_record_trace_id	4.2	修改	默认值由 True 调整为 False。
plan_cache_evict_interval	4.2	修改	默认值由 1s 调整到 5s。
devname	4.2	修改	动态生效调整为只读。
local_ip	4.2	新增	集群级配置项，表示安装 OBServer 机器的 IP 地址。只读。
observer_id	4.2	新增	集群级配置项，用于集群中 RS 分配给 OBServer 节点的唯一标识。只读。
standby_fetch_log_bandwidth_limit	4.2	新增	集群级配置项，备库集群中的所有 Server 从主库同步日志的流量总和占用的最大带宽，默认值为 0 ，代表不对流量进行限制。
ls_gc_delay_time	4.2	新增	租户级配置项，用于配置物理备库场景下，主租户日志流延迟删除的时间。
archive_lag_target	4.2	新增	租户级配置项，用于控制租户日志归档延迟的时间。
standby_db_preferred_upstream_log_region	4.2	新增	租户级配置项，用于配置物理备库场景下，备租户同步上游日志的首选 Region。
storage_meta_cache_priority	4.2	新增	集群级配置项，用于控制 kvcache 中存储 Meta Cache 的优先级。
range_optimizer_max_mem_size	4.2	新增	租户级配置项，用于限制 Query Range 模块使用的内存。
rootservice_memory_limit	4.2	废弃	集群级配置项，用于设置 Root Service 的最大内存容量限制。
trace_log_sampling_interval	4.2	废弃	集群级配置项，用于设置定期打印跟踪日志信息的时间。
tenant_cpu_variation_per_server	4.2	废弃	集群级配置项，用于设置租户多个 UNIT 之间 CPU 配额调度允许的偏差。
token_reserved_percentage	4.2	废弃	集群级配置项，用于设置每次预留多少比例的空闲 token 数给租户。
global_write_halt_residual_memory	4.2	废弃	集群级配置项，用于设置触发暂停普通租户写入（sys 租户不受影响）的全局剩余内存阈值。
plan_cache_high_watermark	4.2	废弃	集群级配置项，用于设置执行计划缓存占用内存的阈值，如果超过该阈值时将触发自动淘汰。
plan_cache_low_watermark	4.2	废弃	集群级配置项，用于设置执行计划缓存占用内存的阈值，如果低于该阈值时将停止淘汰。
max_px_worker_count	4.2	废弃	集群级配置项，用于设置 SQL 并行查询引擎使用的最大线程数。
io_category_config	4.2	废弃	组户级配置项，用于配置各类别 I/O 请求的百分比。

函数变更

函数	变更版本	变更类型	变更说明
RANDOM([N])	4.2	新增	随机生成一个 64 位整数。
RANDSTR(N, gen)	4.2	新增	随机生成长度为 N 的字符串，gen 为随机方法。
NORMAL(<mean> , <stddev> , <gen>)	4.2	新增	返回一个符合正态分布（normal distribution，又称高斯分布）的浮点数。
UNIFORM(<min> , <max> , <gen>)	4.2	新增	返回一个符合均匀分布（uniform distribution）的整数或浮点数。
ZIPF(<s> , <N> , <gen>)	4.2	新增	返回一个符合齐夫分布（zipf distribution）的整数。

周边配套

OceanBase 数据库 V4.2.0_CE 版本推荐使用的平台工具版本如下。

组件	版本	备注
ODP	ODP V4.2.0	-
OCP	V4.0.3_CE	租户主备库功能暂不支持
OBD	OBD V2.2.0	-
All in One	V4.2.0_CE_BETA	-
ODC	ODC V4.1.3 BP3	整体适配是在 ODC V4.2.1版本，预计是8月底发布
OBCDC	OBCDC V4.2.0	-
OMS	V4.1.1_CE	-
OBClient	OBClient V2.2.2	-
LibOBClient	LibOBClient V2.2.2	-

升级说明

• 支持 OceanBase 数据库 V4.1.0_CE 版本在线升级到 OceanBase 数据库 V4.2.0_CE_Beta 版本。
• 不支持从 OceanBase 数据库 V3.x 版本在线升级到 OceanBase 数据库 V4.2.0_CE 版本。
• 支持通过 OMS 将 OceanBase 数据库 V3.x 版本数据使用逻辑迁移升级到 OceanBase 数据库 V4.2.0_CE 版本。

注意事项

• 该版本不建议打开 RPC SSL，相关问题会在后续版本优化。
• 对于 GB18030 到 GB18030-2022 字符集的升级，需要进行逻辑升级。

Version information

Information	Description
Release date	Jun 19, 2023
Version	V3.1.5_CE_HF1
Commit number	b4c6e7b

About this version

This version fixes some bugs and improves stability.

Fixed issues

• Fixed an issue that the PARAM INFO field of the __all_virtual_plan_stat table was not deeply copied, which resulted in the generation of a core dump file in the case of access to an invalid memory address.
• Fixed an issue where an excessive number of rows were returned by the TABLE LOOKUP operator in the table access by index primary key operation, which resulted in the generation of a core dump file in the case of access to an invalid memory address.
• Fixed an issue where partition pruning was not supported when a time type column was used as a partitioning key and the query condition was not an equation.

版本信息

项目	描述
发布日期	2023-06-19
版本号	V3.1.5_CE_HF1
Commit 号	b4c6e7b

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

BUG 修复

• 修复 __all_virtual_plan_stat 中 PARAM INFO 字段没有进行深拷贝，导致后续访问非法内存地址 core 掉的问题。
• 修复 TABLE LOOKUP 的回表行数过多，导致重试过程中访问非法内存地址 core 掉的问题。
• 修复了时间类型非等值条件的分区裁剪问题，增强了分区裁剪的功能。

Version information

Information	Description
Release date	Jun 15, 2023
Version	V4.1.0_CE_BP2
Commit number	43bca41

About this version

• This version includes compatibility with MySQL's SHOW CREATE TABLE statement to meet the needs of related tools.
• User and internal testing issues are also addressed to improve version stability.

Fixed issues

• Fixed an issue where querying the TABLE_CONSTRAINTS view would fail when the system variable lower_case_table_names was set to 0.
• Fixed an issue where refreshing the schema after system restart with a large number of partitions caused Proxy to hang when establishing a connection.
• Fixed an issue where data write operations reported error 4017 due to reference count leakage after inserting over 1 billion rows into an unpartitioned table with no primary key.
• Fixed an issue where large transactions involving full table updates continued to report error 4138.
• Fixed compatibility issues with the ObDDLStartLog structure that could cause failures when upgrading from V4.0.0_CE and V4.0.0_CE_BP1 to later versions.
• Fixed an issue where excessive memory was used by SQL Audit during cluster data playback after restart.
• Fixed an issue where abnormal column equal encoding resulted in data exceptions.
• Fixed an issue where core dump might be triggered when timezone info is modified concurrently.
• Added support for complete compatibility with MySQL's SHOW CREATE TABLE statement by setting the session variable _show_ddl_in_compat_mode.

Considerations

• If you are using V4.0.0_CE or V4.0.0_CE_BP1, we recommend that you upgrade directly to V4.1.0_CE_BP2 to avoid possible log playback compatibility issues during the upgrade process.

• If you have unpartitioned tables with large amounts of data and no primary keys, we recommend that you upgrade directly to V4.1.0_CE_BP2 to avoid potential errors that may occur during data write operations.

版本信息

项目	描述
发布日期	2023-06-15
版本号	V4.1.0_CE_BP2
Commit 号	43bca41

发版目的

• SHOW CREATE TABLE 兼容 MySQL 以满足周边工具需求。
• 解决用户及内部测试遇到的问题，提升版本稳定性。

BUG 修复

• 修复系统变量 lower_case_table_names 设置为 0 时，查询 TABLE_CONSTRAINTS 视图失败的问题。
• 修复分区数特别多的场景下，宕机重启后刷新 Schema 较慢导致 Proxy 建立链接卡住的问题。
• 修复无主键表单分区累计插入 10 亿多行数据后，引用计数泄漏导致的数据写入操作报 4017 错误的问题。
• 修复全表更新的大事务场景下，持续报 4138 错误的问题。
• 修复 V4.0.0_CE 和 V4.0.0_CE_BP1 版本升级到后续版本时，由于 ObDDLStartLog 结构体的兼容性问题，可能导致的升级失败问题。
• 修复重启集群数据回放时，SQL Audit 占用内存不合理的问题。
• 修复列间等值编码异常导致的数据异常问题。
• 修复了并发修改 timezone info 可能触发的 core 问题。
• 支持通过设置 Session 变量 _show_ddl_in_compat_mode，使 SHOW CREATE TABLE 返回信息与 MySQL 完全兼容。

注意事项

• 建议在使用 V4.0.0_CE 或 V4.0.0_CE_BP1 版本的用户直接升级到 V4.1.0_CE_BP2 版本，以避免在升级过程中可能出现的日志回放兼容性问题。
• 建议存在无主键表单分区表且数据量较大的用户，直接升级到 V4.1.0_CE_BP2 版本，以避免在写入数据时可能出现的报错问题。

Version information

Information	Description
Release date	May 19, 2023
Version	V4.1.0_CE_BP1_HF1
Commit number	f7379b2

About this version

This version fixes some bugs and improves stability.

Fixed issues

• Fixed the data exceptions caused by inter-column equidistant encoding.
• Fixed the possible data write failures caused by tablet_id change in the TRUNCATE TABLE scenario.

版本信息

项目	描述
发布日期	2023-05-19
版本号	V4.1.0_CE_BP1_HF1
Commit 号	f7379b2

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

BUG 修复

• 修复列间等值编码异常导致的数据异常问题。
• 修复 TRUNCATE TABLE 场景下，tablet_id 变化可能导致的数据写入失败问题。

Version information

Information	Description
Release date	May 12, 2023
Version	V4.1.0_CE_BP1
Commit number	bd50a54

About this version

This version fixes some bugs and improves stability.

Fixed issues

• Fixed an issue where the error code of the REGEXP BINARY expression was incompatible with that of MySQL.
• Fixed a bug where the SQL execution result sets were duplicated after IN expression optimization.
• Fixed a bug where OceanBase Database deployed in a Kubernetes cluster failed to start due to too many virtual network cards.
• Fixed a bug where the execution plan was not generated as expected after an index was created on a generated column and used for table access.
• Fixed an issue that OceanBase Database does not support the NULLABLE field in the information_schema.STATISTICS view.
• Fixed a bug where plan cache eviction would fail if an SQL execution plan occupies too much memory and contains expressions that cannot be parameterized.
• Fixed a bug related to encoding data estimation error, which resulted in the writing of more than 2 MB of encoded data into the macroblock memory buffer. This bug would result in macroblock serialization failure, which in turn caused the major compaction to be stuck.

Notes

OBD V2.1.0 and later support the upgrade of OceanBase Database from V4.0.0 to V4.1.0.

版本信息

项目	描述
发布日期	2023-05-12
版本号	V4.1.0_CE_BP1
Commit 号	bd50a54

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

缺陷修复

• 修复 REGEXP BINARY 返回错误码与 MySQL 不兼容问题。
• 修复 In Expr 优化导致的 SQL 执行结果集重复问题。
• 修复 k8s 部署集群，因为虚拟网卡太多导致启动失败问题。
• 修复生成列添加索引后，通过索引访问表，生成执行计划不符合预期问题。
• 修复 information_schema.STATISTICS 视图中 NULLABLE 字段不兼容问题。
• 修复 SQL 执行计划占用内存较大且包含不能参数化的表达式，导致 Plan Cache 无法淘汰问题。
• 修复编码数据估算误差，导致写入宏块内存 buffer 的编码数据超过 2M，宏块序列化失败，从而产生合并卡住的问题。

注意事项

OBD V2.1.0 版本开始支持将 OceanBase 数据库社区版从 V4.0.0 版本升级至 V4.1.0 版本。

Version information

Information	Description
Release date	2023-04-20
Version	V4.1.0.0
Commit number	0765e69

About this version

We further enhanced the stability of OceanBase Database in OceanBase Community Edition V4.1.0.0 based on the valuable feedback of our community users. Check the following for more details.

Fixed issues

1. Fixed the issue where stack overflow would occur when the operating system page size is set to 64 KB
2. Fixd the disconnection issue caused by the lack of updating session active time in the response logic of COM_PING
3. Fixed the issue where backup statistics was not accurate
4. Fixed the issue of failing to read the lob data length caused by the upgrade from version 4.0 to version 4.1
5. Fixed a backup failure issue which occurred when many empty tablets exist
6. Fixed the issue of memory leak caused by the ModulePageAlloc module

Notes

1. OBD V2.0.0 does not support the upgrade from OceanBase Database Community Edition V4.0 to OceanBase Database Community Edition V4.1.
2. OCP V4.0.3_CE now supports the upgrade from OceanBase Database Community Edition V4.0 to OceanBase Database Community Edition V4.1.

版本信息（V4.1.0）

项目	描述
发布日期	2023-04-20
版本号	V4.1.0.0
commit号	0765e69

发版目的

本次发版主要是BUG修复，提升版本稳定性。

BUG 修复

1. 修复操作系统page size为64k场景下可能触发的爆栈问题
2. 修复COM_PING响应逻辑里，没有更新session active time导致的断连问题
3. 修复CDB_OB_BACKUP_SET_FILES表中OUTPUT_BYTES统计不准确问题
4. 修复4.0升级4.1后，lob数据读取长度失败问题
5. 修复空tablet数量较多时的备份失败问题
6. 修复500租户ModulePageAlloc模块占用过高导致内存爆问题

注意事项

1. OBD V2.0.0暂不支持4.0 observer升级4.1 observer
2. OCP V4.0.3_CE开始支持4.0 observer升级4.1 observer

版本信息

信息	描述
发布时间	2023-04-19
版本号	V3.1.5
提交号	6d73a6764190f46bbc0805dc27eea5ab08e1920c

概要说明
间隔十余月，OceanBase 迎来了社区版 V3.1.5 版本的正式发布。该版本着重提高内核稳定性，特性上 OBKV 支持了基于热 key 的限流，OBCDC 通过架构优化降低了对使用者机器的资源要求。同时为满足用户对大宽表的期待，将单表列限制从 512 列优化提升至 4096 列。针对用户反馈及内部测试发现的问题，该版本也重点进行了修复。

特性更新

多模数据库（OBKV）支持基于热 key 的限流
新增支持多模数据库（OBKV）基于热 key 的限流功能。增加限流阈值设置，通过统计当前 QPS 最大的 K 个 rowkey 是否超过阈值决定是否执行限流。采用平滑的分梯度部分限流方案，避免简单粗暴切断流量对业务的影响。支持 tableapi 及 hbase 操作。核心能力如下：

• 新增租户级配置项 kv_hotkey_throttle_threshold：指示OBKV限流阈值。当阈值为0时表示限流功能关闭；阈值大于 0 时，在一个epoch（2秒时间区间）内，访问数大于该阈值的 rowkey 会考虑在下一个 epoch 中被限流。取值范围为 [0, 1000000000000000000L] ，默认为0。
• 新增虚拟表 __all_virtual_kv_hotkey_stat：用于记录被限流的 topK hotkey。
• 新增视图 [G]V$OB_KV_HOTKEY_STAT：用于查看 topK hotkey 信息。系统租户下可查看所有租户信息，普通租户下只能查看本租户信息。GV$OB_KV_HOTKEY_STAT 可查看所有 server 上的信息，V$OB_KV_HOTKEY_STAT 只能查看本 server 上的信息。

同步链路系统（OBCDC）架构优化
早期 OceanBase 同步链路系统（OBCDC）对使用者的机器性能（内存大小/磁盘性能）要求比较高，V3.1.5 社区版本优化了 OBCDC 架构，减少内存使用，降低资源依赖，提升性能与稳定性。

单表支持列数上限从512提升至4096列
OceanBase将单表支持列数上限提升至4096列，通过大宽表设计，减少多表间的关联操作，提高该场景下数据库查询性能和数据处理能力。

• 特别说明：有主键表可以支持指定 4096 列，无主键表因系统生成隐藏主键会占用 1 列，用户只可以指定 4095 列。

CLOG 日志文件支持按绝对值限制存储空间
早期 OceanBase clog 日志文件的存储空间阈值仅支持按照磁盘空间百分比进行限制，缺少直观性；同时对于部分共享存储，也无法准确表达使用空间水位大小。V3.1.5 社区版本在之前设计的基础上，支持使用空间绝对值限制的方式，替换固定磁盘规格限制，更灵活和易用。

• 新增集群级启动配置项 log_disk_size：用于控制单台 observer 存储 clog 日志文件的最大空间使用量。取值范围 [0G, +∞)，默认“0G”，表示以磁盘总空间为准。当 log_disk_size 配置为负数或者配置大于磁盘总空间时，会造成 observer 初始化失败。参数可修改，但需要重启 observer 才生效。
• log_disk_size 配置大于 0 时，磁盘使用上限由“磁盘总容量 * 可用百分比配置”变更为“log_disk_size * 可用百分比配置”。

新增支持 default_storage_engine 系统变量
为了方便 python django 框架适配，新增支持 default_storage_engine 系统变量，默认“OceanBase”。

行为变更

• 租户级配置项 undo_retention 默认值从“0”变更为“1800”，表示转储中默认保留 1800 秒的多版本数据。

问题修复
（1）修复约束名为空时未查重，导致出现重名约束进而导致刷 schema hang 住的问题。
（2）修复合并时卡住，报错 buffer not enough 问题。
（3）修复恢复租户时，clog 回放卡住问题。
（4）修复强制取消备份失败，备份状态一直为 stopping 的问题。
（5）修复 FULL 副本偶然出现 replica is not readable，查询耗时高的问题。
（6）修复 backup zone 耗时过长导致数据备份失败的问题。
（7）修复 add partition 时，sql 卡住的问题。
（8）修复执行 6 亿数据的存储过程，导致内存不足，kvcache清理不掉的问题。
（9）修复 insert ... on duplicate key update 语句报 5024-重复主键的问题。
（10）修复 observer.log 日志有大量 Fail to erase key from cache 报错的问题。
（11）修复 slog 回放报错导致备库重启失败的问题。
（12）修复 R 副本切换 F 副本失败的问题。
（13）修复扩容 datafile_size 后，部分 server 不生效的问题。
（14）修复 insert into ignore 执行出现卡住的问题。
（15）修复 JSON 生成列创建索引内存爆的问题。
（16）修复开启 schema history 回收后，可能导致物理恢复失败的问题。
（17）修复备份恢复后，索引状态不符合预期的问题。
（18）修复恢复中的租户开启归档失败的问题。
（19）修复开 ps 后，select NULLIF(NULL, '') from dual 返回 4016 的问题。
（20）修复自动清理任务正常调度时，预期被清理的 backup_piece 未删除的问题。
（21）修复只读视图不支持读取后写入其他表的问题。
（22）修复 replace into 多条数据到混合字符集的表，查询数据有乱码的问题。
（23）修复 json 类型转换为 int 类型失败的问题。
（24）修复 from_base64() 的参数为换行符、制表符时，与 mysql 不兼容的问题。
（25）修复 sql 改写时丢失 hint 的问题。
（26）修复当备份清理任务在 doing 阶段发生切主时，切主后继续清理任务可能会报 4016 问题。
（27）修复 select udf 后 group by having聚合函数嵌套里用 select 调用形参 udf , 系统无法识别传参字段的问题。
（28）修复同样 sql 执行计划有差异导致返回结果不一致的问题。
（29）修复 PL 中游标使用 ROWID 别名触发 ORA-00904: invalid identifier 报错的问题。
（30）修复几类特殊场景下节点出 core 的问题。

OceanBase 数据库社区版 V4.1.0

OceanBase 数据库 V4.0 社区版本是对分布式数据库系统架构设计的全面升级，OceanBase 数据库 V4.1 版本面向公有云&开源用户场景需求，在对功能健全优化的同时，不断对产品进行打磨和完善，在对 MySQL 8.0 兼容、性能、易用性、成本方面进行优化增强，目标支持项目规模化复制，是真正可全面商业化推广的版本。

版本概要

本版本的核心能力特性如下：

• 功能增强。

  支持 SQL 级资源隔离，租户级 IOPS 隔离优化，支持 Latin1 字符集等。

• MySQL 兼容性增强。

  MySQL 8.0 版本系统函数、变量和 SQL MODE 系统化完善，支持 GIS 数据类型。

• 性能提升。

  • TP 性能优化。

    • SYSBENCH 性能模型，综合读写性能（Read Write）1024 并发测试性能相比于 V4.0 版本提升约 40%。
    • TPCC 性能模型，tpmC (NewOrders) 1000 warehouse 测试性能相比于 V4.0 版本提升约 8%。

  • AP性能优化。

    • TPCH 查询性能优化，100GB 数据量顺序执行 22 条 SQL，整体性能相比于 V4.0 版本提升约 17%。
    • TPC-DS 查询性能优化，100GB 数据量顺序执行 99 条 SQL，整体耗时约 161s。

  • 数据导入性能优化，在 c6a.12xlarge 规格（48vCPU，96GB 内存）机器上使用旁路导入 LINEITEM 表（74GB），单 OBServer 节点导入速率可以达到 165MB/s。

  • 基于 OBProxy 的分布式事务路由优化，提升分布式事务性能。

  • 其它性能优化：Nest Loop Join 算子性能优化、Index Skip Scan 执行优化、Truncate Table 并行执行优化、 编译反馈优化。

• 稳定性增强。

  扩展支持 LOB 存储规格上限。

• 高可用增强。

  支持基于归档日志的物理备库，支持更多场景达成 RTO 时间降低到 8s 以内。

• 运维能力提升。

  • 支持 4.0 系列版本在线升级。

  • 实时统计信息收集。

  • 日志系统与可读性优化整改。

  • 持久化与存储优化：自适应合并（Compaction）、小表空间优化等。

• 产品形态。

  发布单机产品形态。

特性更新

功能增强

• 支持 SQL 级资源隔离。

  在实际项目交付中我们发现，客户业务希望能够对资源隔离进行更细微的控制，比如某个用户执行不同 SQL 使用不同的资源规格进行隔离（同一个租户下不同 user 的资源隔离、user 执行的不同 SQL 使用不同的资源），通过这种细粒度的应用方式帮助业务分配和隔离资源（通常为 OLAP 和 OLTP 业务的资源），减少业务之间的互相影响。

  OceanBase 数据库 V4.1 版本支持创建资源组，支持绑定用户与资源组，后续用户在执行的业务 SQL 时，OceanBase 数据库根据预定义的 SQL 规则匹配相应的资源组，通过使用 DBMS_RESOURCE_MANAGER 系统包帮助用户自定义业务资源隔离方案策略，当前该资源隔离方案仅支持 MySQL 模式下对 CPU 的资源隔离。

• 租户级 IOPS 隔离优化。

  OceanBase 数据库 V4.0 版本开始支持租户级 IOPS 隔离，通过在租户间按照 Unit 划分和租户内按照 IO 类别（category）划分的二级方式，可以基本保证租户内的不同任务只使用分配好的资源而不会挤兑其他任务，但同时也存在其他一些问题，例如 1）固定的 IO 类别不能支持用户根据任务作业定制，2）同一租户下的不同用户无法再进行资源隔离。因此我们将 IO 资源与 CPU 资源一样纳入到 Resource Manager 框架，实现用户界面统一的资源隔离体系。

  OceanBase 数据库 V4.1 版本通过 DBMS_RESOURCE_MANAGER 系统包来支持用户自定义 IO 资源隔离策略，通过在包函数 CREATE_PLAN_DIRECTIVE 设置 MIN_IOPS、MAX_IOPS 和 WEIGHT_IOPS 参数来设置隔离计划，IOPS 隔离方案同时支持 Oracle 租户与 MySQL 租户。

• 支持 Latin1 字符集。

  随着 OceanBase 数据库社区用户和海外客户数目的增多，越来越多的项目提出了 Latin1 字符集的需求，希望可以在数据库层面进行支持从而避免项目迁移过程中复杂的字符集转换工作。因此 OceanBase 数据库在 V4.1 版本对 Latin1 字符集进行新增支持，同时在 MySQL 模式支持 latin1_bin&latin1_swedish_ci 字符序，在 Oracle 模式下支持 latin1_bin 字符序。

MySQL 兼容

• MySQL 8.0 兼容，系统函数、变量和 SQL MODE 系统化完善。

  OceanBase 数据库 V4.0 及之前版本已经兼容了 MySQL 5.7 的大部分功能，但随着 OceanBase 数据库在公有云和社区上有了更多 MySQL 资深使用客户，其业务系统对 MySQL 8.0 存在特性依赖这个矛盾诉求愈加强烈。同时考虑到 MySQL 8.0 版本发布已有六七年时间，其版本特性也足够成熟。OceanBase 数据库从 V4.1 版本开始对 MySQL 8.0 能力进行系统化兼容支持，V4.1 版本主要包括如下：

  • 系统函数
    • 字符运算函数：BIN_TO_UUID() 、CHARACTER_LENGTH() 、LOAD_FILE()、IS_UUID() 、UUID_TO_BIN() 、OCTET_LENGTH()。
    • 时间日期函数：ADDTIME()、DAYNAME()。
    • 加解密函数：DECODE() 、DES_DECRYPT()、DES_ENCRYPT() 、ENCODE()、ENCRYPT()。
    • Perf 信息函数：FORMAT_BYTES() 、FORMAT_PICO_TIME()。
    • 信息函数：CURRENT_ROLE() 、ICU_VERSION()。
    • 窗口函数：BIT_AND()、BIT_OR()、BIT_XOR()。
    • 其他函数：NAME_CONST()。
  • SQL Mode
    • 独立SQL Mode：REAL_AS_FLOAT、TIME_TRUNCATE_FRACTIONAL。
    • 组合 SQL Mode：ANSI、DB2、MAXDB、MSSQL、ORACLE、POSTGRESQL、TRADITIONAL。
  • Information Schema
    • 视图兼容性：视图字段没有变化，字段类型或宽度或约束有兼容性调整。如VIEW_TABLE_USAGE、VIEWS、TABLES、STATISTICS、ENGINES、TABLE_CONSTRAINTS、REFERENTIAL_CONSTRAINTS、CHECK_CONSTRAINTS、PARAMETERS、ROUTINES、PARTITIONS 等。
    • 性能提升：基于本地表索引，普遍提升系统视图查询性能，如 STATISTICS 等。
  • Float(m, d)：完全兼容 MySQL 8.0 数据类型与精度。

• 支持 GIS 数据类型。

  空间信息系统（GIS）提供了对空间对象（点、线、面以及复杂的空间对象）的存储、计算、索引能力，在交通出行行业有着广泛的应用，可以帮助用户快速构建空间计算能力。OceanBase 数据库 V3.2.4 版本开始支持 GIS，OceanBase 数据库的 GIS 设计选择了基于四叉树空间划分的索引方案，支持兼容 MySQL 8.0 的 GIS 数据类型，支持 SRS（空间参考坐标系）元数据的管理及缓存，支持基于 QuadTree 的空间索引，支持单值类型（GEOMETRY/POINT/LINESTRING/POLYGON）和多值类型（MULTIPOINT/MULTILINESTRING/MULTIPOLYGON/GEOMETRYCOLLECTION），并实现 MySQL 8.0 常用的空间计算函数。

性能提升

• 数据导入性能优化。

  数据导入性能是 OLAP 领域内的一个重要衡量指标，在数据分析/大数据的业务应用中，数据量大是其中一个关键特征，那么如何将业务数据（text/csv 格式）快速的装载到数据库内部，对外提供查询分析服务，是会影响到 AP 领域数据库选择的技术能力和关键竞争力。

  数据库系统对于数据导入的通常做法是从客户端接收到数据，SQL 层进行数据解析，容错处理，路由分发，事务封装最后再进程存储持久化，这么做在设计上存在如下几个瓶颈点：1）一行一行数据进行，2）SQL 层过滤解析，3）CLOG 日志量大。因此 OLAP 系统数据库对此都有针对性优化，最常见的做法是通过旁路导入技术，将 SQL 的处理消耗代价屏蔽，使得数据可以直接持久化到磁盘上。

  OceanBase 数据库 V4.1 版本提供了旁路导入技术对数据加载执行路径进行精简，旁路导入跳过 SQL 层、事务模块、MemTable 等模块，直接将数据持久化到 SSTable，大大的提升了数据导入的速度。使用旁路导入能力需要为 load data 语句增加 HINT 标识，例如：load data /*+ direct(true , 1024) parallel(64) */ infile '/data/1/hits.tsv' into table hits Fields Terminated By '\t'; 通过视图 V$SESSION_LONGOPS 可以观测导入进度，支持多种模式主键冲突处理和过程容错，当前仅支持 CSV 格式数据文件。使用旁路导入在 c6a.12xlarge 规格（48vCPU，96GB 内存）机器上对 LINEITEM 表（74GB）进行数据导入测试，单 OBServer 节点导入速率可以达到 165MB/s。

• 基于 OBProxy 的分布式事务路由优化，提升分布式事务性能。

  在业务数据建模时通常要求其事务处理尽可能聚集在一个数据节点上，来避免分布式事务引发的跨节点访问性能下降问题。OceanBase 数据库早期版本仅能支持事务内请求在一个 OBServer 节点上完成协同处理，因此 OBProxy 无法按照 SQL 本身访问数据的位置进行路由，这带来了分布式事务内 SQL 处理延迟增加，导致性能下降。客户业务在性能压测中，很多时候需要通过调整SQL顺序去优化性能，投入大量时间精力调优来降低分布式事务路由带来的负面性能影响。

  OceanBase 数据库 V4.1 版本针对分布式事务路由进行优化设计，借助 OBProxy 可将事务运行状态同步到 OBServer 节点上，不需要都发给协调者，每条 SQL 语句都可以计算路由，从而可以确保 SQL 请求可以在集群内任意 OBServer 节点上执行，从而消除不必要的处理延迟。通过 OBProxy 的配置项 enable_disributed_route 可开启分布式事务路由优化，默认开启。当前不支持 XA 事务的路由优化。

• 编译反馈优化。

  通过编译反馈优化技术，在 SYSBENCH 测试模型下验证，性能综合提升约 10-15%。

• 其它性能优化。

  • Nest Loop Join 算子性能优化，多级 Nest Loop Join 算子在特定 Group Rescan 场景下性能提升约 10 倍。
  • Index Skip Scan 执行优化，NDV 算子的计算量超过 50 万行数据时，性能可提升约 10 倍。
  • Truncate Table 并行执行优化，Truncate Table 语句执行效率提升约 10 倍。

稳定性增强

• 扩展支持 DBMS_LOB 规格上限。

  在 OceanBase 数据库早期的版本中，LOB 数据存储大小限制在 48MB 以内，这对客户使用 LOB 带来了强约束限制。在本次架构升级中，通过存储层将 Lob 宏块的数据拆成多条 Lob Meta 进行存储，取数据的时候再将多条 Lob Meta 中的数据聚合成一个连续 Buffer 返回给 SQL 层处理，这样突破了数据存储大小的限制，通过普通 SQL 使用 LOB 规格扩展达到了 512MB，在 Oracle 模式下通过系统包 DBMS_LOB 使用 LOB 规格可扩展到 TB 级别。

高可用增强

• 支持基于归档日志的物理备库。

  如何不断提升数据库的高可用能力是 OceanBase 数据库设计之初的目标之一，OceanBase 数据库通过分布式架构技术和多副本数据管理，可以满足大部分场景下业务系统高可用诉求。但是在银行、保险等对数据库高可用有极端追求的客户业务中，单集群的两地三中心在跨城网络通信不佳的情况下依然存在服务不可用风险（即地域级容灾），因此 OceanBase 数据库推出了物理备库的方案来解决跨城地域级容灾问题。

  在 OceanBase 数据库早期的版本中，物理备库（V3.x 版本之前称为主备库）采用集群级日志传输的策略，主备集群需要相互感知日志同步状态且存在租户间日志耦合的问题。在 OceanBase 数据库 V4.1 版本中将集群级别粒度的物理备库细化到租户级别的物理备库，主租户与备租户相互不感知实现完成解耦，归档日志同步采用异步同步策略，通过三方介质 NFS/OSS 来完成，主备租户支持日志断点续传，Switchover 和 Failover 切换操作。在租户级的物理备库方案下，OceanBase 数据库的一个集群内即可以存在主租户也可以存在备租户，帮助业务应用获的更均衡的资源利用率。

• 支持更多场景达成 RTO 时间降低到 8s 以内。

  OceanBase 数据库 V4.0 版本架构升级针对分布式故障检测、分区选举能力进行优化和设计，使能够在故障恢复时缩短 RTO 的时间 <8s，但是故障场景是复杂和耦合的，在 V4.1 版本中继续识别分析分布式数据库故障场景，并加以优化使得在大多数场景下可以达成 RTO<8s 这个系统设计目标，主要完善优化场景如下：

  • 主 OBServer 节点故障宕机，连同 OBProxy 对外一起恢复服务。
  • 主 OBServer 节点的日志盘故障或数据盘故障，主节点报错但不退出，集群分区 Leader 进行迁移和选主后对外提供服务。此时可用副本数减少，故障的节点仍需要人工干预恢复。

运维能力提升

• 支持 4.0 系列版本在线升级。

  OceanBase 数据库 V4.0 版本是大的架构升级版本，其中存储数据、内部表、视图、配置项、部分功能行为均发生了不兼容变化，所以 V3.x 版本无法支持热升级到 V4.0 版本，建议通过 OMS 工具进行数据逻辑迁移进行升级。但是从 V4.1 版本开始，系统数据兼容和支持物理在线升级是 OceanBase 数据库核心关键能力目标，同时也是满足客户项目升级不中断诉求，降低升级复杂度和代价，助力 OceanBase 数据库 V4.1 版本在市场项目上应用和推广。

  OceanBase 数据库 V4.1 采用轮转升级的总体策略。

  1. 发起升级操作后，集群将进入混部状态，系统按 Zone 替换 OBServer 的二进制程序，直至全部节点替换完毕后退出混部状态，此时高版本的 OBServer 的二进制程序以兼容方式运行低版本的数据和行为。
  2. 在租户内执行升级命令，系统内部进行变量/系统表/数据校验和升级修正。集群内租户需逐一执行同样升级命令，最后完成集群整体升级。推荐使用 OCP 工具完成集群在线升级任务。

  OceanBase 数据库 V4.1 支持的升级场景如下：

  • 支持集群在线升级。
  • 支持主备集群升级，主备集群需各自升级。建议先升级备集群后主集群，升级前建议先通过 Switchover 命令将集群内租户状态调整一致。
  • 支持从 V4.0 版本开始的后续版本连续升级，包括功能版本和补丁版本。
  • 升级成功的 OBServer 节点不支持回退，因此建议升级前做好数据和二进制程序备份。
  • 支持租户级版本升级。但不推荐同一节点不同租户的版本长期不一致，建议集群内所有租户协同升级到同一版本。

  与此同时，升级过程中也存在如下约束限制：

  • 禁止 DDL 操作，升级完成后自动开启。
  • 禁止 Major Freeze 操作，升级完成后会自动开启。
  • 禁止迁移复制和负载均衡，升级完成后会自动开启。
  • 禁止物理备份恢复操作，升级完成后会自动开启。
  • 禁止 Switchover/Failover 操作，升级完成后会自动开启。
  • 禁止新建租户操作，升级完成后会自动开启。

• 日志系统与可读性优化整改。

  OceanBase 数据库 V4.1 版本对日志输出进行了系统性分析和优化调整，主要包括：

  • 日志级别定义：增加 DIAG 诊断日志级别，将无需用户感知的 WARN、ERROR 归到 DIAG 日志。对需要保留面向运维的预警/报错日志，进行日志级别分类调整，如下：

    日志级别	面向对象	定义	原日志级别
    ERROR	DBA/用户	OBServer 不能提供正常服务的异常，如磁盘满监听端口被占用等。也可能是产品后台的内部检查报错，例如 4377(dml defensive check error)，4103 (data checksum error) 等，需人工干预恢复。
    WARN	DBA/用户	出现非预期场景，OBServer 能提供服务，但行为可能不符合预期，例如写入限流告警。
    INFO	DBA/用户	系统状态变化信息。	INFO
    EDIAG	研发	Error Diagnosis，协助故障排查的诊断信息，非预期的逻辑错误，如函数参数不符合预期等。	ERROR
    WDIAG	研发	Warning Diagnosis，协助故障排查的诊断信息，预期内的错误，如函数返回失败。	WARN
    TRACE	研发	任务级调试信息。	TRACE
    DEBUG	研发	详细调试信息。	DEBUG

  • 错误码关联：分类错误消息并完善对应的错误码。为用户的每一条告警、错误定义响应的错误码，用户可根据错误码检索文档寻找解决方法。

  • 按错误码限流：针对 WDIAG 级别日志按错误码进行限流，被限流日志仅输出错误码及限流日志数。增加 diag_syslog_per_error_limit 配置项用于控制此限流功能，默认单个错误 200 条 DIAG 日志每秒。

  • 日志文件自描述：在日志文件头部增加记录机器地址、机型信息 CPU 类型、OS 版本、OBServer 版本和 TimeZone 信息等。

• 视图标准化优化，对视图/内部表进行重新整改设计，统一标准化视图输出共 73 个，推荐用户通过视图获取 OceanBase 数据库元数据等信息，更多信息请参见 文档链接。

• 实时统计信息收集。

  统计信息的准确度是优化器生产良好执行计划的基础，OceanBase 数据库早期版本已经支持多种方式生成统计信息：

  • 通过系统包 DBMS_STATS 或 ANALYZE 命令手动触发收集.
  • 通过定时任务自动收集统计信息.
  • 在数据量变化超过一定阈值时自动收集统计信息。

  在 OceanBase 数据库 V4.1 版本中我们新增支持 Online 统计信息收集能力，通过系统变量 _optimizer_gather_stats_on_load 或者 HINT 可以启用该能力，当业务支持 CTAS 或者 INSERT 语句时，OceanBase 数据库会实时增量更新统计信息，避免常规统计信息收集时全表扫描所带来的的系统开销。

• 持久化与存储优化。

  • 自适应合并（Compaction）：Compaction 会消耗大量的 IO 操作和 CPU 资源，因此针对不同的业务场景，需要采取不同的 Compaction 策略。在 LSM 存储体系下，Compaction 的核心目标是对这三类因子（写放大、读放大、空间放大）做最优平衡，自适应 Compaction 策略即是通过对表的历史转储、查询行为进行统计分析，抽取出当前 Tablet 特征，并依此判断该 Tablet 是否需要调度合并，在用户无感知的情况下完成合并。

  • 表空间优化：在小表多分区的场景下，宏块存储会有一定的存储放大现象，在分区数很多时容易出现磁盘空间不够的问题。通过将多个小 SSTable 存入一个物理宏块中进行合并存储，小表多分区场景下优化后宏块使用比例约 4%，宏块碎片比例约为 1.5%，大大提高了磁盘使用率。

产品形态

• 支持单机产品形态。

  随着 OceanBase 数据库 V4.0 版本单机分布式一体化架构升级逐步完成，我们也顺利推出 OceanBase 数据库单机产品，支持通过 OCP/OBD 来部署安装单机版本，来帮助 ISV、小客户、社区用户等快速上手体验 OceanBase 数据库 V4.1 版本所带来的新产品能力，同时我们支持单机版本在线转化升级为分布式版本，在数据管理规模无法满足项目要求或业务需要更高的高可用能力时，可以轻松实现“角色”转换。

性能报告

测试环境规格：

资源	规格
CPU 平台架构	x86_64
ECS 类型	ecs.g7.8xlarge
计算资源	32 核
内存资源	128GB
磁盘资源	500G ESSD 云盘
操作系统	CentOS Linux release 7.9.2009 (Core)

测试版本：

产品	版本信息
OceanBase 数据库 (V4.1)	OBServer (OceanBase_CE 4.1.0.0)
REVISION: 100000172023031416-6d4641c7bcd0462f0bf3faed011803c087ea1705
BUILD_TIME: Mar 14 2023 16:53:58
OceanBase 数据库代理 ODP (V4.1)	OBProxy (OceanBase 4.1.0.0 1)
REVISION: 5617-local-e6798c479feaab9f9a60b89f87e4df5e284250b6
BUILD_TIME: Mar 11 2023 21:42:11
OceanBase 数据库 (V4.0)	OBServer (OceanBase_CE 4.0.0.0)
REVISION: 103000022023011215-05bbad0279302d7274e1b5ab79323a2c915c1981
BUILD_TIME: Jan 12 2023 15:28:27
OceanBase 数据库代理 ODP (V4.0)	OBProxy (OceanBase 4.0.0 5)
REVISION: 1-local-9d5c90e562c61d9fcf8894993187aa20239db47e
BUILD_TIME: Oct 28 2022 23:01:19

SYSBENCH OLTP 负载测试

测试方案：

1. 通过 OBD 部署 OceanBase 集群，OBProxy 和 Sysbench 分别安装在两台机器上, 作为客户端的压力机器，避免资源抢占。其中 OBProxy 单独部署在 64c128g 的机器上（机型 ecs.c7.16xlarge）。
2. OceanBase 集群规模为 1：1：1，部署成功后先新建跑 Sysbench 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM，RANDOM 表示新建表分区的 leader 随机到这 3 台机器。
3. 启动 Sysbench 客户端，进行 point_select、read_write、read_only 和 write_only 测试。
4. 每轮测试 --time 设置为 60s，线程数取值可以为 32/64/128/256/512/1024。
5. 测试数据量为 30 张非分区表，100 万行数据，即 --tables=30，--table_size 设置为 1000000。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

测试结果：

Point Select 性能

Threads	V4.0 QPS	V4.0 95% Latency (ms)	V4.1 QPS	V4.1 95% Latency (ms)
32	139594.87	0.26	135146.05	0.27
64	257088.19	0.29	251219.37	0.30
128	453625.18	0.34	431564.13	0.36
256	746710.21	0.50	686271.21	0.55
512	964910.06	0.81	920502.51	0.92
1024	988444.97	1.64	972018.58	1.76

Read Only 性能

Threads	V4.0 QPS	V4.0 95% Latency (ms)	V4.1 QPS	V4.1 95% Latency (ms)
32	100505.96	6.43	117325.66	4.65
64	189356.32	6.55	214733.98	5.18
128	326115.21	7.43	370499.19	6.09
256	479483.89	10.46	572924.33	8.13
512	584193.84	19.29	705032.91	13.95
1024	561898.43	70.55	755182.87	28.16

Write Only 性能

Threads	V4.0 QPS	V4.0 95% Latency (ms)	V4.1 QPS	V4.1 95% Latency (ms)
32	38301.16	6.43	42329.95	5.37
64	71365.18	6.91	74408.79	6.09
128	117430.28	8.13	126026.90	7.30
256	182082.02	10.84	197493.43	9.56
512	252286.87	16.71	288284.95	13.95
1024	290982.27	31.37	354554.10	25.74

Read Write 性能

Threads	V4.0 QPS	V4.0 95% Latency (ms)	V4.1 QPS	V4.1 95% Latency (ms)
32	63498.13	12.30	74857.82	9.39
64	120362.58	12.52	138795.77	10.27
128	197802.61	15.55	234340.23	12.08
256	303103.47	20.37	365657.91	16.12
512	383006.31	33.12	479109.44	25.74
1024	389587.53	104.84	561333.10	48.34

BMSQL TPCC 测试

测试方案：

1. 通过 OBD 部署 OceanBase 集群，OBProxy 和 TPC-C 单独部署在一台机器上, 防止客户端的压力不足成为性能瓶颈。
2. 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPC-C 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

软件版本：

mysql-connector-java-5.1.47

Benchmark SQL V5.0

测试配置：

• warehouse = 1000
• loadWorder=40
• terminals=800
• runMins=5
• newOrderWeight=45
• paymentWeight=43
• orderStatusWeight=4
• deliveryWeight=4
• stockLevelWeight=4

测试结果：

	V4.0	V4.1
tpmC (NewOrders)	307021.0	332559.26
tpmTOTAL	682517.67	738374.78

TPCH 测试

测试方案：

1. 使用 OBD 部署 OceanBase 数据库集群。TPC-H 客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 OBProxy，测试时直连任意一台机器即可。
2. 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCH 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM。先执行数据装载，然后多次顺序执行 22 个 SQL 后取均值。
3. 测试数据量：100GB。

租户规格：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

测试结果：

Query	V4.0（s）	V4.1（s）
Q1	2.34	2.06
Q2	0.14	0.22
Q3	0.72	1.50
Q4	0.56	0.46
Q5	2.25	0.95
Q6	0.23	0.13
Q7	1.52	1.48
Q8	0.70	0.61
Q9	5.22	2.95
Q10	1.24	1.02
Q11	0.23	0.18
Q12	1.62	1.13
Q13	2.41	1.95
Q14	0.36	0.28
Q15	0.79	0.88
Q16	0.66	0.62
Q17	0.63	0.54
Q18	0.93	0.83
Q19	0.78	0.61
Q20	1.17	1.09
Q21	2.42	2.63
Q22	1.24	1.09
Total	28.16	23.21

TPC-DS 测试

测试方案：

1. 使用 OBD 部署 OceanBase 数据库集群。客户端需要部署在一台机器上, 作为客户端的压力机器。您无需部署 OBProxy，测试时直连任意一台机器即可。
2. 3 节点的 OceanBase 集群部署规模为 1：1：1，部署成功后先新建跑 TPCDS 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM。先执行数据装载， 然后多次顺序执行 99 个 SQL 后取均值。
3. 测试数据量：100GB。

租户信息：

• MAX_CPU = 26
• MEMORY_SIZE = 70g

测试结果：

Query	V4.1（s）
Q1	0.63
Q2	3.46
Q3	0.16
Q4	9.43
Q5	1.63
Q6	0.37
Q7	0.28
Q8	0.39
Q9	1.89
Q10	0.50
Q11	5.79
Q12	0.28
Q13	2.04
Q14	11.38
Q15	0.23
Q16	0.92
Q17	0.52
Q18	0.32
Q19	0.17
Q20	0.19
Q21	0.29
Q22	1.11
Q23	14.20
Q24	1.56
Q25	0.62
Q26	0.21
Q27	0.35
Q28	7.44
Q29	0.64
Q30	0.27
Q31	0.62
Q32	0.11
Q33	0.77
Q34	0.37
Q35	0.87
Q36	0.31
Q37	0.42
Q38	1.49
Q39	2.31
Q40	0.16
Q41	0.18
Q42	0.11
Q43	0.64
Q44	0.45
Q45	0.39
Q46	0.81
Q47	1.16
Q48	0.61
Q49	0.86
Q50	0.81
Q51	2.82
Q52	0.11
Q53	0.24
Q54	1.05
Q55	0.11
Q56	1.01
Q57	0.79
Q58	0.60
Q59	13.64
Q60	1.13
Q61	0.30
Q62	0.40
Q63	0.23
Q64	1.84
Q65	2.70
Q66	0.46
Q67	16.12
Q68	0.67
Q69	0.44
Q70	1.18
Q71	0.54
Q72	1.47
Q73	0.31
Q74	6.36
Q75	2.26
Q76	0.49
Q77	0.49
Q78	3.64
Q79	0.65
Q80	1.78
Q81	0.30
Q82	0.67
Q83	0.69
Q84	0.19
Q85	0.84
Q86	0.36
Q87	1.59
Q88	0.65
Q89	0.30
Q90	0.19
Q91	0.13
Q92	0.10
Q93	0.75
Q94	0.62
Q95	6.37
Q96	0.38
Q97	0.93
Q98	0.30
Q99	0.70
Total Time	160.83

兼容性变更

产品行为变更

功能	变更版本	变更点说明
浮点类型	4.1	V4.0：不再支持 float(m，d) 格式定义，仅支持 float(m) 和 float(m，0) 的格式定义。V4.1：完全兼容 MySQL 8.0 数据类型与精度
备份文件名后缀	4.1	新增后缀 .obbak 标识 OceanBase 数据库的数据备份的文件。新增后缀 .obarc 标识 OceanBase 数据库的日志归档的文件
UNUSABLE索引	4.1	删除分区后产生的 UNUSABLE 索引，通过备份恢复操作不会再恢复出来。
MAJOR FREEZE	4.1	新增支持指定一个租户和特定 Tablet 或特定表，发起合并任务。

视图/实体表/虚拟表

视图/实体表/虚拟表	用途及不兼容点说明	状态变化	变更版本
__all_virtual_plan_table	保存当前 session explain 的计划。	新增	4.1
__all_virtual_sql_plan	保存用户执行过的逻辑计划。	新增	4.1
__all_virtual_ha_diagnose	在诊断表中额外加入对于 gc 当前状态的诊断信息（gc_diagnose_info、restore_handler_role、 restore_handler_proposal_id、restore_context_info、restore_err_context_info）。	变更	4.1
__all_virtual_malloc_sample_info	查询各模块内存分配的堆栈信息。	新增	4.1
__all_ddl_task_status	增加 execution_id 列来标记 DDL 的每次单副本构建任务。	变更	4.1
__all_virtual_span_info	存放诊断信息。	新增	4.1
__all_virtual_show_trace	展示处理后的诊断信息。	新增	4.1
__all_virtual_io_scheduler 展示 IOPS 与带宽的统计信息。	新增	4.1
__all_virtual_io_status	展示不同租户、不同类别的请求 IO 排队情况。	新增	4.1
V$OB_SQL_AUDIT	新增加 PARTITION_HIT 字段，用于判断是否会发生分区路由，是否是远程执行。	变更	4.1
DBA_RSRC_PLAN_DIRECTIVES	展示 resource manager 中的 IO 资源配置情况	新增	4.1
V$OB_TABLET_STATS 自适应 Compaction 的 Tablet 级别的采集信息，有助于问题排查和定位。	新增	4.1
DBA_OB_TENANTS	扩展普通支持普通租户可查看，增加展示例如LOCALITY、同步位点、租户类型等信息（TENANT_ROLE、SWITCHOVER_STATUS、SWITCHOVER_EPOCH、SYNC_SCN、REPLAYABLE_SCN、READABLE_SCN、RECOVERY_UNTIL_SCN、LOG_MODE、ARBITRATION_SERVICE_STATUS）。	变更	4.1
V$OB_LOG_STAT	新增列 arbitration_member、degraded_list，表示仲裁成员和降级副本列表。	变更	4.1
V$OB_TRANSACTION_SCHEDULERS	展示事务的 scheduler 信息，有助于问题排查和定位。	新增	4.1
DBA_OB_ARBITRATION_SERVICE	展示当前集群的仲裁服务配置信息。	新增	4.1
DBA_OB_LS_ARB_REPLICA_TASKS	展示当前租户及对应用户租户正在运行中的仲裁副本任务。	新增	4.1
DBA_OB_LS_ARB_REPLICA_TASK_HISTORY	展示当前租户及对应用户租户执行过的仲裁副本任务历史。	新增	4.1
V$OB_ARCHIVE_DEST_STATUS	查询租户各个归档目的端状态。	新增	4.1
DBA_OB_LS_LOG_ARCHIVE_PROGRESS	展示日志流级别归档进度。	新增	4.1
DBA_OB_LS_LOG_RESTORE_STAT	展示日志流级别恢复汇总信息。	新增	4.1
DBA_OB_CLUSTER_EVENT_HISTORY	仅展示集群升级相关事件，仅系统租户可访问。	新增	4.1
DBA_OB_TENANTS	展示所有租户的基本信息。	变更	4.1

配置项变更

配置项	用途及不兼容点说明	状态变化	变更版本
ob_proxy_readonly_transaction_routing_policy	只读语句路由策略。	废弃	4.1
ob_plan_table_memory_limit	控制优化器保存逻辑计划使用的内存上限。	默认值 32MB，取值范围：1 - 1024。	4.1、
tenant_task_queue_size	租户请求队列长度。	默认值 65536 调整为 8192。	4.1
ob_enable_trace_log	是否启用 SQL Trace 功能。	废弃	4.1
ob_enable_show_trace	是否启用 Show Trace 功能。	默认值 0，关闭 Show Trace 功能。	4.1
_data_storage_io_timeout	配置数据盘最大 IO 超时时间。	默认值 120s 调整为 10s，取值下线 5s 调整为 1s。	4.1
_enable_pkt_nio	控制新的 RPC 网络框架 pkt-nio 的启用和关闭。	默认值 True。	4.1
rpc_memory_limit_percentage	租户下的 RPC 可以使用的最大内存。	默认值 0，表示不对 RPC 内存进行限制。	4.1
_private_buffer_size	配置日志数据达到 buffer size 时触发写日志。	默认值 256KB 调整为 16KB。	4.1
_mvcc_gc_using_min_txn_snapshot	是否用户使用活跃事务快照来保留多版本数据。	默认值 True。	4.1
_ob_enable_dynamic_worker	控制自适应线程功能的开关。	默认值 True。	4.1
data_storage_warning_tolerance_time	容忍数据盘 IO 失败的时间，超出则认为磁盘损坏。	默认值 5s，取值范围：1 - 300。	4.1
log_storage_warning_tolerance_time	容忍日志盘 IO 失败的时间，超出则认为磁盘损坏。	默认值 5s，取值范围：1 - 300。	4.1
_min_malloc_sample_interval	控制内存分配的最小采样间隔。	默认值 16，取值范围：1 - 10000。	4.1
_max_malloc_sample_interval	控制内存分配的最大采样间隔。	默认值 256，取值范围：1 - 10000。	4.1
ob_max_read_stale_time	Session 级别控制弱读延迟阈值, 当前 Session 上 weak 读请求，读到的数据一定在设定的延迟阈值内，不同 Session 可以设置为不同的延迟阈值。	默认值 5s。	4.1
log_archive_concurrency	控制日志归档总的工作线程数量，支持动态增加、减少线程数量。	生效范围由集群级变更为租户级。	4.1
log_restore_concurrency	控制物理恢复/备库恢复日志的工作线程数量，支持动态增加、减少线程数量。	生效范围由集群级变更为租户级。	4.1
_ob_enable_direct_load	是否开启旁路导入功能。	默认值 True。	4.1
_enable_transaction_internal_routing	事务内执行的 DML 语句是否可路由至任意 OBServer。	默认值 True。	4.1
log_restore_source	日志恢复路径。	默认值“”。	4.1
ob_startup_mode	observer 的启动模式。	默认值为 normal，指定为 arbitration 时表示以仲裁模式启动。	4.1
_ob_plan_cache_auto_flush_interval	控制定时自动 flush plan cache 的时间间隔。	默认值 0s，代表不进行自动 flush。	4.1
enable_user_defined_rewrite_rules	控制用户自定义规则是否开启的开关。	默认值 False。	4.1

升级说明

• 不支持从 V3.x 版本在线升级到 V4.x 版本。
• 支持通过 OMS 将 V3.x 版本数据使用逻辑迁移升级到 V4.1 版本。
• 支持从 V4.0 版本在线升级到 V4.1 版本。

周边配套

OceanBase 数据库 V4.1.0 推荐使用的平台工具版本如下。

组件	配套版本
OceanBase Database Proxy（ODP）	V4.1.0
OceanBase Connector/J	V2.4.3
OceanBase Connecotr/ODBC	V2.0.7
OceanBase Client（OBClient）	V2.2.2
OceanBase Deployer（OBD）	V2.0.0
OceanBase Agent（OBAgent）	V1.3.0
ob-operator	V1.2.0
MySQL JDBC	V5.1.47

约束限制

• OceanBase 数据库 V4.1.0 暂时不支持副本扩容后的数据负载均衡，扩容前已经存在的数据无法均衡到新添加的节点上，计划在 V4.2 版本完善负载均衡能力。
• OceanBase 数据库 V4.1.0 暂时不支持复制表，后续 V4.2 版本将补齐该能力。
• OceanBase 数据库 V4.1.0 支持从主集群发起数据备份，后续版本将支持从备集群发起数据备份。
• OceanBase 数据库 V4.1.0 节点在生产环境最低要求 运行规格为 4C16GB，租户内存资源大于 2GB，CPU 资源大于 1C。
• OceanBase 数据库 V4.1.0 当前仅支持 F 副本，其它类型副本如 R 副本将在后续版本补齐。
• OceanBase 数据库 V4.1.0 当前仅支持调大租户的 Unit 个数（UNIT_NUM），后续版本将支持调小租户的 Unit 个数。
• OceanBase 数据库 V4.1.0 支持从 V4.0 版本在线升级到 V4.1 版本，OBD 暂未适配完成，后续版本会补齐该能力。
• OceanBase 数据库 V4.1.0 版本 DROP DATABASE 操作一次删除数据库内的表的个数超过 200 个时存在删除失败的风险，建议业务先 DROP TABLE 后再执行 DROP DATABASE 操作，后续 V4.2 版本将修复该问题。

版本信息

信息	描述
发布时间	2023-02-10
版本号	V3.1.4 BP3
提交号	16544a206f00dd3ceb4ca3011a625fbb24568154

发版目的

本次发版主要是BUG修复，提升版本稳定性。

新增功能

• 备份恢复支持OSS存储介质。

BUG修复

• 修复bug 备份介质不可用时日志归档导致副本迁移失败
• 修复bug 新建分区归档落后导致迁移复制卡住
• 修复bug 事务提交和切主并发场景下的事务卡住情况
• 修复bug 停止备份后无效的piece_id导致日志卡在stopping状态
• 修复bug 非mini模式下lock-wait-mgr休眠太久的情况
• 修复bug insert into ignore 执行卡住
• 修复bug varbinary类型校验字符集导致插入报错 #1088

版本信息（V4.0.0 BP3）

项目	描述
发布日期	2023-01-12
版本号	V4.0.0.0 BP3
commit号	05bbad0

发版目的

本次发版主要是BUG修复,提升版本稳定性。

BUG 修复

1.[Bug]: NULL changed to '' after adding DISTINCT [3.1.4, 4.0.0]#1248
2.[Bug]: Unit testing make fail #1273
3.fix last_active_time reset bug when change user
4.fix physical restore report -4018 issue
5.[CP] [CP] fix connect by memory leak
6.fix size overflow when reconstruct sql
7.Fix 4.0.0 allocator deconstruction core bug
8.Fix migration reuse local major makes checksum error
9.fix insert oom caused by wrap allocator's interface empty
10.Fix full outer join with for update causing core
11.Fix observer core at create tablet for migration
12.fix null complex argument core
13.Fix deadlock when auto increment service alloc handle
14.fix ret= -4016 when switch leader
15.fix merge into result error when hitting plan cache

注意事项

1. obdv1.6.2开始支持4.0 observer版本间的升级；
2. ocp4.0-ce-bp1版本开始支持observer版本间升级；