Skip to content

v4.2.2_CE
Compare
Choose a tag to compare
@zhuzhaoyang001 zhuzhaoyang001 released this 17 Jan 13:42
· 5650 commits to develop since this release
v4.2.2_CE
fac02c6

Version information

Information Description
Release date January 17, 2024
Version V4.2.2_CE
Commit number fac02c6
OBServer RPM version oceanbase-ce-4.2.2.0-100000192024011915

Overview

OceanBase Database V4.2.2_CE is a follow-up to V4.2.1_CE. This version comes with enhancements to the database kernel, with a restructuring of the row-based cost estimation system and statistics collection mechanism. It also introduced support for lateral derived tables, order preservation for paging queries, and DBLink-based remote UDF calls to enhance MySQL compatibility. Additionally, OceanBase Database V4.2.2_CE now supports GIS, XML, and JSON data types to expand the multi-mode feature. This version also added support for SQLSTAT, TIME MODEL, and manual partition transfer to improve the ease of use. Furthermore, it optimized system resource usage by reducing temporary index space occupation and supporting OBKV RPC compression. OceanBase Database V4.2.2_CE also improved the performance of minimum specification databases and enhanced system stability.

Key features

Kernel enhancements

  • Enhancement of the row-based cost estimation system

    As OceanBase Database evolves, more cost estimation methods are supported for optimizers. Currently, OceanBase Database supports a variety of algorithms for row-based cost estimation by each operator, such as storage-layer cost estimation, statistical estimation, dynamic sampling, and default statistics. In OceanBase Database V4.2.2_CE, the row-based cost estimation system was restructured, prioritizing cost estimation strategies based on specific use cases and introducing tools like hints and system variables for manual intervention in strategy selection. Additionally, the new version further enhanced the framework for calculating predicate selectivity and number of distinct values (NDV), thereby improving the accuracy of optimizers' cost estimation.

  • Enhancement of the statistics feature

    On the basis of V4.2.1_CE, V4.2.2_CE further improved the statistics feature in terms of statistics collection performance, compatibility, and ease of use. Specifically, this version restructured the offline statistics collection process, improved the statistics collection efficiency, and optimized the statistics collection strategy. The system now automatically collects index histograms by default, derives statistics to ensure transactional consistency during online statistical gathering, and is compatible with the ANALYZE TABLE feature of MySQL to support more syntaxes. This version now provides a command to cancel statistical collection, supports progress monitoring for statistics gathering, and improves operational usability. It also provides the capability for parallel deletion of statistical data.

  • Optimization of large IN queries

    Currently, in scenarios where the right side of the IN predicate contains many constants (referred to as "large IN query"), there is a noticeable consumption of CPU and memory during the hard parsing stage. To address these large IN queries, V4.2.2_CE implemented a new query range extraction algorithm. Moreover, when the number of values in the IN list exceeds 1000, OceanBase Database triggers a rewrite from the IN list to the VALUES table to reduce resource consumption and improve performance.

  • Enhancement of the execution engine

    OceanBase Database V4.2.2_CE implemented a series of optimizations at the SQL execution layer, such as enhancements to recursive CTE searches, the integration of window functions with automatic memory management, improvements to adaptive hash group by for data skew optimization, the refinement of hash-based distinct aggregate strategy, and optimizations for the adaptive hash group by strategy. These enhancements help to boost the performance of SQL execution and increase system stability.

  • Optimization of the recompilation logic in PL cache

    After a stored procedure is compiled as a shared library, it can be used by multiple threads. However, if the dependent objects are changed, the shared library may become invalid and must be recompiled. OceanBase Database V4.2.2_CE reviewed and refined the recompilation scenarios. It implemented a series of logic optimizations in terms of temporary table matching, dependency information collection for static SQL statements, and DDL operations on tables, to avoid recompilation when cached objects in the PL cache become invalid.

  • Persistence of PL compilation results

    In previous versions, the compiled PL functions and procedures were retained in the PL cache, which risked eviction under tight memory conditions. This meant that the compilation results could be lost after a system restart and a recompilation was required in distributed environments. Consequently, PL statements missing the cache would initiate an low-level virtual machine (LLVM) compilation, incurring CPU usage. However, starting from OceanBase Database V4.2.2_CE, the compiled PL functions and procedures are now persistently stored in system tables. As long as no DDL operations invalidate the cache, these functions and procedures require compilation only once and can be reused after a restart or in a distributed environment.

  • Embedding of session variables for function indexes

    When a function index is created, a hidden virtual generated column is added to the primary table, defined as the index key of the function index, and then the values of this column are stored in the index table. The session variables can influence the output of some built-in system functions, resulting in different outcomes despite identical input parameters. To enhance the reliability of generated columns and function indexes, the latest release ensures that any session variables the function depends on are embedded directly into the index or generated column's schema. Consequently, when calculating values for these columns, the system employs these embedded, unchanging values, thereby rendering the current session's variable values irrelevant. In OceanBase Database V4.2.2_CE, system variables that can be embedded include timezone_info, nls_format, nls_collation, and sql_mode.

  • OBCDC allowlists and blocklists

    OceanBase Change Data Capture (CDC) already supports tenant-level log synchronization. Starting from OceanBase Database V4.2.2_CE, database-level and table-level log synchronization are supported. The system now supports the configuration of allowlists and blocklists using simple regular expressions to accommodate scenarios where users require data synchronization for only a subset of tables.

Compatibility with MySQL

  • Lateral derived tables

    Lateral derived tables are a special type of derived tables that can reference columns from preceding tables within the same FROM clause. This makes SQL statements easier to read and write, and reduces repeated data scanning and calculation, thereby improving the performance of SQL execution.

  • Order preservation for paging queries

    Due to factors such as plan selection and parallel execution, the output results of the LIMIT OFFSET clause are unstable for most databases. To ensure a stable and ordered output, it is necessary to add an ORDER BY clause to the outer layer of each SQL statement. Although native MySQL Database does not guarantee an ordered result set, many of its queries still produce ordered results. To avoid extensive restructuring for paging queries during data migration from a MySQL database, OceanBase Database has introduced a feature that preserves order in paging queries. However, there may be some performance degradation compared with the unordered behavior, particularly with large data volumes. For business scenarios that require order preservation, you can consult OceanBase Technical Support to assess the impact on performance. If the impact is acceptable, enable this feature by using a parameter.

  • Online DDL operations for integer type expansion

    In the context of a primary key column, partitioning key column, index column, column referenced by a generated column, or a column with a CHECK constraint, there may be a need to change its integer type to accommodate a larger value range, such as from INT to BIGINT. In OceanBase Database V4.2.1_CE, this type of change was performed using an offline DDL operation with doublewrites, resulting in table locks that blocked read and write access. However, starting from V4.2.2_CE, this change is implemented using an online DDL operation without affecting business writes.

  • Local import from the client

    Prior to V4.2.2_CE, OceanBase Database supported file import from the server, Network File System (NFS), and Object Storage Service (OSS) through SQL import in either standard or bypass mode. However, importing files from the client side required the use of tools like OBLOADER and could not be done directly using SQL statements. To facilitate data developers in performing local import tests and to address the issue of inconvenient data import due to the inability to log on to the server in cloud environments, V4.2.2_CE added new support for client-side local data import (LOAD DATA LOCAL INFILE). This feature allows for local file import through streaming file processing.

  • Support for output parameters in prepared statements

    In OceanBase Database V4.2.2_CE, executing the CALL PROCEDURE statement via the prepared statement (PS) protocol in MySQL mode now supports stored procedures with output parameters.

  • Improvement in communication protocol

    OceanBase Database V4.2.2_CE now supports the MySQL communication protocol command COM_SET_OPTION for specifying connection-level options such as MYSQL_OPTION_MULTI_STATEMENTS_ON and MYSQL_OPTION_MULTI_STATEMENTS_OFF. It also supports the MySQL AuthSwitchRequest protocol for switching authentication methods and solving authentication errors caused by client version incompatibilities.

  • Support for SHOW EXTENDED syntax of MySQL 8.0

    OceanBase Database V4.2.2_CE now supports the SHOW EXTENDED syntax introduced in MySQL 8.0, such as SHOW EXTENDED TABLES, SHOW EXTENDED COLUMNS, and SHOW EXTENDED INDEX.

  • Support for utf8mb4_unicode_ci and utf16_unicode_ci collations

    OceanBase Database V4.2.2_CE now supports the utf8mb4_unicode_ci and utf16_unicode_ci collations.

