Version information

Overview

OceanBase Database V4.3.1, building on the foundation of V4.3.0, introduces the new feature of full-text indexing to enhance document retrieval efficiency, and expands features such as real-time materialized views, materialized view rewriting, and primary key materialized views to meet analytical needs across various scenarios. This version introduces a new partition management mechanism, including partition swapping, external table partitions, and an extension of data types for partition keys in MySQL mode, enhancing the processing capability for large-scale data. The multi-model features (including JSON, XML, and GIS) are also upgraded, adding support for multi-valued indexes for JSON data and partial updates of JSON, promoting the migration and integration of heterogeneous data. Compatibility with MySQL continues to be enhanced, supporting lateral derived tables and MySQL locking functions, facilitating integration into the ecosystem. Incremental direct load capabilities are provided, improving the performance of multiple import scenarios, while also optimizing DML performance in scenarios with multiple local indexes, improving the efficiency of basic statistical information collection, and achieving significant performance improvements in row sampling and small-scale TP scenarios. The new version further optimizes resource usage, supporting clog caching, storage compression, SQL temporary result compression, system log compression, and other features. It complements the MySQL privilege system and supports operating system configuration checks to strengthen system security. As always, OceanBase Database focuses on user experience, adding resource specification estimation capabilities, enhancing backup transparency, providing IPv6 format support, and empowering database management and operations.

V4.3.1 is positioned as a Beta version, recommended for testing in real-time data warehouses or online transaction processing businesses. A General Availability (GA) version recommended for production use will be released in the second half of the year.

Key features

Kernel enhancement

• Full-text indexing in MySQL mode (Experimental)

  In relational databases, indexes are often used to accelerate queries based on exact value matches, but ordinary B-tree indexes are not suitable for scenarios involving large amounts of text data that require fuzzy searches. In such cases, the only option is to perform a full table scan for fuzzy queries on each row, which often fails to meet performance requirements when dealing with large text and high data volumes. Additionally, some complex query scenarios, such as approximate matching and relevance sorting, are also difficult to support through SQL rewriting.

  To address the issues mentioned above, OceanBase Database introduces the full-text indexing feature in V4.3.1. By preprocessing text content to establish keyword indexes, it significantly enhances full-text search efficiency. This feature is an experimental feature in V4.3.1. Future versions are expected to enhance its functionality and mature it into a feature that is ready for production use. The current release includes the following capabilities:

  • Supports full-text indexing in MySQL mode, compatible with basic MySQL syntaxes.
  • Allows the creation of full-text indexes on CHAR, VARCHAR, and TEXT columns during table creation.
  • Applicable to partitioned tables.
  • Supports the creation of multiple full-text indexes on a primary table.
  • Includes three built-in tokenizers: SPACE (space), NGRAM, and BENG (basic English).
  • Supports using a single match against for full-text searches on multiple columns.
  • Supports NATURAL LANGUAGE MODE.

• Materialized view enhancements

  OceanBase Database V4.3.0 introduced the materialized view feature, which enhances query performance by precomputing and storing the results of view queries, thus reducing the burden of real-time computations and simplifying complex query structures to meet the demands of analytical processing (AP) scenarios. With the release of V4.3.1, the capabilities have been further extended to include support for real-time materialized views. This provides the capacity to perform immediate calculations based on materialized views and materialized log (MLOG) data, addressing the needs of businesses with critical real-time analysis requirements. The latest update also introduces the ability to define primary key constraints on materialized views, helping users to fine-tune performance for specific queries such as single-row lookups, range queries, and joins where the primary key is a determining factor. In addition, enhanced support for incremental updates on materialized views in inner join scenarios ensures more efficient refresh rates in various situations.

  Additionally, in V4.3.0, when you use materialized views, you need to manually update your business scripts, replacing operations on original tables with queries addressing the corresponding materialized views. This process introduced a significant manual rewrite burden. The new version improves this by offering automated query rewriting capabilities for materialized views in select scenarios. When you set the system variable QUERY_REWRITE_ENABLED to True, you can create materialized views and specify ENABLE QUERY REWRITE to enable the query rewrite capabilities. This means that the system can rewrite queries on the original tables to queries targeting the materialized views, thereby reducing the need for business modifications.

• Partition exchange

  As time goes by, a large amount of historical data may accumulate in the table, some of which may not require frequent access but need to be retained to meet compliance or historical data analysis requirements. To improve query performance, businesses often need to differentiate between active and inactive data and archive the inactive data. Although transferring data to a new table using SQL can address this scenario, the performance is often suboptimal for large data volumes. Therefore, OceanBase Database V4.3.1 introduces the partition exchange feature, which, by modifying the definitions of partitions and tables in the data dictionary without the need for physical data replication, can almost instantly move data from Table A to a partition in Table B, greatly enhancing the performance of data migration. This release includes the following features:

  • Support for exchanging data between a partition of a partitioned table and a normal table.
  • Support for partitioned tables with the partition type being Range (Range Columns).
  • Support for subpartitioned tables with no requirements for the partition type, and the subpartition type being Range (Range Columns).
  • Support for the INCLUDING INDEXES action, which means that during partition exchange, corresponding local indexes will also be part of the exchange and will remain usable afterward.
  • Support for WITHOUT VALIDATION mode, which requires users to ensure the data conforms to the partition key range.

• External table partitioning

  OceanBase Database introduced support for external tables since V4.2.0, though initially, this feature was confined to non-partitioned tables. In situations where a large number of files exist but a query only needs to process a fraction of them, non-partitioned external tables were less efficient since they had to scan the entire file set without the ability to trim away irrelevant data, resulting in suboptimal performance. OceanBase Database V4.3.1 adds partitioning capabilities to external tables, supporting partitioning methods similar to list partitioning on regular tables. This update offers two partitioning approaches—automatic and manual. When the automatic option is selected, the system organizes files into groups according to the predefined partition keys. If manual partitioning is selected, users are required to designate specific subpaths for data files tied to each partition. By leveraging partition pruning, which tailors data retrieval to only the necessary partitions, external table queries become far more efficient, narrowing the scope of file scanning and considerably improving query performance.

