OceanBase Database Enterprise Edition V4.3.1

V4.3.1 Beta

Version information

• Release date: May 17, 2024
• Version: V4.3.1 Beta
• RPM version: oceanbase-4.3.1.0-100000212024051522
• Description: The Beta version resolved most of the issues and is becoming more and more stable. However, there may still be some minor issues or errors that need to be addressed in the final stable release, so we recommend that you use this version in a testing environment.

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 and Oracle continues to be enhanced, supporting lateral derived tables, MySQL locking functions, Oracle view annotations, and remote UDF calls, 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.

• Oracle JSON

  OceanBase Database V4.2.1 supports the JSON_OBJECT_T and JSON_ELEMENT_T data types in PL statements. On top of that, OceanBase Database V4.3.1 also supports the JSON_ARRAY_T data type.

• Oracle GIS

  To allow GIS-dependent businesses to conveniently access and analyze spatial data, OceanBase Database V4.3.1 adds support for the SDO_GEOMETRY data type, which can be used to describe the following spatial data types: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection. The new version also allows you to use member functions GET_DIMS(), GET_GTYPE(), and ST_ISVALID() to query the dimension, type, and validity status of SDO_GEOMETRY spatial objects. Moreover, it allows you to use the GET_WKB(), GET_WKT(), and GET_GEOJSON() functions to convert SDO_GEOMETRY objects into the Well-Known-Binary or Well-Known-Text type, or into a JSON data type.

• Oracle XML

  OceanBase Database V4.3.1 adds support for the XMLTABLE, INSERTCHILDXML, DELETEXML, and XMLSEQUENCE 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.

Compatibility with Oracle

• Comments on views

  OceanBase Database V4.3.0 supports adding comments only on entity tables. OceanBase Database V4.3.1 supports adding comments both on views and columns in views. You can use the COMMENT ON statement to add a comment, or use -- to add a comment in the view definition.

• Improvement on the global temporary table feature

  OceanBase Database of earlier versions support the Create, Select, Insert, Delete, and Update operations on global temporary tables in Oracle mode. In OceanBase Database V4.3.1, MERGE INTO and INSERT ALL statements are supported for global temporary tables.

• DBMS_LOCK improvement

  OceanBase Database of earlier versions support the ALLOCATE_UNIQUE, ALLOCATE_UNIQUE_AUTONOMOUS, and REQUEST(release_on_commit = TRUE) subprograms. On top of that, OceanBase Database V4.3.1 supports the RELEASE and REQUEST(release_on_commit = FALSE) subprograms for manually releasing locks and requesting session-level locks.

• Lateral inline views

  Apart from lateral derived tables in MySQL mode, OceanBase Database V4.3.1 also supports lateral inline views in Oracle mode. OceanBase Database provides the Lateral keyword for an inner join view to reference columns of a table that appears earlier in the same FROM clause. It also allows you to specify whether to rewrite a lateral inline view by using the DECORRELATE and NO_DECORRELATE hints.

• Data of complex types serialized into text

  OceanBase Database V4.3.1 supports the serialization of complex data types in text protocols, which is compatible with Oracle. If complex data types exist in the result set of an SQL query, OceanBase Database can serialize values of the complex data types into Oracle-compatible text.

• UDF calls by using DBLinks

  In earlier versions of OceanBase Database in Oracle mode, you can use a DBLink to connect to a native Oracle database to view remote tables or views and call remote stored procedures. In OceanBase Database V4.3.1, you can use PL and SQL statements to call remote user-defined functions (UDFs) in an Oracle database, and call functions in packages.

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.

• Clog compression for storage

  As more and more replacement requirements arise in AP and HBase scenarios, the throughput of the clog disk may reach the upper limit in high write concurrency scenarios. In this case, you need to scale out the resources. However, other resources may not reach a bottleneck. An overall resource scale-out will increase the business costs and cause resource wastes. OceanBase Database V4.3.1 allows you to compress the clogs for storage. Compressing logs committed by transactions improves the log disk throughput and increases the total amount of clogs that can be stored in the log disk. You can use the log_storage_compress_all parameter to specify whether to enable clog compression.

• 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.

• Replication role for the network-based Physical Standby Database solution

  OceanBase Database supports the network-based Physical Standby Database solution since V4.2.0. Before you use the network-based Physical Standby Database solution, you must create an account dedicated for replication in the primary database and grant the account the privileges to access views that allow the account to view related information of the primary database during synchronization. In OceanBase Database of earlier versions, you need to grant access privileges on seven views and the dependent views may change. Manual intervention is complex. OceanBase Database V4.3.1 in Oracle mode supports a replication role for the network-based Physical Standby Database solution. The process of creating a replication account, granting login privileges, and granting access privileges on dependent objects of the network-based Physical Standby Database solution, is streamlined to the following process: creating a replication account and granting a replication role. This significantly improves the ease-of-use in O&M.

• 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

Recommended versions of tools

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

Upgrade notes

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