Multi-model features

  • MySQL GIS enhancement

    OceanBase Database V4.1.0_CE introduced support for MySQL GIS data types and associated spatial expressions. Building on this, V4.2.2_CE further enhanced the capabilities for storing, computing, and analyzing spatial data by adding support for MySQL-compatible expressions such as ST_Crosses, ST_Overlaps, ST_Difference, ST_Union, ST_SymDifference, ST_Length, ST_Centroid, and ST_AsGeoJSON. Additionally, as PostgreSQL (PG) is widely used in the GIS sector and offers some expressions that differ from those in MySQL, OceanBase Database also extended its support to include _ST_Touches, _ST_Equals, _ST_MakeEnvelope, _ST_ClipByBox2D, _ST_GeometryType, _ST_IsCollection, _ST_NumInteriorRings, _ST_PointOnSurface, ST_AsMVTGeom, and _ST_AsMVT, along with capabilities for storing three-dimensional spatial objects.

  • MySQL XML

    OceanBase Database V4.2.2_CE now supports the ExtractValue and UpdateXML expressions.

  • MySQL JSON

    OceanBase Database V4.2.2_CE now supports the JSON_SCHEMA_VALID, JSON_SCHEMA_VALIDATION_REPORT, and JSON_ARRAY_APPEND expressions.

  • MySQL JSON Partial Update

    In scenarios where JSON documents are used for storing business data, updates currently require full document reads and rewrites, which can be inefficient for large documents. V4.2.2_CE introduced support for JSON Partial Update, allowing users to update specific parts of a JSON document through certain expressions (such as JSON_SET, JSON_REPLACE, and JSON_REMOVE) without the need to overwrite the entire document. This enhances update performance and can be enabled through the log_row_value_options parameter.

Performance improvements

  • Performance improvement for the minimum specifications

    For the minimum specifications of 4C16G, OceanBase Database V4.2.2_CE implemented a series of improvements in terms of background thread usage, location cache access, primary read/write path, and system calls. During a Sysbench benchmark consisting of 30 tables under stress testing, each table containing 500,000 rows of data within a single primary zone setup, OceanBase Database V4.2.2_CE has demonstrated a performance boost ranging from 10% to 30% compared with V4.2.0_CE.

    Scenario Read/Write Write-only Read-only Select Insert Update
    V4.2.0_CE with default parameters 1330 4714 2334 67776 20880 21507
    V4.2.2_CE with default parameters 1520 5652 2645 77910 25798 27433
    Performance improvement ratio in contrast to V4.2.0_CE 14% 20% 13% 15% 24% 28%

  • Parallel synchronization in a single log stream

    Prior to V4.2.2_CE, OceanBase Database used a log synchronization model that processed multiple log streams in parallel, but handled each individual log stream through a pipeline mechanism. This was adequate for scenarios where logs were consumed from local storage within the same city. However, this model proved less effective when the standby database was located in a remote area or when logs were read from object storage. OceanBase Database V4.2.2_CE introduced a new parallel synchronization model for single log streams based on file data blocks. This update considerably improves synchronization efficiency and optimizes memory usage.

Resource optimization

  • OBKV RPC compression

    OBKV has introduced a new feature for compressing RPC messages in the response packets of query requests. This feature is particularly useful in situations where the network bandwidth between the client and server is limited. By compressing the RPC messages, it substantially reduces the amount of data that needs to be transferred over the network, thus minimizing bandwidth usage.

  • Enhanced resource control for bypass import

    The bypass import feature supported by OceanBase Database V4.x significantly increased data import speeds. However, when users set a high degree of parallelism with many concurrent bypass import tasks, there can be an excessive consumption of threads and memory without strict resource control, potentially impacting other ongoing tasks. OceanBase Database V4.2.2_CE introduced enhanced resource management for bypass imports across three dimensions:

    • A new task-level resource management module was provided. This module allocates appropriate thread and memory resources based on the execution mode and number of partitions of each import task.

    • A tenant-level resource management module was provided to manage the thread and memory resources allocated for bypass imports. This module uses scheduled tasks to monitor changes in the resource pool and reclaim resources allocated to import tasks that were disrupted unexpectedly.

    • An OBServer-level resource management module was provided to record node-level resource allocations. This module dynamically adjusts the available memory during the sorting phase of bypass import tasks based on the number of tasks.

  • Cascading of read-only replicas by region

    OceanBase Database supports read-only replicas for weak-consistency reads and replication tables since V4.2.0_CE. A read-only replica synchronizes logs by registering as a downstream of either a full-featured replica or another read-only replica. When multiple read-only replicas and their upstream replicas are deployed across different regions, they may consume additional cross-region network bandwidth. In V4.2.2_CE, read-only replicas are enhanced with the capability to recognize their region, allowing them to prioritize log synchronization with other replicas within the same region whenever possible. This efficiently reduces cross-region data transfer and conserves cross-region bandwidth resources.

  • Space optimization for partitioned local indexes

    During the process of creating indexes on existing tables, internal SQL statements are sent to load index table data. If a node contains a substantial amount of data, the sorting process may result in a temporary amplification of disk space usage. OceanBase Database V4.2.2_CE introduced a progressive execution strategy for backfilling data into index tables. With this strategy, a single node processes 1 GB of data per batch, while multi-node tasks are executed in parallel. This approach not only leverages the parallel computing capabilities of the distributed system but also addresses the issue of temporary space amplification that may occur during index construction.

  • Memory consumption optimization for JSON/XML aggregate functions

    OceanBase Database V4.2.2_CE optimized the memory consumption during the execution of aggregate functions such as XMLAGG and JSON_OBJECTARRAY,

High availability enhancements

  • Verification of primary/standby tenant switchover

    OceanBase Database supports tenant-level primary/standby switchover. For example, you can change the role of a standby tenant to the primary tenant through a switchover without data loss, or through a failover with data loss. However, the role switching can fail. To reduce the risks of role-switching failures, OceanBase Database V4.2.2_CE introduced a verification feature for primary/standby switching (SWITCHOVER/FAILOVER VERIFY). By appending a VERIFY keyword after the switchover or failover command, you can check in advance whether the operation can be performed. If the operation cannot be performed, an error is returned. In this case, you can refer to the suggested actions to address the issue accordingly.

  • Proactive broadcasting/refreshing of tablet locations

    OceanBase Database provided a periodic refresh mechanism for the location cache, ensuring real-time updates and eventual consistency for log stream location information. However, the tablet location was only equipped with passive refresh capabilities, which meant that changes in the mapping relationship between tablets and log streams could sometimes trigger SQL retries and read/write errors. V4.2.2_CE introduced an active broadcasting feature for tablet location, which reduced SQL retries and read/write errors caused by mapping relationship changes after a transfer. It also provides an active refresh fallback to avoid irrecoverable read/write errors.

Security enhancements

  • Operating system configuration check upon OBServer node start

    Inappropriate operating system configurations can incur system issues. OceanBase Database V4.2.2_CE supports checking core operating system parameters. Two check modes are supported: loose and strict. In loose check mode, if the operating system parameters do not meet the requirements, a WARNING log is recorded, without affecting the start of the OBServer node. In strict check mode, if the operating system parameters do not meet the requirements, an ERROR log is recorded, and the OBServer node cannot be started.

  • PL privilege management in MySQL mode

    The MySQL mode of OceanBase Database now supports PL privilege management, including the CREATE ROUTINE, EXECUTE, and ALTER ROUTINE privileges. It also supports the mysql.procs_priv view, which displays privilege grants on stored procedures or functions.

Improvement in ease of use

  • SQLSTAT for performance diagnostics

    Previous versions of OceanBase Database provided methods for identifying performance issues through SQL AUDIT and PLAN STAT. However, they lacked user-friendly tools for locating problems with SQL statements that were either currently executing or had executed. OceanBase Database V4.2.2_CE introduced the new SQLSTAT feature, which records the execution status of SQL statements and their statistical information in real time. Together with the workload repository (WR) feature, it becomes much easier to identify the top SQL statements that have the greatest impact on performance, which further facilitates automated diagnostics. You can view the basic performance statistics for all current SQL statements through the [G]V$SQLSTAT view, and access performance statistics information for the top SQL after persistence through the CDB/DBA_WR_SQLSTAT view.

  • Time statistic models

    To promptly reflect the databases' load and obtain accurate database time, OceanBase Database V4.2.2_CE now supports time statistics models at the session and tenant levels. It introduces nine new metrics: DB time, DB CPU, non-idle wait time, idle wait time, background elapsed time, background CPU time, background database time, background database non-idle wait time, and background database idle wait time. These metrics can be used for problem diagnosis and performance tuning. You can view the statistical information through the [G]V$SYSSTAT and [G]V$SESSTAT views. Additionally, the WR module will collect and persist these statistics to the DBA_WR_SYSSTAT view at a default interval of one hour.

  • Manual partition transfer

    OceanBase Database already features an automatic load balancing mechanism which can automatically adjust the distribution of partitions to facilitate online scaling and partition-level load balancing. However, in practical business scenarios, users may have specific requirements for data distribution, desiring to consolidate or disperse particular partitions. V4.2.2_CE introduces a new partition transfer feature, allowing users to migrate specific partitions to designated log streams, and offers the capability to monitor the status of these tasks.

  • Event logging for primary and standby tenants

    Prior to OceanBase Database V4.2.2_CE, events such as primary/standby tenant switchover and failover were recorded within RootService events. Over time, these RootService event logs would be purged, and tenant-level records were intermingled with cluster operation records, making them difficult to locate. In V4.2.2_CE, operations for primary/standby tenants have been segregated under each individual tenant, and are now accessible through the CDB/DBA_OB_TENANT_EVENT_HISTORY view for easier tracking and review.

  • Decoupling of PL logs from SQL logs

    Currently, SQL statements executed through PL reuse the PL's trace ID. This results in an excessive volume of logs associated with a single trace ID, making filtering and troubleshooting through the logs quite time-consuming. In V4.2.2_CE, OceanBase Database decouples the logs of PL and SQL. SQL statements executed within PL are assigned unique trace IDs. Additionally, the external PL trace ID is recorded in the SQL AUDIT log to effectively enhance the efficiency of troubleshooting.

  • PL execution time statistics

    The PL execution performance may fail to meet the expectations in business scenarios. At present, no easy method is available for you to quickly analyze whether a large amount of time is consumed in internal SQL statements or PL structures. OceanBase Database V4.2.2_CE now supports new execution time statistics for PL structures. These statistics can be directly obtained through the PLSQL_EXEC_TIME column in the [G]V$OB_SQL_AUDIT view.

  • Binding both an execution plan and a throttling rule to an outline

    In earlier versions, you can bind an execution plan or a throttling rule to an outline, but not both. To cope with scenarios where an execution plan must be interfered with and an SQL statement must be throttled, OceanBase Database V4.2.2_CE now allows you to specify max_concurrent() and other hints in an outline creation statement. Since the execution plan does not support the use of the wildcard ? to bind with sql_text, when execution plans and rate limiting are bound together, they are subject to the same constraints. The method of binding via sql_id remains unchanged.

  • Dynamic configuration of the LOB storage mode

    At present, when large object (LOB) data is less than or equal to 4 KB in size, it is stored in INROW (in-memory storage) mode. If it exceeds 4 KB, the data is stored in the LOB auxiliary table. In some scenarios, if the data size does not exceed the row-level storage specification limits, INROW storage can offer better performance for whole storage and retrieval compared with using an auxiliary table. Therefore, OceanBase Database 4.2.2_CE provides the ability to dynamically configure INROW size, allowing users to adjust the INROW threshold based on their specific business needs.