• Expansion of range columns partition key types in the MySQL mode

  To accommodate partitioning requirements of various business, OceanBase Database V4.3.1 has expanded the compatibility of range columns partition key types to include double, float, decimal, timestamp, and other types as partition keys for range columns partitioning. The specific types supported are:

  • DECIMAL and DECIMAL[(M[,D])]
  • DEC, NUMERIC, and FIXED
  • FLOAT[(M,D)] and FLOAT(p)
  • DOUBLE and DOUBLE[(M,D)]
  • DOUBLE PRECISION and REAL
  • TIMESTAMP

• PL recompilation logic optimization

  After a stored procedure is compiled into a shared library, it can be used by multiple threads. However, if dependent objects change, the shared library might become invalid and require recompilation. In the V4.3.1 release, the scenarios for recompilation have been thoroughly reviewed and refined. A series of logical optimizations have been carried out concerning temporary table matching, collection of dependency information for static SQL, and changes in table DDL. These enhancements aim to reduce the scenarios where PL CACHE cached objects become invalid, thus decreasing the need for recompilation.

• PL compilation results persisted to disk

  After a PL function or procedure is compiled, it is added to the PL cache. However, when memory pressure is excessive, it may be evicted, resulting in the loss of the compilation results after a restart, and requiring recompilation in distributed scenarios. In these situations, the PL cannot hit the PL cache, leading to triggering LLVM compilation and thus consuming some CPU resources. Starting from V4.3.1, PL functions and procedures are stored in system tables on disk, allowing the reuse of the cache after a single compilation in scenarios where DDL does not invalidate the PL cache, regardless of restart or distributed scenarios.

Multi-model features

• Multi-valued index for JSON data in MySQL mode (Experimental)

  MySQL 8.0 supports the multi-valued index feature for JSON documents and other collection data types. You can create a multi-valued index on an array or collection to efficiently retrieve elements. In OceanBase Database V4.3.1, the MySQL mode supports the multi-valued index feature for JSON data. You can create an efficient secondary index on a JSON array of multiple elements. This enhances the capabilities to query complex JSON data structures while ensuring the data model flexibility and data query performance. This feature is in the experimental stage in OceanBase Database V4.3.1, and will be enhanced for use in production environments in later versions. Take note of the following considerations when you use the multi-valued index feature:

  • Supports pre-creation of multi-valued indexes and composite multi-valued indexes.
  • Supports unique and non-unique multi-valued indexes.
  • Supports creating multi-valued indexes on JSON array element types such as INT, UINT, DOUBLE, FLOAT, and CHAR.
  • Applicable to partitioned tables.
  • Supports the use of multi-value indexes in queries with the MEMBER_OF(), JSON_CONTAINS(), and JSON_OVERLAPS() functions.

• MySQL JSON

  OceanBase Database V4.3.1 adds support for the JSON_SCHEMA_VALID, JSON_SCHEMA_VALIDATION_REPORT, and JSON_ARRAY_APPEND expressions.

• MySQL JSON partial update

  Some users store business data in JSON documents. To update a JSON document in OceanBase Database of earlier versions, all data in the document must be read and updated as a whole, which results in unsatisfactory update performance if the document is large. OceanBase Database V4.3.1 supports the JSON partial update feature to address this issue. You can use specific expressions such as JSON_SET, JSON_REPLACE, and JSON_REMOVE to update part of the fields in a JSON document, improving the update performance. You can enable this feature by using the log_row_value_options parameter.

• MySQL GIS enhancements

  OceanBase Database V4.1 supports geographic information system (GIS) data types and some spatial object-related expressions of MySQL. OceanBase Database V4.3.1 supports the storage, computing, and analysis of spatial data, and adds support for MySQL expressions such as ST_Crosses, ST_Overlaps, ST_Difference, ST_Union, ST_SymDifference, ST_Length, ST_Centroid, and ST_AsGeoJSON. As the most applied database in the GIS industry, PostgreSQL provides some common expressions different from those of MySQL. OceanBase Database V4.3.1 supports these expressions, such as _ST_Touches, _ST_Equals, _ST_MakeEnvelope, _ST_ClipByBox2D, _ST_GeometryType, _ST_IsCollection, _ST_NumInteriorRings, _ST_PointOnSurface, ST_AsMVTGeom, and _ST_AsMVT, and the storage of three-dimensional spatial objects.

• MySQL XML

  OceanBase Database V4.3.1 adds support for the ExtractValue and UpdateXML expressions.

Compatibility with MySQL

• Lateral derived tables

  A lateral derived table is a special type of derived table that can reference columns of a table that appears earlier in the same FROM clause. This makes SQL statements easier to read and write and reduces repeated data scans and calculations, thereby improving the SQL execution performance. OceanBase Database V4.3.1 supports the usage methods of lateral derived tables in MySQL 8.0.

• Communication protocol improvements

  OceanBase Database V4.3.1 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 the authentication method, avoiding authentication errors caused by incompatible client versions.

• Show Extended Tables/Columns/Index

  OceanBase Database V4.3.1 supports new SHOW EXTENDED syntaxes of MySQL 8.0, such as SHOW EXTENDED TABLES, SHOW EXTENDED COLUMNS, and SHOW EXTENDED INDEX.

• MySQL locking functions

  OceanBase Database V4.3.1 supports the following MySQL locking functions: GET_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK(), RELEASE_ALL_LOCKS(), and RELEASE_LOCK(). You can use these functions in different parts of SQL statements, for example, in the ORDER BY and HAVING clauses of a SELECT statement, in the WHERE condition of a SELECT, DELETE, or UPDATE statement, or in a SET statement. The function expression can be a literal, column value, NULL, variable, built-in function or operator, loadable function, or stored function. Locking functions are a type of built-in functions that allow you to define and use locks.