Performance test report

The performance test data of OceanBase Database V4.2.2_CE is as follows:

  • Test environment specifications

    • OBServer node (1:1:1)

      Type Specification
      CPU architecture x86_64
      ECS type ecs.g7.8xlarge
      Compute 32 cores
      Memory 128 GB
      Disk System disk: 300 GB, cloud disk: 2 × 400 GB, performance level: PL1
      Operating system CentOS 7.9 64-bit

    • OceanBase Database Proxy (ODP) (1)

      Type Specification
      CPU architecture x86_64
      ECS type ecs.c7.16xlarge
      Compute 64 cores
      Memory 128 GB
      Operating system CentOS 7.9 64-bit

  • Version for test

    Product Version information
    OBServer (V4.2.2)
    • OBServer: OceanBase_CE 4.2.2.0
    • REVISION: 1-87b81aa4bc5603ac81fd5e0c896b9ced01d78739
    • BUILD_TIME: Jan 3 2024 14:53:33
    ODP (V4.2.1)
    • ODP: OceanBase 4.2.1.0
    • REVISION: 1-local-6599462fc897a4a46734d64585906ea80975a656
    • BUILD_TIME: Oct 12 2023 21:03:30

  • Tenant specifications

    • MAX_CPU = 26
    • MEMORY_SIZE = 100g

OLTP test with Sysbench

  • Parameter tuning

    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;

  • Test specifications

     obd test sysbench rn --tenant=perf --script-name=xxx.lua --table-size=1000000 --threads=xx  --report-interval=1 --rand-type=uniform --time=30 --db-ps-mode=disable

  • Test results

    • Point select performance

      Threads V4.2.2_CE zone1 QPS/95%rt (unit: milliseconds) V4.2.2_CE RANDOM QPS/95%rt (unit: milliseconds)
      32 144562.71/0.26 150002.69/0.24
      64 255157.22/0.30 279256.71/0.27
      128 380483.96/0.51 489197.56/0.30
      256 505118.71/0.90 791088.58/0.46
      512 589809.56/1.42 1041150.67/0.83
      1024 600025.98/3.30 1053486.24/2.18

    • Read-only performance

      Threads zone1 QPS/95%rt (unit: milliseconds) RANDOM QPS/95%rt (unit: milliseconds)
      32 124411.49/4.49 131753.27/4.18
      64 209992.12/5.57 241825.11/4.65
      128 283414.89/8.74 414202.92/5.57
      256 317012.12/19.29 638432.40/7.30
      512 337949.54/39.65 798094.11/15.00
      1024 331738.82/77.19 798567.76/34.95

    • Write-only performance

      Threads zone1 QPS/95%rt (unit: milliseconds) RANDOM QPS/95%rt (unit: milliseconds)
      32 62842.72/3.96 46505.45/6.09
      64 123026.83/4.65 88264.25/5.99
      128 172264.95/6.09 153548.94/6.43
      256 221739.40/9.73 227430.99/8.74
      512 242756.24/23.10 292273.10/14.46
      1024 252565.64/36.24 324863.22/35.59

    • Read/Write performance

      Threads zone1 QPS/95%rt (unit: milliseconds) RANDOM QPS/95%rt (unit: milliseconds)
      32 95173.19/7.98 83309.88/9.56
      64 164018.31/9.06 151101.81/10.27
      128 222046.91/22.69 268784.90/11.65
      256 272321.09/33.72 394488.45/15.00
      512 298693.98/53.85 523029.07/31.37
      1024 292904.80/108.68 598383.51/50.11

TPC-C benchmark test with BenchmarkSQL

  • Parameter tuning

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

# sys tenant
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;

  • Test specifications

    obd test tpcc rn --tenant=perf --tmp-dir=/data/2/tpcc  --warehouses=1000 --load-workers=40 --terminals=800 --run-mins=5 -v -O 2

  • Test results

    Test type zone1 RANDOM
    tpmC (NewOrders) 150354.01 303653.87
    tpmTOTAL 334152.04 674530.08
    Transaction count 1671628 3395842

TPC-H benchmark test

  • Parameter tuning

    # sys tenant
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;

# Test tenant
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;
# parallel_servers_target = max_cpu * server_num * 8
SET GLOBAL parallel_servers_target = 624;

  • Test specifications

    obd test tpch rn --user=root --test-server=server1 --tmp-dir=/data/2/ob   --tenant=perf --remote-tbl-dir=/home/admin -s 100

  • Test results

    Query RANDOM (unit: seconds)
    Q1 2.26
    Q2 0.50
    Q3 1.49
    Q4 0.61
    Q5 0.97
    Q6 0.15
    Q7 1.41
    Q8 0.94
    Q9 4.42
    Q10 1.10
    Q11 0.18
    Q12 1.18
    Q13 1.93
    Q14 0.30
    Q15 0.43
    Q16 0.61
    Q17 1.63
    Q18 0.93
    Q19 0.64
    Q20 1.43
    Q21 2.70
    Q22 1.20
    Total 27.01

TPC-DS benchmark test

  • Parameter tunning

    # sys tenant
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;

# Test tenant
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;
# parallel_servers_target = max_cpu * server_num * 8
SET GLOBAL parallel_servers_target = 624;

  • Test specifications

    100 GB

  • Test results

    Query RANDOM (unit: seconds)
    Q1 0.36
    Q2 1.15
    Q3 0.16
    Q4 10.63
    Q5 1.50
    Q6 0.23
    Q7 0.30
    Q8 0.27
    Q9 1.96
    Q10 0.57
    Q11 6.69
    Q12 0.19
    Q13 0.58
    Q14 11.37
    Q15 0.57
    Q16 0.92
    Q17 0.49
    Q18 0.35
    Q19 0.21
    Q20 0.21
    Q21 0.20
    Q22 1.18
    Q23 14.96
    Q24 1.48
    Q25 0.58
    Q26 0.23
    Q27 0.43
    Q28 6.67
    Q29 0.66
    Q30 0.31
    Q31 0.69
    Q32 0.12
    Q33 0.77
    Q34 0.52
    Q35 0.99
    Q36 0.31
    Q37 0.46
    Q38 1.59
    Q39 0.85
    Q40 0.18
    Q41 0.05
    Q42 0.13
    Q43 0.61
    Q44 0.49
    Q45 0.40
    Q46 0.56
    Q47 1.14
    Q48 0.67
    Q49 0.97
    Q50 0.69
    Q51 2.94
    Q52 0.13
    Q53 0.25
    Q54 1.04
    Q55 0.12
    Q56 0.65
    Q57 0.80
    Q58 0.91
    Q59 3.03
    Q60 0.77
    Q61 0.39
    Q62 0.42
    Q63 0.26
    Q64 1.96
    Q65 2.56
    Q66 0.54
    Q67 9.47
    Q68 0.49
    Q69 0.51
    Q70 1.20
    Q71 0.60
    Q72 5.53
    Q73 0.37
    Q74 4.24
    Q75 2.47
    Q76 0.64
    Q77 0.82
    Q78 3.43
    Q79 0.73
    Q80 1.19
    Q81 0.24
    Q82 0.74
    Q83 0.65
    Q84 0.21
    Q85 0.59
    Q86 0.33
    Q87 1.67
    Q88 0.72
    Q89 0.32
    Q90 0.23
    Q91 0.15
    Q92 0.13
    Q93 0.75
    Q94 0.66
    Q95 6.40
    Q96 0.39
    Q97 0.97
    Q98 0.32
    Q99 0.74
    Total time 142.27

Compatibility changes

Product behavioral changes

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

Change Description
The size of a single log is extended to 3.5 MB. When the amount of data in a single row is large, the space for a single log is insufficient. To address this issue, OceanBase Database extends the size of a single log to 3.5 MB since V4.2.2_CE. You can use the ob_admin tool to view the clogs.
The zlib compression algorithm is no longer used for storage. In OceanBase Database V4.2.0_CE, it is prohibited to use the zlib algorithm to compress newly created tables. However, existing tables can still be compressed by using the zlib algorithm. The zlib compression algorithm is no longer used for the storage layer since OceanBase Database V4.2.2_CE. If the zlib compression algorithm is used for data tables in the source version, you must change the compression algorithm to another before the upgrade. The zlib compression algorithm is also prohibited in clog transmission and TableAPI transmission.
A column comment cannot exceed 1024 characters in MySQL mode. In earlier versions, a column comment cannot exceed 2048 bytes in MySQL mode. In MySQL Database, a column comment cannot exceed 1024 characters. In OceanBase Database V4.2.2_CE, the length limit for column comments is adjusted to match that of MySQL Database.
The ob_query_timeout parameter is supported in stored procedures. Prior to OceanBase Database V4.2.1_CE_BP3, after you run the set ob_query_timeout=xxx command in a stored procedure to set a query timeout value, the specified timeout value does not take effect for subsequent SQL statements in the stored procedure. In OceanBase Database V4.2.2_CE, you can set a timeout value in stored procedures to accommodate some business scenarios. After you set a timeout value in a stored procedure, the timeout value recorded in the session will change accordingly. The specified timeout value takes effect not only for subsequent SQL statements executed in the stored procedure, but also for external SQL statements executed after the stored procedure is executed. If you want the new timeout value to take effect only for SQL statements executed in the stored procedure, you must change the timeout value to the original value before the execution of the stored procedure ends.
An online DDL operation is supported for changing the integer type to another integer type with a larger value range. For a primary key column, partitioning key column, index column, generated column, column on which a generated column depends, or column with a UNIQUE or CHECK constraint, you can perform an online DDL operation to change the integer type to another integer type with a larger value range.
Both an execution plan and a throttling strategy can be bound to an outline. In OceanBase Database V4.2.2_CE, you can specify both an execution plan and a throttling strategy when you create an outline. The process involving ALTER OUTLINE is deprecated.

View changes

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

View Change type Description
DBA_OB_TRANSFER_PARTITION_TASKS New Displays all ongoing partition transfer tasks in the current tenant.
CDB_OB_TRANSFER_PARTITION_TASKS New Displays the ongoing partition transfer tasks of all tenants. You can query this view only in the sys tenant.
DBA_OB_TRANSFER_PARTITION_TASK_HISTORY New Displays all historical partition transfer tasks executed in the current tenant.
CDB_OB_TRANSFER_PARTITION_TASK_HISTORY New Displays the historical partition transfer tasks executed in all tenants. You can query this view only in the sys tenant.
[GV$OB_PL_CACHE_OBJECT] New Displays information about cached objects in the PL cache.
[GV$OB_SQL_AUDIT] Modified
  • Adds the PL_TRACE_ID column to record outer PL trace IDs for association with SQL statements in PL.
  • Adds the PLSQL_EXEC_TIME column to record PL execution time (excluding the SQL execution time), in μs.
[GV$SQLSTAT] New Displays basic performance statistics of SQL statements.
DBA_WR_SQLSTAT New Displays the performance statistics of top SQL statements in the current tenant.
CDB_WR_SQLSTAT New Displays the performance statistics of top SQL statements in all tenants.
DBA_WR_SQLSTAT New Displays the SQL texts collected by WR in the current tenant.
CDB_WR_SQLSTAT New Displays the SQL texts collected by WR in the sys tenant.
[GV$OB_CGROUP_CONFIG] New Displays the cgroup configurations of OBServer nodes. Each row indicates level-1 cgroup configurations. All information is sourced from the cgroup directories in the installation directory of the OBServer node.
[GV$OB_ACTIVE_SESSION_HISTORY] New Displays the Active Session History (ASH) statistics specific to OceanBase Database.
DBA_WR_ACTIVE_SESSION_HISTORY Modified Adds columns TOP_LEVEL_SQL_ID, PLSQL_ENTRY_OBJECT_ID, PLSQL_ENTRY_SUBPROGRAM_ID, PLSQL_OBJECT_ID, PLSQL_SUBPROGRAM_ID, IN_PLSQL_EXECUTION, IN_PLSQL_COMPILATION, PLSQL_ENTRY_SUBPROGRAM_NAME, and PLSQL_SUBPROGRAM_NAME to refine PLSQL statistics.
CDB_WR_ACTIVE_SESSION_HISTORY Modified Adds columns TOP_LEVEL_SQL_ID, PLSQL_ENTRY_OBJECT_ID, PLSQL_ENTRY_SUBPROGRAM_ID, PLSQL_OBJECT_ID, PLSQL_SUBPROGRAM_ID, IN_PLSQL_EXECUTION, IN_PLSQL_COMPILATION, PLSQL_ENTRY_SUBPROGRAM_NAME, and PLSQL_SUBPROGRAM_NAME to refine PLSQL statistics.
[GV$OB_SESS_TIME_MODEL] New Displays the statistical items of session-level time models.
[GV$OB_SYS_TIME_MODEL] New Displays the statistical items of tenant-level time models.
DBA_WR_SYS_TIME_MODEL New Displays the WR data of statistical items of tenant-level time models.
CDB_WR_SYS_TIME_MODEL New Displays the WR data of statistical items of tenant-level time models. You can query this view only in the sys tenant.
DBA_WR_SYSTEM_EVENT New Displays persisted information on tenant-level wait events in the current tenant.
CDB_WR_SYSTEM_EVENT New Displays persisted information on tenant-level wait events in all tenants.
DBA_WR_EVENT_NAME New Displays persisted names of tenant-level wait events in the current tenant.
CDB_WR_EVENT_NAME New Displays persisted names of tenant-level wait events in all tenants.
DBA_OB_SYS_VARIABLES New Displays values of system variables of the current tenant.
CDB_OB_SYS_VARIABLES Modified Adds the DEFAULT_VALUE and ISDEFAULT columns to record the default values of system variables.
[GV$OB_PL_CACHE_OBJECT] New Displays basic information about cached objects in the PL cache.

Parameter changes

Parameter Change type Description
tableapi_transport_compress_func Renamed The tableapi_transport_compress_func parameter is renamed as kv_transport_compress_func. The kv_transport_compress_func parameter is changed from a cluster-level parameter to a tenant-level parameter. This parameter specifies whether to compress RPC messages returned for query requests in OBKV.
kv_transport_compress_threshold New It is a new tenant-level parameter used in combination with kv_transport_compress_func to specify the minimum threshold for compressing a query result set in OBKV. The default value is 10 KB, which specifies to compress a result set greater than 10 KB.
ha_diagnose_history_recycle_interval New It is a new cluster-level parameter that specifies the interval for clearing historical transfer diagnostic statistics. The default value is 7 days.
strict_check_os_params New It is a new startup option that specifies whether to check operating system parameters in strict mode at startup. The default value is False. When operating system parameters do not meet the requirements, a warning is displayed without affecting the normal start of the OBServer node.
range_optimizer_max_mem_size Modified The value range is changed from [16 MB, 1 GB] to [0 MB, +∞). The default value is changed from 128 MB to 0 MB, which specifies not to limit the memory usage of the query range module.

System variable changes

System variables Change type Description
automatic_sp_privileges New It is a new global system variable that specifies whether to automatically grant the ALTER and EXECUTE privileges to the creator of a stored procedure. The default value is True.
ob_enable_pl_cache New It is a global/session-level system variable that specifies whether to enable the PL cache. The default value is True. If you change the value to False, the stored procedure is recompiled each time it is executed.
sql_mode Modified The default value is changed from STRICT_ALL_TABLES,NO_ZERO_IN_DATE to STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER.
lc_time_names New It is a new global/session-level system variable that specifies the language for displaying the date/month or abbreviated names. The default value is en_US.

Recommended versions of tools

The following table lists the recommended versions of tools for OceanBase Database V4.2.2_CE.

Tool Version Remarks
ODP V4.2.1 V4.2.3 will be fully compatible.
OceanBase Cloud Platform (OCP) V4.2.1_CE_BP1 -
OceanBase Deployer (OBD) V2.6.0 -
OceanBase Developer Center (ODC) V4.2.3 V4.2.4 will be fully compatible.
OceanBase CDC V4.2.2 -
OceanBase Migration Service (OMS) V4.2.1_CE Only OceanBase Database V4.2.2_CE can serve as the destination. Incremental data cannot be pulled from OceanBase Database V4.2.2_CE.
OceanBase Client (OBClient) V2.2.3 V2.2.5 will be fully compatible.
LibOBClient V2.2.3 V2.2.5 will be fully compatible.