• Support for output parameters in stored procedures

  When you execute the CALL PROCEDURE statement by using the PreparedStatement protocol in MySQL mode, output parameters are supported in stored procedures.

Performance improvements

• Incremental direct load (Experimental)

  OceanBase Database supports direct load since V4.1.0. This feature simplifies the data loading path and skips the SQL, transaction, MemTable, and other modules to directly persist data into SSTables, which significantly improves the data import efficiency. However, in a scenario where the table data needs to be imported multiple times, the existing data in the table needs to be written repeatedly during each import, compromising the incremental import performance. OceanBase Database V4.3.1 provides the incremental direct load feature to optimize incremental import. Specifically, the database writes only new data rather than repeatedly writing all existing data. This ensures high import performance. You can use the /*+ direct(need_sort, max_errors_allowed, load_mode)*/ hint in the LOAD DATA or INSERT INTO SELECT statement to specify whether to enable the incremental direct load feature. You can leave load_mode unspecified or set load_mode to full to enable full direct load. You can set load_mode to inc_replace to enable incremental direct load. This feature is in the experimental stage in OceanBase Database V4.3.1, and will be enhanced for use in production environments in later versions.

• Performance improvement for the SELECT INTO OUTFILE statement

  In earlier versions, the SELECT INTO OUTFILE statement supports reading data from tables in parallel but can write data into external files only in serial, leading to a performance bottleneck in data export. OceanBase Database V4.3.1 supports parallel export. It allows you to set the data export mode by specifying the SINGLE and MAX_FILE_SIZE options in the SELECT INTO OUTFILE statement. The SINGLE option specifies to export data to a single file or multiple files. If you set the degree of parallelism (DOP) to a value greater than 1 and SINGLE to FALSE, the data is exported to multiple files in parallel. The MAX_FILE_SIZE option limits the size of an external file.

• DML performance optimization in a scenario with multiple local indexes

  The performance of DML operations on an indexed database table will decrease due to synchronous index update, especially when a large number of indexes exist. The new version takes a series of measures to reduce the maintenance overhead of local indexes by 45%, thereby improving the overall DML execution performance. Some of the measures are as follows: unlock a table with local indexes, not to record the lock holder, skip the transaction conflict check on non-unique indexes, and reduce the overhead in reporting DML statistics.

• Parallel synchronization of a single log stream

  In the log synchronization model of OceanBase Database of earlier versions, multiple log streams are synchronized and processed in parallel, and a single log stream is synchronized in pipeline mode. This log synchronization model can meet the performance requirements in a scenario where logs in the local disk are consumed in the same city. However, in a scenario where the standby database is remotely deployed or logs are read from an object storage service provided by a public cloud vendor, the performance will decrease. OceanBase Database V4.3.1 implements a model that supports parallel synchronization of a single log stream based on file data blocks, significantly improving the synchronization performance and optimizing the memory usage.

• Statistics collection performance optimization

  In earlier versions, internal SQL statements of related aggregate functions are executed to collect basic statistics. OceanBase Database V4.3.0 supports pushing down aggregate functions to the storage layer. OceanBase Database V4.3.1 supports pushing down more aggregate functions to the storage layer and avoids projecting data to the SQL layer for computing. This way, all operations for collecting basic statistics are executed at the storage layer, improving the statistics collection efficiency. Compared with V4.3.0, V4.3.1 improves the overall collection performance by about 5%.

• Row sampling performance optimization

  When the overhead for full data processing is high, you can learn the overall data distribution by observing a small part of the data. For example, the optimizer samples data to analyze data distribution and assist execution plan generation. In earlier versions, OceanBase Database uses the WHERE condition to filter a row and determines whether to sample this row. This process is time-consuming because the full data is scanned row by row. OceanBase Database V4.3.1 optimizes the sampling process. Specifically, it filters data first and then applies conditions, reducing the data reading cost. For data stored in columnar storage, it reads only required column data. This remarkably improves the sampling performance.

• Performance optimization for environments with small specifications

  To improve the performance in environments with four or eight CPU cores, OceanBase Database V4.3.1 is optimized in terms of background thread scheduling, location cache access, read/write paths, and system calls. V4.3.1 improves the performance in online transaction processing (OLTP) test scenarios by 20% to 30% compared with V4.3.0.

Reliability improvements

• Write stop upon high data disk usage

  In earlier versions, when the data disk usage is high, user write requests will still be processed until an error is returned after the memory is full due to minor compaction failures or after the clog disk is full. In this case, you need to urgently scale out the clog disk space or tenant memory to resolve this issue. In the new version, the kernel provides the feature of write stop upon high data disk usage. When the data disk usage reaches the value specified by data_disk_write_limit_percentage, an error is returned for new user write requests. After you drop tables, transfer data, or scale out the disk space to reduce the data disk usage, user writes automatically resume.

Resource usage optimization

• Clog caching

  In earlier versions of the V4.x series, OceanBase Database supports LogHotCache to cache part of the real-time logs in scenarios such as log archiving and replay. This reduces the overhead in reading logs from the disk. However, when logs are written at a high speed or multiple OceanBase Change Data Capture (CDC) instances repeatedly pull closely-associated logs, the I/O throughput of the log disk is high, resulting in full usage of the log disk bandwidth in extreme conditions. The bandwidth of a cloud disk is limited. Therefore, the overhead in reading logs from the disk must be reduced to support more log consumption scenarios. This version provides the clog caching feature, which allows consumers to directly read logs from the log cache. If the log cache is not hit, consumers can read logs from the disk and write the logs to the cache to avoid repeated disk reads, thereby reducing the usage of the log disk bandwidth. Three statistical items, 50065, 50066, and 120010, are added to the SYSSTAT views to indicate the number of log cache hits, number of log cache misses, and clog cache size at the tenant level.