Upgrade notes

  • Online upgrade to OceanBase Database V4.2.2_CE is supported from both OceanBase Database V4.2.1_CE_BP2 and earlier V4.x_CE versions via an effective upgrade path. Note that BP versions subsequent to V4.2.1_CE_BP3 are no longer supported for upgrade to V4.2.2_CE. In line with the parallel development of V4.2.1_CE and V4.2.x_CE, future BP versions of V4.2.1_CE will progressively offer support for upgrades to subsequent releases within the V4.2.x_CE series.
  • For a seamless upgrade process, we recommend that you first upgrade OceanBase Database, and then upgrade ODP.
  • Major compactions and DDL operations are automatically disabled during the upgrade and will return to normal after the upgrade.

版本信息

项目 描述
发布日期 2024-1-17
版本号 V4.2.2_CE
Commit 号 fac02c6
OBServer RPM 版本号 oceanbase-ce-4.2.2.0-100000192024011915

版本定位

作为 OceanBase 数据库 V4.2.1_CE 后继版本，V4.2.2_CE 版本已正式发布。内核层面进一步加强，重构估行系统和统计信息收集机制，持续完善 MySQL 兼容性，新增 Lateral Derived Tables、分页查询保序、DBLink 调用远端 UDF 等多项业务依赖特性；同时也补充完善了 GIS/XML/JSON 等多模类型实现；新增 SQLSTAT、TIME MODEL、手动 Transfer 分区等多项易用性功能改进；通过降低索引临时空间占用、支持 OBKV RPC 压缩等一系列特性，优化系统资源使用。优化小规格基础测试性能，提高系统稳定性。

关键特性说明

内核增强

  • 估行系统增强

    随着 OceanBase 数据库版本的不断演进，优化器代价估计的方式也越来越丰富。涉及到每个算子估行，目前已经支持了存储层估行、统计信息估行、动态采样、默认统计信息等算法。V4.2.2_CE 版本重构估行系统，根据不同场景，指定不同的估行策略优先顺序，并提供 HINT、系统变量等手工干预估行策略选择的方式。同时新版本对谓词选择率和 NDV 计算框架也做了进一步增强，以此提高优化器代价估计的准确性。

  • 统计信息增强

    在 V4.2.1_CE 版本基础上，V4.2.2_CE 版本完善了统计信息功能、改善了统计信息收集性能、提升了统计信息兼容性和易用性。主要包括重构离线统计信息收集流程、提升统计信息收集效率、优化统计信息收集策略。默认自动收集索引直方图，使用推导统计信息的收集方式，保证在线统计信息收集的事务一致性；兼容 MySQL ANALYZE TABLE 功能，提供更丰富的语法支持；新增取消统计信息收集的命令，丰富统计信息收集进度监控，增强运维易用性；提供统计信息并行删除能力等。

  • 大 IN 优化

    目前在 IN 谓词右支包含多常量的场景下（简称“大 IN”），硬解析阶段会有明显的 CPU 和内存消耗。V4.2.2_CE 版本针对大 IN 场景，实现新版 Query Range 抽取算法，同时默认 INLIST 超过 1000 时，触发 INLIST 到 VALUES TABLE 的改写，降低资源消耗，提升性能。

  • 执行引擎强化

    V4.2.2_CE 版本在 SQL 执行层进行了一系列优化，如 Recursive CTE 搜索优化、Window Function 接入自动内存管理、Adaptive Hash GBY 数据倾斜优化、Adaptive Hash GBY 自适应策略完善、Hash Based Distinct Aggregate 优化等，提升 SQL 执行性能和系统稳定性。

  • PL 重新编译逻辑优化

    存储过程编译为共享库后，可以提供给多个线程使用。但如果发生依赖对象变更，共享库可能失效需要重新编译。V4.2.2_CE 版本针对重新编译场景做了梳理细化，在临时表匹配、静态 SQL 依赖对象信息收集、表 DDL 变更等方面进行一系列逻辑优化，减少因 PL CACHE 缓存对象失效导致重新编译的场景。

  • PL 编译结果落盘

    当前 PL Function/Procedure 编译后会加入到 PL Cache 中，当内存压力过大时可能会被淘汰，重启后会丢失编译结果，并且在分布式场景下也需要重新编译。在这些情况下，PL 无法命中 PL Cache，进而触发 LLVM 编译，导致消耗部分 CPU 资源。V4.2.2_CE 版本开始，PL Function/Procedure 被加入系统表落盘保存，未触发 DDL 使 PL 缓存失效的情况下，无论重启还是分布式场景都可以只编译一次后复用缓存。

  • 函数索引 SESSION 变量固化

    创建函数索引时，会向主表添加一个隐藏的虚拟生成列，定义为函数索引的索引键，然后再将虚拟生成列的值存储到索引表中。一些内置系统函数的结果会受到 SESSION 变量的影响，不同 SESSION 变量的取值，即使函数入参相同，计算结果也是不同的。为提高生成列/函数索引的稳定性，新版本在创建函数索引和生成列时，会将依赖的 SESSION 变量固化至索引列和生成列的 column schema 中。后续计算索引列和生成列的取值时，使用固化值，不受当前 SESSION 下变量取值的影响。V4.2.2_CE 版本支持固化的系统变量为 timezone_info、nls_format、nls_collation、sql_mode 等。

  • OBCDC 黑白名单

    OBCDC 目前已具备租户级别的日志同步功能，V4.2.2_CE 版本开始，增加库、表级同步粒度。支持通过简单的正则表达式配置黑白名单，来满足用户只需要同步部分表的数据消费场景。

MySQL 兼容

  • Lateral Derived Tables

    Lateral Derived Tables 是一种特殊的 Derived Tables，可以引用同一 FROM 子句中前面表的列，这种用法下 SQL 更易读易写，往往也可以减少数据的重复扫描计算，提升 SQL 执行性能。

  • 分页查询保序

    受计划选择、并行执行等因素影响，大部分数据库在 limit offset 场景下输出结果是不稳定的，需要在每个 SQL 外层添加 order by 来保证稳定有序输出。原生 MySQL 数据库虽然未承诺保序，但很多查询仍会保持结果集有序输出，为了避免 MySQL 迁移业务分页场景的一一改造，OceanBase 数据库增加分页查询保序功能，但大数量下和不保序行为相比会存在一定的性能回退。明确有诉求的业务场景，可咨询相关技术支持人员评估性能影响并可接受后，通过配置项打开该功能。

  • INTEGER 列类型增长支持 Online 方式

    对于主键列/分区键/索引列/被生成列依赖的列/有 Check 约束的列，列类型如果为整型，当列类型修改为取值范围更大的整形列类型时（如 INT -> BIGINT），在 V4.2.1_CE 版本中是通过双表双写的 Offline DDL 实现，转换过程中会加表锁，阻塞读写。但从 V4.2.2_CE 版本开始，将 Offline DDL 改进为 Online DDL，整型列类型增长将不再影响业务写入。

  • 客户端本地导入

    OceanBase 数据库 V4.2.2_CE 之前版本，支持了通过 SQL 导入（普通或旁路） 服务端、NFS、OSS 文件，但客户端本地文件需要借助 OBLoader 等工具导入，无法通过 SQL 命令直接导入。为了方便数据开发人员进行本地导入测试，也为了解决云环境无法登录服务端导致数据导入不方便的问题，V4.2.2_CE 版本新增支持客户端本地导入（LOAD DATA LOCAL INFILE）功能，通过流式文件处理方式完成本地文件导入。

  • PS 协议支持存储过程出参

    在MySQL 模式下，使用 PS 协议执行 CALL PROCEDURE 语句时，新增支持存储过程带出参的场景。

  • 通信协议完善

    兼容 MySQL COM_SET_OPTION 通信协议命令，用于指定 CONNECTION 级别选项，如 MYSQL_OPTION_MULTI_STATEMENTS_ON、MYSQL_OPTION_MULTI_STATEMENTS_OFF。兼容 MySQL AuthSwitchRequest 协议，用于支持认证方式切换，解决部分客户端版本不匹配导致认证出错的问题。

  • Show Extended Tables/Columns/Index

    支持 MySQL 8.0 新增的 SHOW EXTENDED 语法，如 show extended tables、show extended columns、show extended index。

  • 支持 utf8mb4/utf16_unicode_ci 字符序

    社区版本新增支持 utf8mb4_unicode_ci 和 utf16_unicode_ci 字符序。

多模特性

  • MySQL GIS 增强

    OceanBase 数据库 V4.1.0_CE 版本支持了 MySQL GIS 数据类型及部分空间对象相关的表达式，V4.2.2_CE 版本在此基础上进一步补齐空间数据存储和计算分析的能力，新增支持 MySQL 兼容的 ST_Crosses/ST_Overlaps/ST_Difference/ST_Union/ST_SymDifference/ST_Length/ST_Centroid/ST_AsGeoJSON 等表达式。另外 PG 作为 GIS 行业使用最广的数据库，提供了部分区别于 MySQL 的常用表达式，OceanBase 数据库在新版本也进行了扩展补充，包括 _ST_Touches/_ST_Equals/_ST_MakeEnvelope/_ST_ClipByBox2D/_ST_GeometryType/_ST_IsCollection/_ST_NumInteriorRings/_ST_PointOnSurface/ST_AsMVTGeom/_ST_AsMVT 等，同时也支持了三维空间对象的存储能力。

  • MySQL XML

    新增兼容 ExtractValue、UpdateXML 表达式。

  • MySQL JSON

    新增兼容 JSON_SCHEMA_VALID、JSON_SCHEMA_VALIDATION_REPORT 和 JSON_ARRAY_APPEND 表达式。

  • MySQL JSON Partial Update

    在使用 JSON 文档存储业务数据的场景中，若需要对文档进行更新，目前只能全量读取后全量更新，文档较大时性能无法满足预期。V4.2.2_CE 版本新增支持 JSON Partial Update 功能，当用户通过特定表达式（JSON_SET/JSON_REPLACE/JSON_REMOVE 等）更新 JSON 文档的部分字段时，可以只更新要修改的部分，无需全量覆盖更新，提升了更新性能，该功能需要通过 log_row_value_options 配置项开启使用。

性能提升

  • 小规格专项性能优化

    针对 4C16G 小规格环境，V4.2.2_CE 版本在后台线程使用、Location Cache 访问、读写主路径、系统调用等方面进行了一系列优化。在 30 个压测表，单表 50 万行数据，单 Primary Zone 的 SYSBENCH 压测场景下，相对 V4.2.0_CE 版本提升约 10%-30%。

    场景 read write write only read only select insert update
    V4.2.0_CE 默认参数 1330 4714 2334 67776 20880 21507
    V4.2.2_CE 默认参数 1520 5652 2645 77910 25798 27433
    相对 V4.2.0_CE 提升比例 14% 20% 13% 15% 24% 28%

  • 单日志流并行同步

    OceanBase 数据库 V4.2.2_CE 版本之前的日志同步模型为不同日志流并行同步和处理，单日志流基于 Pipeline 方式同步。目前在同城消费本地盘日志的场景下是可以满足性能要求的，但在备库异地部署、读对象存储的场景下，性能相对会差一些。V4.2.2_CE 版本实现了基于文件数据块的单日志流并行同步模型，显著提升同步性能并优化内存使用。

资源优化

  • OBKV RPC 压缩

    OBKV 新增查询请求回包的 RPC 消息压缩功能。客户端和服务端间网络带宽资源不足的场景下，通过 RPC 消息压缩，显著降低网络传输的数据大小，减小网络带宽消耗。

  • 强化旁路导入资源控制

    OceanBase 数据库 V4.x 版本支持的旁路导入功能显著提高了数据导入速率，但在用户设定较高并行度且并发执行的旁路导入任务较多时，资源缺少严格控制，容易造成较多线程和内存占用，影响其他任务的正常执行。V4.2.2_CE 版本新增三个维度的旁路导入资源管理能力：

    • 新增任务级资源申请管理模块，根据导入任务的执行模式和分区数量，申请对应的线程和内存资源。

    • 新增租户级资源管理模块，管理租户用于旁路导入的线程和内存资源，以定时任务感知资源池变化，回收异常中断的导入任务申请的资源。

    • 新增 OBServer 级资源管理模块，记录节点级资源申请，并根据任务数动态伸缩旁路导入任务排序阶段的可用内存。

  • R 副本按 Region 级联

    OceanBase 数据库 V4.2.0_CE 版本开始支持 R 副本功能，服务于弱读、复制表等场景。一个 R 副本通过注册为 F 副本或其他 R 副本的下游来同步日志，当多个 R 副本和其上游被部署在不同的 Region 时，可能占用额外的跨 Region 网络带宽。V4.2.2_CE 版本新增 R 副本对 Region 的感知能力，在日志同步时会尽量选择相同 Region 的其他副本作为上游，尽量避免跨 Region 的网络传输，节省跨 Region 带宽。

  • 分区局部索引空间优化

    后建索引流程中，通过发送内部 SQL 加载索引表数据，如果某个节点数据量很大，在排序过程中，可能引起临时空间放大。V4.2.2_CE 版本支持了索引表补数据的渐进式执行，单机 1GB 数据量在同一批次执行，多机任务并行执行，这样在充分利用了分布式系统并行计算能力的同时，也能够解决在索引构建过程中出现的临时空间放大问题。

  • JSON/XML 汇聚函数内存优化

    新版本优化了 XMLAGG、JSON_OBJECTARRAY 等汇聚函数在执行过程中的内存消耗。

高可用增强

  • 主备租户角色切换验证

    OceanBase 数据库支持租户级主备角色切换，如在数据无损情况下可以将备租户 SWITCHOVER 成主租户，将主租户 SWITCHOVER 成备租户，或在数据损失情况下将备租户 FAILOVER 成主租户。主备租户角色切换操作有失败的可能，为了降低实际执行角色切换动作的风险，V4.2.2_CE 版本新增支持主备租户角色切换验证功能（SWITCHOVER/FAILOVER VERIFY），在切换命令后添加 VERIFY 关键字，可以提前验证对应操作是否可以成功执行，如对应操作不可执行，将给出报错信息，可参考官方提供的处理手段进行相应处理。

  • Tablet Location 主动广播/刷新

    OceanBase 数据库当前已具备 Location Cache 周期性刷新机制，确保日志流 Location 信息更新的实时性和最终一致性。但 Tablet Location 只具备被动刷新能力，在 Tablet 和日志流的映射关系发生变化时，有概率触发 SQL 重试和读写报错。V4.2.2_CE 版本新增 Tablet Location 主动广播能力，减少 Transfer 后映射关系变化导致的 SQL 重试和读写报错；并提供主动刷新能力兜底，避免不可恢复的读写报错问题。

安全强化

  • OBServer 启动检查 OS 配置

    不合理的 OS 配置可能引发系统问题，V4.2.2_CE 版本新增核心 OS 参数检查。提供宽松和严格检查两种模式：宽松模式下，OS 参数不符合要求时，日志报 WARNING ，不影响 OBServer 启动；严格模式下，OS 参数不符合要求时，报 ERROR 且 OBServer 无法启动。

  • MySQL PL 权限管理

    MySQL 模式下新增 PL 权限管理，包括 CREATE ROUTINE、EXECUTE、ALTER ROUTINE 等权限控制。并增加支持视图 mysql.procs_priv，用于展示存储过程或函数授权信息。升级集群默认不开启 PL 权限管理功能，新建集群会自动开启。

易用性提升

  • 性能诊断利器 —— SQLSTAT

    OceanBase 数据库历史版本已提供通过 SQL AUDIT 和 PLAN STAT 来定位数据库性能问题的方式，但对于执行中的 SQL 或执行过去比较长时间的 SQL，缺少易用的定位手段。V4.2.2_CE 版本新增支持 SQLSTAT 功能，用于实时记录 SQL 执行状态和执行期间统计项信息。结合 WR 功能，可以较容易地找到对性能影响最大的 TOP SQL，进一步实现诊断自动化。可通过 [G]V$SQLSTAT 视图查看当前所有 SQL 的基本性能统计数据，通过 CDB/DBA_WR_SQLSTAT 视图用于查看持久化后 TOP SQL 的性能统计信息。

  • 时间模型统计 —— TIME MODEL

    为了更加及时地反映数据库的负载情况，获取准确的 DB time，V4.2.2_CE 版本支持了 SESSION 、TENANT 级别的时间统计模型。新增 DB time、DB CPU、non idle wait time、idle wait time、background elapsed time、backgroud cpu time、background database time、background database non-idle wait time、background database idle wait time 等 9 个指标，以此进行问题诊断和性能调优。可通过 [G]V$SYSSTAT 和 [G]V$SESSTAT 查看统计项信息，同时 WR 模块会以默认 1 小时间隔采集并持久化到 DBA_WR_SYSSTAT 视图中。

  • 手动 Transfer 分区

    OceanBase 数据库现有的自动负载均衡机制可以自动调整分区分布，以达到在线扩缩容和分区均衡的目的。不过实际业务场景中，用户有定制数据分布的需求，希望将特定的分区进行聚合或打散。V4.2.2_CE 版本新增 Transfer 分区功能，用户可以选择将特定的分区迁移到特定的日志流上，并提供任务状态查看能力。

  • 主备租户事件展示

    OceanBase V4.2.2_CE 版本之前，主备租户 SWITCHOVER、FAILOVER 等事件记录在 RS 事件中，RS 事件会随时间清理，且租户级记录混在集群操作记录中不易查找。V4.2.2_CE 版本将主备租户操作记录拆分到每个租户下，通过 CDB/DBA_OB_TENANT_EVENT_HISTORY 视图透出。

  • PL&SQL 日志解耦

    当前通过 PL 执行的 SQL 语句复用了 PL 的 trace_id，导致同一个 trace_id 关联的日志量过大，通过过滤日志排查问题比较耗费时间。V4.2.2_CE 版本将 PL 和 SQL 的日志解耦，为 PL 内部的 SQL 语句赋予独立的 trace_id，并在 SQL AUDIT 增加外层 PL trace_id 记录，有效提高问题排查效率。

  • PL 执行时间统计

    业务场景中，可能会遇到 PL 执行性能不符合预期的情况，目前缺少易用的手段快速分析主要耗时在内部 SQL 还是 PL 结构本身。V4.2.2_CE 版本新增 PL 结构执行时间统计，可直接通过 [G]V$OB_SQL_AUDIT 视图的 PLSQL_EXEC_TIME 列来获取。

  • 执行计划和限流同时绑定

    目前 OUTLINE 支持执行计划绑定和限流绑定两种功能，但不支持同时指定。考虑部分客户场景既需要干预执行计划，又需要对高流量 SQL 限流的需求，V4.2.2_CE 版本开始允许用户在一条创建 OUTLINE 的语句中指定 max_concurrent() 和其他 HINT。因为执行计划不支持使用 sql_text 指定通配符 ？ 绑定，执行计划和限流同时绑定时也约束为同样行为。sql_id 绑定方式未发生变化。

  • 动态配置 LOB 存储模式

    当前 LOB 数据小于等于 4KB 时，会 INROW 存储（即行内存储），大于 4KB 时，会存入 LOB 辅助表。不超过行级存储规格限制的前提下，部分场景相比于存入辅助表，INROW 整存整取性能更好。因此该版本提供动态配置能力，用户可根据业务需求动态调整 INROW 大小。