• Strengthened resource management for direct load

  In OceanBase Database V4.x, the direct load feature drastically increases the data import efficiency. However, when a high DOP is specified and many direct load tasks are executed in parallel, a number of threads and memory resources are occupied due to loose resource control, thereby affecting the normal execution of other tasks. OceanBase Database V4.3.1 enhances direct load resource management from three dimensions:

  • A task-level resource management module is provided. Thread and memory resources are requested based on the execution mode of the import task and the number of partitions.
  • A tenant-level resource management module is provided to manage the thread and memory resources of a tenant that are available for direct load. The module detects resource pool changes based on scheduled tasks and reclaims resources requested by import tasks that are interrupted unexpectedly.
  • An OBServer node-level resource management module is provided for node-level resource application. The module dynamically scales the memory available for direct load tasks in the sorting phase based on the number of tasks.

• System log compression

  When the business traffic is heavy, system logs are refreshed quickly. In this case, troubleshooting will be affected due to a short retention period of system logs. The new version provides the system log compression feature. For the observer.log, rootservice.log, election.log, and trace.log log files, when the number of log files of a specific type reaches the value specified by syslog_file_uncompressed_count, the earliest logs will be compressed by using the compression method specified by syslog_compress_func. When the total occupied disk space approaches the upper limit specified by syslog_disk_size, the earliest log files are deleted to release the occupied disk space. After you enable zstd compression, the volume of logs that can be stored in the same disk space is 20 times that of logs that can be stored when compression is disabled.

• Cascading of read-only replicas by region

  OceanBase Database supports read-only replicas for weak-consistency reads and replicated tables since V4.2.0. A read-only replica synchronizes logs by registering as a full-featured replica or as a downstream replica of another read-only replica. When multiple read-only replicas and their upstream replicas are deployed in different regions, cross-region network bandwidth resources may be excessively occupied. OceanBase Database V4.3.1 enhances the capability to detect the regions of read-only replicas. During log synchronization, the database will preferentially select another replica in the same region as its upstream replica to avoid network transmission across regions, thereby saving the cross-region bandwidth.

• Compression of temporary results of SQL queries

  When an SQL query involves a large amount of data, the memory may be insufficient. In this case, the temporary intermediate results of some operators must be materialized. The execution of the SQL query fails if the disk space is fully occupied by the materialized data. OceanBase Database V4.3.1 supports compressing temporary results of SQL queries. You can use the tenant-level parameter spill_compression_codec or an SQL-level hint such as /*+opt_param('spill_compression_codec', 'lz4') */, to specify whether to compress temporary results and the compression algorithm. This feature effectively reduces the disk space occupied temporarily, so as to support query tasks with higher computing workload.

Security enhancements

• PL privilege management in MySQL mode

  OceanBase Database provides the PL privilege management feature in MySQL mode for you to manage privileges such as CREATE ROUTINE, EXECUTE, and ALTER ROUTINE. The mysql.procs_priv internal table is provided to show authorization information about stored procedures and functions. By default, the PL privilege management feature is disabled for clusters upgraded from earlier versions to V4.3.1, and is enabled for new clusters created in V4.3.1.

• Role management

  OceanBase Database V4.3.1 supports the role management feature of MySQL 8.0. You can manage and maintain a group of privileges based on roles to conveniently grant privileges to and revoke privileges from a specific type of users. You can grant privileges or other roles to or revoke privileges or other roles from a role like normal users. You can grant multiple roles to a user. However, the user has only the privileges of roles in the active state.

• Column-level privileges

  OceanBase Database V4.3.1 provides the column-level privilege management feature in MySQL mode. You can specify whether a user has the SELECT, INSERT, or UPDATE privilege on specific columns in a table.

• Operating system configuration check at startup

  Inappropriate operating system configurations can cause system issues. OceanBase Database V4.3.1 supports checking core operating system parameters when an OBServer node starts. Loose and strict check modes are supported. In loose mode, when any parameter does not meet the requirement, a warning is logged and the OBServer node can still be started. In strict mode, when any parameter does not meet the requirement, an error is reported and the OBServer node cannot be started.

Usability improvements

• Resource specification estimation

  Resources in a database are classified into logical resources and physical resources. Logical resources are entities corresponding to logical concepts, such as data structures, threads, locks, and sessions. Physical resources are hardware resources, such as CPU cores, disk space, and memory space. The amounts of logical resources that can be created for a tenant may be subject to one or more physical resources. OceanBase Database V4.3.1 provides the resource specification estimation feature for you to conveniently learn about the usage of physical resources corresponding to the current logical resources of a cluster, thereby planning scaling, node replacement, standby tenant creation, and other operations in a more reliable manner. The following dynamic views and packages are provided:

  • The [G]V$OB_TENANT_RESOURCE_LIMIT view shows the following information about the logical resources in each unit of a tenant: current usage, upper limit, effective conditions, and maximum usage after a restart upon crash.
  • The [G]V$OB_TENANT_RESOURCE_LIMIT_DETAIL view shows the details of physical resources or parameters that limit the logical resources created on a server for a tenant.
  • The DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_UNIT subprogram calculates the minimum amounts of physical resources required on a node for a tenant.
  • The DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES subprogram calculates the amounts of physical resources required for specific types and quantities of logical resources.
  • The DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_STANDBY_TENANT subprogram calculates the minimum amounts of physical resources required to create a standby tenant with a specified number of units for a primary tenant.

• Display of the backup progress

  In earlier versions of OceanBase Database, backup tasks are executed in black-box mode. Generally, it takes a long time to execute a backup task that involves a large amount of data. However, you cannot learn about the backup progress or estimated completion time. The new version provides the backup progress statistic feature and supports displaying the data backup progress and supplemental log backup progress. You can query the DATA_PROGRESS column in the CDB_OB_BACKUP_TASKS or DBA_OB_BACKUP_TASKS view for the macro block-level data backup progress, and query the LOG_PROGRESS column for the supplemental log backup progress.