性能报告

参考 V4.2.2_CE 的性能测试数据如下：

  • 测试环境规格：

    • OBServer（1:1:1）：

      CPU 平台架构 x86_64
      ECS 类型 ecs.g7.8xlarge
      计算资源 32 核
      内存资源 128GB
      磁盘资源 系统盘 300G，2 * 400G 云盘，性能级别为 PL1
      操作系统 CentOS 7.9 64 位

    • ODP（1）：

      CPU 平台架构 x86_64
      ECS 类型 ecs.c7.16xlarge
      计算资源 64 核
      内存资源 128GB
      操作系统 CentOS 7.9 64 位

  • 测试版本：

    版本 说明
    OBServer (V4.2.2)
    • OBServer：OceanBase_CE 4.2.2.0
    • REVISION: 1-87b81aa4bc5603ac81fd5e0c896b9ced01d78739
    • BUILD_TIME: Jan 3 2024 14:53:33
    ODP (V4.2.1)
    • OBProxy：OceanBase 4.2.1.0
    • REVISION: 1-local-6599462fc897a4a46734d64585906ea80975a656
    • BUILD_TIME: Oct 12 2023 21:03:30

  • 租户规格：

    • MAX_CPU = 26
    • MEMORY_SIZE = 100g

SYSBENCH OLTP 负载测试

  • 参数调优：

    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;

  • 测试规格：

     obd test sysbench rn --tenant=perf --script-name=xxx.lua --table-size=1000000 --threads=xx  --report-interval=1 --rand-type=uniform --time=30 --db-ps-mode=disable

  • 测试结果：

    • Point Select 性能

      Threads V4.2.2_CE zone1 QPS/95%rt（单位为 ms） V4.2.2_CE RANDOM QPS/95%rt（单位为 ms）
      32 144562.71/0.26 150002.69/0.24
      64 255157.22/0.30 279256.71/0.27
      128 380483.96/0.51 489197.56/0.30
      256 505118.71/0.90 791088.58/0.46
      512 589809.56/1.42 1041150.67/0.83
      1024 600025.98/3.30 1053486.24/2.18

    • Read Only 性能

      Threads zone1 QPS/95%rt（单位为 ms） RANDOM QPS/95%rt（单位为 ms）
      32 124411.49/4.49 131753.27/4.18
      64 209992.12/5.57 241825.11/4.65
      128 283414.89/8.74 414202.92/5.57
      256 317012.12/19.29 638432.40/7.30
      512 337949.54/39.65 798094.11/15.00
      1024 331738.82/77.19 798567.76/34.95

    • Write Only 性能

      Threads zone1 QPS/95%rt（单位为 ms） RANDOM QPS/95%rt（单位为 ms）
      32 62842.72/3.96 46505.45/6.09
      64 123026.83/4.65 88264.25/5.99
      128 172264.95/6.09 153548.94/6.43
      256 221739.40/9.73 227430.99/8.74
      512 242756.24/23.10 292273.10/14.46
      1024 252565.64/36.24 324863.22/35.59

    • Read Write 性能

      Threads zone1 QPS/95%rt（单位为 ms） RANDOM QPS/95%rt（单位为 ms）
      32 95173.19/7.98 83309.88/9.56
      64 164018.31/9.06 151101.81/10.27
      128 222046.91/22.69 268784.90/11.65
      256 272321.09/33.72 394488.45/15.00
      512 298693.98/53.85 523029.07/31.37
      1024 292904.80/108.68 598383.51/50.11

BMSQL TPCC 测试

  • 参数调优：

    #ODP
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;

  • 测试规格：

    obd test tpcc rn --tenant=perf --tmp-dir=/data/2/tpcc  --warehouses=1000 --load-workers=40 --terminals=800 --run-mins=5 -v -O 2

  • 测试结果：

    测试类型 zone1 RANDOM
    tpmC (NewOrders) 150354.01 303653.87
    tpmTOTAL 334152.04 674530.08
    Transaction Count 1671628 3395842

TPCH 测试

  • 参数调优：

    #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;
# parallel_servers_target = max_cpu * server_num * 8
SET GLOBAL parallel_servers_target = 624;

  • 测试规格：

    obd test tpch rn --user=root --test-server=server1 --tmp-dir=/data/2/ob   --tenant=perf --remote-tbl-dir=/home/admin -s 100

  • 测试结果：

    Query RANDOM（单位为 s）
    Q1 2.26
    Q2 0.50
    Q3 1.49
    Q4 0.61
    Q5 0.97
    Q6 0.15
    Q7 1.41
    Q8 0.94
    Q9 4.42
    Q10 1.10
    Q11 0.18
    Q12 1.18
    Q13 1.93
    Q14 0.30
    Q15 0.43
    Q16 0.61
    Q17 1.63
    Q18 0.93
    Q19 0.64
    Q20 1.43
    Q21 2.70
    Q22 1.20
    Total 27.01

TPC-DS 测试

  • 参数调优：

    #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;
# parallel_servers_target = max_cpu * server_num * 8
SET GLOBAL parallel_servers_target = 624;

  • 测试规格：

    100GB

  • 测试结果：

    Query RANDOM（单位为 s）
    Q1 0.36
    Q2 1.15
    Q3 0.16
    Q4 10.63
    Q5 1.50
    Q6 0.23
    Q7 0.30
    Q8 0.27
    Q9 1.96
    Q10 0.57
    Q11 6.69
    Q12 0.19
    Q13 0.58
    Q14 11.37
    Q15 0.57
    Q16 0.92
    Q17 0.49
    Q18 0.35
    Q19 0.21
    Q20 0.21
    Q21 0.20
    Q22 1.18
    Q23 14.96
    Q24 1.48
    Q25 0.58
    Q26 0.23
    Q27 0.43
    Q28 6.67
    Q29 0.66
    Q30 0.31
    Q31 0.69
    Q32 0.12
    Q33 0.77
    Q34 0.52
    Q35 0.99
    Q36 0.31
    Q37 0.46
    Q38 1.59
    Q39 0.85
    Q40 0.18
    Q41 0.05
    Q42 0.13
    Q43 0.61
    Q44 0.49
    Q45 0.40
    Q46 0.56
    Q47 1.14
    Q48 0.67
    Q49 0.97
    Q50 0.69
    Q51 2.94
    Q52 0.13
    Q53 0.25
    Q54 1.04
    Q55 0.12
    Q56 0.65
    Q57 0.80
    Q58 0.91
    Q59 3.03
    Q60 0.77
    Q61 0.39
    Q62 0.42
    Q63 0.26
    Q64 1.96
    Q65 2.56
    Q66 0.54
    Q67 9.47
    Q68 0.49
    Q69 0.51
    Q70 1.20
    Q71 0.60
    Q72 5.53
    Q73 0.37
    Q74 4.24
    Q75 2.47
    Q76 0.64
    Q77 0.82
    Q78 3.43
    Q79 0.73
    Q80 1.19
    Q81 0.24
    Q82 0.74
    Q83 0.65
    Q84 0.21
    Q85 0.59
    Q86 0.33
    Q87 1.67
    Q88 0.72
    Q89 0.32
    Q90 0.23
    Q91 0.15
    Q92 0.13
    Q93 0.75
    Q94 0.66
    Q95 6.40
    Q96 0.39
    Q97 0.97
    Q98 0.32
    Q99 0.74
    Total Time 142.27

兼容性变更

产品行为变更

新增如下变更：