• Backup of snapshot table names

  When OceanBase Cloud Platform (OCP) and downstream vendors adapt to the table-level restore feature, tables that can be used for restore must be displayed to users. OceanBase Database V4.3.1 persists the names of corresponding snapshot tables in the backup set and provides the ob_admin tool for parsing the snapshot table names.

• Manual partition transfer

  The existing automatic load balancing mechanism of OceanBase Database can automatically adjust the distribution of partitions to implement online scaling and partition balancing. However, you may want to aggregate or scatter certain partitions in actual business scenarios. OceanBase Database V4.3.1 provides the manual partition transfer feature. You can transfer specific partitions to a specific log stream. You can also view the status of and cancel a partition transfer task.

• Binding of 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.3.1 allows you to specify MAX_CONCURRENT() and other hints in an outline creation statement. You cannot bind an execution plan by using the question mark (?) as a wildcard in sql_text. When you bind both an execution plan and a throttling rule to the same outline, the same restriction applies. The behavior of binding a specific SQL statement by using its SQL ID to an execution plan or other database objects (such as a throttling rule) remains the same.

• Allowlists and blocklists in OceanBase CDC

  OceanBase CDC supports tenant-level log synchronization in earlier versions of OceanBase Database, and also supports database-level synchronization and table-level synchronization in V4.3.1. In data consumption scenarios where you want to synchronize only part of the tables, you can configure an allowlist or a blocklist by using a simple regular expression.

• Decoupling of PL logs from SQL logs

  In earlier versions, an SQL statement executed by using PL inherits the trace ID of PL. As a result, one trace ID may be associated with a large number of logs, and it takes a long time to locate and resolve issues based on logs. OceanBase Database V4.3.1 decouples PL logs from SQL logs. It assigns independent trace IDs to SQL statements in PL procedures and adds records about external PL trace IDs to SQL AUDIT logs to improve the troubleshooting efficiency.

• PL execution time statistics

  The PL execution performance may fail to meet the expectations in business scenarios. In OceanBase Database of earlier versions, 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.3.1 supports PL structure execution time statistics. You can query the PLSQL_EXEC_TIME column in the [G]V$OB_SQL_AUDIT view for these statistics.

• Support of IPv6 for OBServer nodes

  The new version supports IPv6 addresses for OBServer nodes. SQL clients and RPC clients can connect to OBServer nodes through IPv6 addresses. It also supports hybrid deployment of OBServer nodes with an IPv4 address and those with an IPv6 address in the same cluster. You can upgrade an IPv4 cluster to the new version but cannot upgrade an IPv4 cluster to an IPv6 cluster of the new version.

Compatibility changes

Product behavioral changes

The following table describes the changes made in this version.

View changes

The following table describes the changes made in this version.

Parameter changes

The following table describes the changes made in this version.

System variable changes

The following table describes the changes made in this version.

Function/PL package changes

Syntax changes

• Syntaxes related to full-text indexes are provided.
• Syntaxes related to external table partitions are provided.
• Export options are added for the SELECT INTO OUTFILE statement.
• The table-level restore command is adjusted.
• The syntax for creating a materialized view with a primary key is provided.
• Syntaxes for creating real-time materialized views or rewriteable materialized views are provided.
• The syntax for exchanging partitions is provided.
• Syntaxes for manually transferring partitions and canceling a partition transfer task are provided.
• Syntaxes related to lateral derived tables are provided.
• Syntaxes related to JSON multi-valued indexes are provided.

Recommended versions of tools

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

Upgrade notes

• You can upgrade OceanBase Database V4.3.0_CE Beta to V4.3.1 Beta_CE.
• At present, you cannot upgrade OceanBase Database V4.2.x or earlier to V4.3.1_CE Beta. The upgrade paths from V4.2.x to V4.3.x will be supported later.

版本信息

版本概览

OceanBase V4.3.1 在 V4.3.0 基础上，新增全文索引特性提升文档检索效率，扩展实时物化视图、物化视图改写、主键物化视图等功能以满足多场景的分析需求。引入分区管理新机制，如分区交换、外表分区、MySQL 模式分区键数据类型扩展等，提升大规模数据的处理能力。多模特性（含 JSON、XML、GIS）功能升级，增加 JSON 多值索引、JSON 部分更新的能力支持，促进异构数据的迁移与融合。MySQL 兼容性持续增强，支持 Lateral Derived Tables、 MySQL 锁函数等，以便融入生态。提供增量旁路导入能力，提升了多次导入场景的入库性能，同时优化了多局部索引场景下的 DML 性能，提高了基础统计信息收集效率，并在行采样、小规格 TP 场景取得了显著的性能提升。新版本也进一步优化了资源使用，支持了 CLOG 日志缓存、SQL 临时结果压缩、系统日志压缩等特性。补充完善了 MySQL 权限体系、支持了操作系统配置检查，加固系统安全。一如既往地关注用户体验，增加资源规格估算能力，增强备份透明度，提供 IPV6 格式支持，赋能数据库管理与运维。

V4.3.1 定位为 Beta 版本，推荐实时数仓或联机交易业务测试使用，下半年将发布推荐用于生产的 GA 版本。

关键特性说明

内核增强

• MySQL 模式全文索引（Experimental）

  关系型数据库中通常会使用索引来加速基于精准值匹配的查询，但普通的 B-Tree 索引无法应用于涉及大量文本数据需要进行模糊检索的场景，这时只能通过全表扫描来对每一行数据进行模糊查询，文本较大、数据量较多的情况下性能往往不能满足要求。另外一些复杂的查询场景，如近似匹配、相关性排序等，也难以通过改写 SQL 支撑。

  为了解决上述问题，OceanBase 在 V4.3.1 支持了全文索引功能，通过预先处理文本内容，建立关键词索引，有效提升全文检索效率。该功能在 V4.3.1 定义为实验特性，后续版本会继续扩展功能并演进为生产可用特性。本期包含以下功能：

  • MySQL 模式下支持全文索引功能，兼容 MySQL 基本语法。
  • 建表时支持对 CHAR、VARCHAR 和 TEXT 列预建全文索引。
  • 适用于分区表。
  • 支持对主表创建多个全文索引。
  • 支持 SPACE（空格）、NGRAM 和 BENG（基础英文）三种内置分词器。
  • 支持一个 match against 对多个列进行全文检索。
  • 支持 NATURAL LANGUAGE MODE 模式。

• 物化视图增强

  OceanBase V4.3.0 支持了物化视图特性，通过预计算和存储视图的查询结果，减少实时计算来提升查询性能，简化复杂查询逻辑，支撑 AP 场景需求。在此基础上，V4.3.1 版本扩展支持了实时物化视图功能，提供基于物化视图和 MLOG 两部分数据的实时计算能力，适用于实时性要求较高的分析业务。新增物化视图主键约束，支持用户为物化视图指定主键，以此优化基于主键的单行查找、范围查询或关联场景性能。同时扩展支持了内连接场景物化视图的增量更新能力，提升部分场景的物化视图刷新性能。

  另外在 V4.3.0 版本使用物化视图时，需要将业务脚本中对原始表的访问计算手工替换为查询对应的物化视图，引入了人工改写成本。新版本支持了部分场景的物化视图改写能力，在系统变量 QUERY_REWRITE_ENABLED 设置为 True 的情况下，创建物化视图时可以通过指定 ENABLE QUERY REWRITE 来使用物化视图的自动改写能力，此时系统可以将对原始表的查询改写为针对物化视图的查询，以此减少业务改造量。

• 分区交换

  随着时间的推移，表中可能会累积大量的历史数据，这些数据可能不需要频繁访问，但需要保留以满足合规性或历史数据分析需求。为了提升查询性能，业务往往需要区分活跃和非活跃数据，并将非活跃数据进行归档。通过 SQL 迁移数据到新表可以解决这个场景需求，但大数据量情况下性能往往不优。因此，OceanBase V4.3.1 版本新增分区交换功能，通过修改数据字典中分区和表的定义，而无需进行数据的物理复制，可以将 A 表数据近乎瞬时地移动到 B 表某个分区下，极大地提升了数据迁移的性能。本期包含以下功能：

  • 支持分区表中的一个分区和一个普通表进行数据互换。
  • 支持一级分区表，分区类型为 Range（Range Columns）。
  • 支持二级分区表，一级分区类型无要求，二级分区类型为 Range（Range Columns）。
  • 支持 INCLUDING INDEXES 的行为，即分区交换时，对应局部索引也会参与交换，并在交换后保持可用状态。
  • 支持 WITHOUT VALIDATION 模式，需要用户保证数据符合分区键范围。

• 外部表分区

  OceanBase V4.2.0 开始支持外部表功能，局限于非分区表。当文件数量较多，但某次查询理论上只需要扫描一部分数据文件的场景，非分区外部表只能扫描全量文件，无法进行裁剪，性能较差。V4.3.1 版本新增外部表分区功能，支持类似普通表 list 分区的分区方式，并提供了自动/手动分区的两种语法。指定自动创建分区时，系统将按照分区键的定义方式，将文件按照分区进行分组；指定手动创建分区时，需要用户指定每个分区对应的数据文件子路径。这种情况下，外表查询可以根据分区条件实现分区裁剪，减少扫描的文件数量，显著提升查询性能。

• MySQL 模式 Range Columns 分区键类型扩展

  为了满足不同业务的分区要求，OceanBase V4.3.1 在兼容 MySQL Range Columns 分区键类型的基础上，扩展支持了 double、float、decimal、timestamp 等类型作为 Range Columns 分区的分区键。具体类型包括：

  • DECIMAL、DECIMAL[(M[,D])]
  • DEC、NUMERIC、FIXED
  • FLOAT[(M,D)]、FLOAT(p)
  • DOUBLE、DOUBLE[(M,D)]
  • DOUBLE PRECISION、REAL
  • TIMESTAMP

• PL 重新编译逻辑优化

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

• PL 编译结果落盘

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

多模特性

• MySQL 模式 JSON 多值索引（Experimental）

  MySQL 8.0 版本开始支持多值索引特性，适用于 JSON 文档和其他集合数据类型。这使得用户可以通过在数组或者集合上构建索引，来实现元素的高效检索。OceanBase V4.3.1 在 MySQL 模式下兼容了 JSON 多值索引特性，允许在包含多个元素的 JSON 数组字段上创建高效的二级索引，增强了复杂 JSON 数据结构的查询能力，兼顾了数据模型的灵活性和数据查询的高性能。该功能在 V4.3.1 定义为实验特性，后续版本会继续扩展功能并演进为生产可用特性。本期包含以下功能：

  • 支持多值索引、复合多值索引的预创建。
  • 支持唯一、非唯一的多值索引。
  • 支持创建多值索引的 JSON 数组元素类型为 INT、UINT、DOUBLE、FLOAT、CHAR 等。
  • 适用于分区表。
  • 支持 MEMBER_OF()、JSON_CONTAINS() 和 JSON_OVERLAPS() 函数使用多值索引查询。

• MySQL JSON

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

• MySQL JSON Partial Update

  一些用户会使用 JSON 文档存储业务数据，文档需要更新时，目前只能全量读取后全量更新，文档较大时性能无法满足预期。V4.3.1 版本新增支持 JSON Partial Update 功能，当用户通过特定表达式（json_set、json_replace 和 json_remove）更新 JSON 文档的部分字段时，可以只更新要修改的部分，无需全量覆盖更新，提升更新性能。该功能需要通过 log_row_value_options 配置项开启使用。