功能 变更点说明
单条日志大小扩展为 3.5 MB 为解决单行数据量较大情况下，单条日志空间不足的问题，V4.2.2_CE 版本开始将单条日志大小扩展为 3.5 MB。需使用配套的 ob_admin 工具来查看 CLOG 内容。
存储不再使用 zlib 压缩算法 V4.2.0_CE 版本中，存储已经禁止新建表使用 zlib 压缩，存量旧表仍可以使用 zlib 压缩。V4.2.2_CE 版本开始存储层不再支持使用 zlib 压缩算法，用户升级前如果使用了 zlib 压缩算法，须将数据表的压缩算法改成其它压缩算法；Clog 传输、TableAPI 传输等也均禁止使用 zlib 压缩算法。
MySQL 模式下，列注释不超过 1024 字符 之前版本，MySQL 模式下限制列注释最大 2048 字节，原生 MySQL 限制 1024 字符。新版本修改为和 MySQL 兼容，版本升级后，历史注释不受影响。
存储过程内部支持设置 ob_query_timeout 参数 V4.2.1_CE_BP3 之前的版本，存储过程内部执行 set ob_query_timeout=xxx 对于存储过程内后续 SQL 执行不会生效。考虑部分业务需求，V4.2.2_CE 版本支持了存储过程内设置超时时间的行为：存储过程内设置超时时间后，会更改 SESSION 上记录的超时时间，因此不仅对于存储过程内后续执行的 SQL 有效，存储过程执行完，继续执行的外部 SQL 语句依旧会看到更新后的超时时间。如果只想存储过程内部的 SQL 可见，需要在存储过程执行结束前重新设置为原有的超时时间。
INT 列类型增长支持 Online 主键列/分区列/索引列/生成列/被生成列依赖的列/有唯一约束的列/有 Check 约束的列，INT 列类型增长变更为 Online。
OUTLINE 同时绑定执行计划和限流功能 V4.2.2_CE 版本新增支持 CREATE OUTLINE 同时指定计划绑定和限流，涉及 ALTER OUTLINE 的流程已废弃。

视图变更

新增如下变更：

视图 变更类型 变更说明
DBA_OB_TRANSFER_PARTITION_TASKS 新增 展示本租户下所有正在处理的 Transfer Partition 任务。
CDB_OB_TRANSFER_PARTITION_TASKS 新增 展示所有租户当前正在处理的 Transfer Partition 任务。仅适用于 SYS 租户。
DBA_OB_TRANSFER_PARTITION_TASK_HISTORY 新增 展示当前租户下所有执行 Transfer Partition 的任务历史。
CDB_OB_TRANSFER_PARTITION_TASK_HISTORY 新增 展示所有租户执行 Transfer Partition 的任务历史。仅适用于 SYS 租户。
[G]V$OB_PL_CACHE_OBJECT 新增 展示 PL 相关的缓存对象信息。
[G]V$OB_SQL_AUDIT 新增列
  • 新增 PL_TRACE_ID 列，用于记录外层 PL 的 trace_id，使其可以与 PL 内部 SQL 关联。
  • 新增 PLSQL_EXEC_TIME 列，用于记录 PL 执行耗时（不包括 SQL 执行时间），单位为 us。
[G]V$SQLSTAT 新增 展示 SQL 的基本性能统计数据。
DBA_WR_SQLSTAT 新增 用于查看本租户 TOP SQL 的性能统计信息。
CDB_WR_SQLSTAT 新增 用于查看所有租户 TOP SQL 的性能统计信息。
DBA_WR_SQLSTAT 新增 展示本租户下 WR 采集的 SQL 文本。
CDB_WR_SQLSTAT 新增 展示系统租户下 WR 采集的 SQL 文本。
[G]V$OB_CGROUP_CONFIG 新增 用于快捷查询 OBServer 的 cgroup 配置，每行表示一级 cgroup 配置，所有信息取自 OBServer 安装目录下的 cgroup 目录。
[G]V$OB_ACTIVE_SESSION_HISTORY 新增 用于查看 OceanBase 特有的 ASH 统计信息。
DBA_WR_ACTIVE_SESSION_HISTORY 新增列 新增 TOP_LEVEL_SQL_ID，PLSQL_ENTRY_OBJECT_ID，PLSQL_ENTRY_SUBPROGRAM_ID，PLSQL_OBJECT_ID，PLSQL_SUBPROGRAM_ID，IN_PLSQL_EXECUTION，IN_PLSQL_COMPILATION，PLSQL_ENTRY_SUBPROGRAM_NAME，PLSQL_SUBPROGRAM_NAME 列信息，完善 PLSQL 统计。
CDB_WR_ACTIVE_SESSION_HISTORY 新增列 新增 TOP_LEVEL_SQL_ID，PLSQL_ENTRY_OBJECT_ID，PLSQL_ENTRY_SUBPROGRAM_ID，PLSQL_OBJECT_ID，PLSQL_SUBPROGRAM_ID，IN_PLSQL_EXECUTION，IN_PLSQL_COMPILATION，PLSQL_ENTRY_SUBPROGRAM_NAME，PLSQL_SUBPROGRAM_NAME 列信息，完善 PLSQL 统计。
[G]V$OB_SESS_TIME_MODEL 新增 展示 SESSION 级别 TIME MODEL 统计项。
[G]V$OB_SYS_TIME_MODEL 新增 展示租户级别 TIME MODEL 统计项。
DBA_WR_SYS_TIME_MODEL 新增 展示租户级别 TIME MODEL 统计项的 WR 数据。
CDB_WR_SYS_TIME_MODEL 新增 展示租户级别 TIME MODEL 统计项的 WR 数据。仅适用于 SYS 租户。
DBA_WR_SYSTEM_EVENT 新增 展示本租户的持久化后的租户级等待事件信息。
CDB_WR_SYSTEM_EVENT 新增 展示所有租户的持久化后的租户级等待事件信息。
DBA_WR_EVENT_NAME 新增 展示本租户的持久化后的租户级等待事件名称。
CDB_WR_EVENT_NAME 新增 展示所有租户的持久化后的租户级等待事件名称。
DBA_OB_SYS_VARIABLES 新增 展示当前租户的系统变量配置。
CDB_OB_SYS_VARIABLES 新增列 新增 DEFAULT_VALUE、ISDEFAULT 列信息。记录系统变量的默认值。
[G]V$OB_PL_CACHE_OBJECT 新增 展示 PL 相关缓存对象的基础信息。

配置项变更

配置项 变更类型 变更说明
tableapi_transport_compress_func 更名 将 tableapi_transport_compress_func 更名为 kv_transport_compress_func；将 kv_transport_compress_func 配置项的级别由集群级调整为租户级。用于控制 OBKV 的查询请求 RPC 回包是否开启压缩算法进行压缩。
kv_transport_compress_threshold 新增 新增租户级配置项，配合 kv_transport_compress_func ，用于指定需要进行压缩的 OBKV 查询结果集的最小阈值。默认值为 10KB，表示结果集大于 10KB 时，才会进行压缩。
ha_diagnose_history_recycle_interval 新增 新增集群级配置项，用于控制 Transfer 诊断统计历史信息的清理时间间隔。默认为 7 天。
strict_check_os_params 新增 新增启动项，用于指定启动时对 OS 参数进行宽松模式还是严格模式检查。默认为 False，表示不符合 OS 参数要求时，报 warning，不影响 OBServer 正常启动。
range_optimizer_max_mem_size 变更 取值范围由 [16M，1G] 调整为 [0M，+∞)；默认值由 128 M 调整为 0M，即不限制 Query Range 模块内存使用。

系统变量变更

系统变量 变更类型 变更说明
automatic_sp_privileges 新增 新增 GLOBAL 级系统变量，用于控制是否为存储过程创建者自动授予 ALTER 和 EXECUTE 该存储过程的权限。默认为 True，表示自动赋予。
ob_enable_pl_cache 新增 新增 GLOBAL/SESSION 级系统变量，用于控制是否开启 PL Cache 。默认为 True ，表示开启。更改为 False 后，每次执行存储过程都会触发重新编译。
sql_mode 默认值变更 将默认值由 “STRICT_ALL_TABLES,NO_ZERO_IN_DATE” 变更为“STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER“。
lc_time_names 新增 新增 GLOBAL/SESSION 级系统变量，用于控制日期/月份或缩写的名称展示使用哪种语言。默认为 en_US。

周边配套

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

组件 版本 备注
ODP V4.2.1 V4.2.3 版本全面适配
OCP V4.2.1_CE_BP1 -
OBD V2.6.0 -
ODC V4.2.3 V4.2.4 版本全面适配
OBCDC V4.2.2 -
OMS V4.2.1_CE 仅支持 OBServer V4.2.2_CE 版本作为目标端；不支持拉取 OBServer V4.2.2_CE 版本增量数据
OBClient V2.2.3 V2.2.5 版本全面适配
LibOBClient V2.2.3 V2.2.5 版本全面适配

升级说明

  • 支持 OceanBase 数据库 V4.2.1_CE_BP2 及之前的 V4.x_CE 版本通过有效升级路径在线升级到 OceanBase 数据库 V4.2.2_CE 版本。V4.2.1_CE_BP3 及之后的 BP 版本不再支持升级到 V4.2.2_CE 版本。随着 V4.2.1_CE 和 V4.2.x_CE 版本的并行演进，V4.2.1_CE 的后续 BP 版本也会逐步支持升级到 V4.2.x_CE 后续版本。

  • ODP 和 OBServer 升级顺序：建议先升级 OBServer 版本再升级 ODP 版本。

  • 升级期间，系统会自动禁用合并和 DDL 操作，升级完成后恢复正常使用。

Assets 2