• MySQL GIS 增强

  OceanBase V4.1 版本支持了 MySQL GIS 数据类型及部分空间对象相关的表达式，V4.3.1 版本在此基础上进一步补齐空间数据存储和计算分析的能力，新增支持 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 兼容

• Lateral Derived Tables

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

• 通信协议完善

  兼容 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。

• MySQL 锁函数

  V4.3.1 兼容了 MySQL GET_LOCK、IS_FREE_LOCK、IS_USED_LOCK、RELEASE_ALL_LOCKS 和 RELEASE_LOCK 等锁相关的表达式。表达式可以用在 SQL 语句的多个地方，例如 SELECT 语句的 ORDER BY 和 HAVING 子语句，SELECT、DELETE 和 UPDATE 的 WHERE 条件中以及 SET 语句中。表达式的值可以是字面值、列值、NULL、变量、内部函数和操作符、可加载函数、存储函数。锁函数是一类内部函数，允许用户自定义锁，并进行使用。

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

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

性能提升

• 增量旁路导入（Experimental）

  OceanBase V4.1.0 开始支持旁路导入特性，通过精简数据加载的执行路径，跳过 SQL、事务、memtable 等模块，直接将数据持久化为 SSTable 来显著提升数据导入效率。但在表数据需要多次导入的场景，每次导入都需要将表中已有数据重写一遍，影响了增量导入的性能。V4.3.1 针对性地优化了增量导入场景，增量旁路导入无需重写原有数据，只需处理新增数据，让多次导入像第一次导入一样具有高性能。支持在 LOAD DATA 和 INSERT INTO SELECT 语句中通过 /*+ direct(need_sort, max_errors_allowed, load_mode) */ Hint 指定是否使用增量旁路导入功能。不指定 load_mode 或 load_mode 为 full 时，表示使用原有的全量旁路导入方式；指定 load_mode 为 inc_replace 时使用增量旁路导入方式。该功能在 V4.3.1 定义为实验特性，后续版本会继续扩展功能并演进为生产可用特性。

• SELECT INTO OUTFILE 性能优化

  现有的 SELECT INTO OUTFILE 功能虽然支持并行读取数据表，但只能串行写入外部文件，存在数据导出的性能瓶颈。V4.3.1 增加并行导出能力，在 SELECT INTO OUTFILE 命令基础上增加了 SINGLE、MAX_FILE_SIZE 选项，用于控制数据写入外部文件的方式。SINGLE 选项可控制将数据导出到单个文件或多个文件，指定并行度大于 1 且 SINGLE = FALSE 时，可以将数据导出到多个文件，达到并行读并行写的效果；MAX_FILE_SIZE 选项可控制导出文件的大小。

• 多局部索引场景下 DML 性能优化

  当数据库表上存在索引时，DML 会因为需要同步更新索引而产生性能下降。在索引数量特别多时，性能下降尤其明显。新版本针对表上存在多个局部索引的场景，通过局部索引去表锁、非唯一索引不记录持锁者、非唯一索引不检查事务冲突、降低 DML 统计信息上报开销等等一系列系统优化，将局部索引维护开销降低了 45%，从而提升 DML 整体执行性能。

• 单日志流并行同步

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

• 统计信息收集性能优化

  当前基础统计信息的收集依赖通过执行相关聚合函数的内部 SQL 完成，V4.3.0 开始支持了聚合函数下压到存储层，V4.3.1 进一步扩展了收集基础统计信息可以下压到存储层的聚合函数，避免投影数据到 SQL 层再做计算，基础统计信息的收集操作全部放到了存储层，提升了基础统计信息的收集效率。新版本收集性能整体上比 V4.3.0 提升 5% 左右。

• 行采样性能优化

  在处理全量数据开销太大时，往往可以通过小部分数据观察整体的数据分布，例如优化器通过采样来分析数据分布，辅助执行计划的生成。OceanBase sample 行采样当前会先应用 WHERE 过滤条件，然后过滤出的一行数据，判断是否进行采样。这相当于逐行扫描进行判断，把数据整体都探测一遍，十分耗时。V4.3.1 优化了行采样流程，先过滤数据再应用条件，省去部分数据的读取成本，同时针对列存也优化为只读取需要的列数据，显著提升采样性能。

• 小规格性能优化

  针对 4C/8C 小规格环境，V4.3.1 版本在后台线程使用、Location Cache 访问、读写主路径、系统调用等方面进行了一系列优化，OLTP 相关测试场景，性能相对 V4.3.0 提升 20%-30%。

可靠性提升

• 数据盘满停写

  数据盘使用量过高时，当前不会停写用户请求，一直到内存因为无法转储写满，或者 clog 盘写满后才会报错。这种情况下，需要通过紧急扩 clog 盘或租户内存恢复。新版本在内核层面增加数据盘满停写功能，当用户数据盘水位线达到 data_disk_write_limit_percentage 配置后，用户写入请求会报错。通过删表、transfer 或者扩磁盘方式降低数据盘使用比例后，用户写入操作可以自动恢复。

资源使用优化

• CLOG 日志缓存

  V4.x 在归档、回放等场景已经支持了 LogHotCache，用来缓存部分实时日志，一定程度上避免了日志读盘开销。但当日志写入速度比较快或多个 OBCDC 重复拉取相近日志时，还是无法避免大量的日志读盘，极端情况下会将日志盘带宽打满。同时，云上磁盘带宽往往有限的，我们需要通过降低日志读盘的开销来支撑更多的日志消费场景。因此，该版本新增 CLOG 日志缓存功能，支持消费者直接从日志缓存读取日志进行消费，没有命中日志缓存时，依然支持从磁盘读取日志，并将日志同步写入缓存中，避免重复读取磁盘，降低日志盘带宽使用。为了方便用户监控日志缓存命中情况，SYSSTAT 新增 50065、50066 和 120010 三个统计项，用于展示租户级别的日志缓存命中次数、未命中次数和 CLOG 缓存大小。

• 旁路导入资源控制强化

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

  • 新增任务级资源申请管理模块，根据导入任务的执行模式和分区数量，申请对应的线程和内存资源。
  • 新增租户级资源管理模块，管理租户用于旁路导入的线程和内存资源，以定时任务感知资源池变化，回收异常中断的导入任务申请的资源。
  • 新增 OBServer 级资源管理模块，记录节点级资源申请，并根据任务数动态伸缩旁路导入任务排序阶段的可用内存。

• 系统日志压缩

  业务流量过大时，系统日志刷新的会比较快，保留时间较短可能影响问题排查。新版本增加系统日志压缩功能，支持对 observer.log、rootservice.log、election.log 和 trace.log 等日志文件，每类超过 syslog_file_uncompressed_count 个数时，采用 syslog_compress_func 设置的压缩方法，对最早日志进行压缩。当日志使用总空间接近 syslog_disk_size 设置的磁盘空间上限时，开始删除最早生成的日志文件，回收空间。磁盘空间不变的情况下，开启 zstd 压缩后，预计可以存储不开启压缩时 20 倍的日志量。

• R 副本按 Region 级联

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

• SQL 临时结果压缩

  SQL 执行涉及的数据量过大的情况下，可能出现内存不足的问题，这时部分算子需要物化临时的中间结果。当物化的数据量过大，磁盘空间写满时，会导致 SQL 执行失败。V4.3.1 新增 SQL 临时结果压缩功能，允许通过租户级配置项 spill_compression_codec 或 SQL 级 Hint（如 /*+opt_param('spill_compression_codec', 'lz4') */）指定临时结果是否压缩及压缩算法，当指定临时结果压缩时可有效降低临时磁盘空间占用，以支撑更大运算量的查询任务。

安全强化

• MySQL PL 权限管理

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

• MySQL 角色

  OceanBase V4.3.1 兼容了 MySQL 8.0 的角色管理功能，通过角色来管理维护一组权限，可以更方便地对某一类用户进行授权和回收。与普通用户类似，角色可以被授予或回收权限，也可以被授予或回收其他角色。用户可以被授予多个角色，但仅能使用激活状态角色中的权限。

• MySQL 列级权限

  V4.3.1 版本新增 MySQL 列级权限功能，可以用于控制用户是否有权限对某张表的某几列进行 SELECT、INSERT 或 UPDATE。

• OBServer 启动检查 OS 配置

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

易用性提升

• 资源规格估算：

  我们将数据库中的资源分为逻辑资源和物理资源两大类。逻辑资源指的是逻辑概念对应的实体，如数据结构、线程、锁、会话等；物理资源指的是硬件资源，如：CPU、磁盘、内存等。租户能够创建的逻辑资源量可能受一个或者多个物理资源限制。为了用户可以更方便地获取集群当前的逻辑资源对应的物理资源使用信息，以此更可靠地规划扩缩容、节点替换、备租户创建等操作，V4.3.1 新增资源规格估算功能，提供以下一系列动态视图、系统包：

  • 新增 [G]V$OB_TENANT_RESOURCE_LIMIT 视图，用于展示租户在每个 Unit 上的逻辑资源使用量、上限值、生效限制条件和宕机重启后的最大占用量。
  • 新增 [G]V$OB_TENANT_RESOURCE_LIMIT_DETAIL 视图，用于展示租户在一个机器上能创建的逻辑资源所受的物理资源或配置项的限制情况。
  • 新增 DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_UNIT 子程序，用于计算某个租户在某个节点上所需的最小物理资源量。
  • 新增 DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES 子程序，用于计算特定逻辑资源类型和数量需要的物理资源量。
  • 新增 DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_STANDBY_TENANT 子程序，用于计算指定主租户创建指定 Unit 个数的备租户需要的最小物理资源量。

• 备份进度展示

  OceanBase 早期版本备份任务黑盒进行，大数据量的备份任务往往需要执行较长时间，用户无法了解备份进度，无法感知预计完成时间。新版本增加备份进度统计功能，支持数据备份进度和补偿日志备份进度展示。用户可通过查询 CDB/DBA_OB_BACKUP_TASKS 视图的 DATA_PROGRESS 字段获取宏块级别的数据备份进度，查询 LOG_PROGRESS 字段获取补偿日志备份进度。

• 备份快照表名

  OCP 及下游厂商适配表级恢复功能时，需要向用户展示可供恢复的表。新版本在备份集中持久化了对应的快照表名，并提供通过 ob_admin 来解析快照表名的能力。

• 手动 Transfer 分区

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

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

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

• OBCDC 黑白名单

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

• PL & SQL 日志解耦

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

• PL 执行时间统计

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

• OBServer 支持 IPV6

  新版本支持 IPV6 格式的 server ip，支持 sql 客户端、rpc 客户端以 IPV6 地址连接，同时也支持了 IPV4 和 IPV6 节点的混合部署。支持 IPV4 集群升级，但不支持旧的 IPV4 类型的集群升级到 IPV6 类型。

兼容性变更

产品行为变更

新增如下变更：

视图变更

新增如下变更：

配置项变更

新增如下变更：

系统变量变更

新增如下变更：

函数/PL包变更

语法变更

• 新增全文索引相关语法。
• 新增外部表分区语法。
• SELECT INTO OUTFILE 新增导出选项。
• 表级恢复命令调整。
• 新增有主键物化视图创建语法。
• 新增实时物化视图/可改写物化视图语法。
• 新增分区交换语法。
• 新增手动 Transfer 分区和任务取消语法。
• 新增 Lateral Derived Tables 相关语法。
• 新增 JSON 多值索引相关语法。

周边配套

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

升级说明

• 支持 V4.3.0_CE Beta 升级到 V4.3.1_CE Beta。
• 暂不支持 V4.2.x 系列或更低版本升级到 V4.3.1_CE Beta，随着版本演进，后续会增加 V4.2.x 到 V4.3.x 的升级路径支持。