OceanBase Database Enterprise Edition V4.4.2

V4.4.2

Version information

• Release date: February 10, 2026
• Version: V4.4.2
• RPM version: oceanbase-4.4.2.0-100000252026020915

Version overview

OceanBase Database V4.4.2 is a long-term support (LTS) release designed for hybrid workloads, combining the transactional processing strengths of V4.2.5 LTS with the analytical capabilities of V4.3.5 LTS. This version delivers comprehensive kernel improvements in data management, compatibility, security, and operational diagnostics, offering robust and stable support for both mission-critical transactional and complex analytical workloads.

For transactional processing (TP) scenarios, V4.4.2 introduces partition exchange between subpartitioned and regular partitioned tables, greatly simplifying large-scale data partition management and reorganization. It restructures global temporary tables in Oracle-compatible mode for substantial performance gains, and adds session-level private temporary tables in MySQL-compatible mode, completing the temporary table system. OBCDC now supports incremental data synchronization after table-level restores and can synchronize virtual generated columns, better serving downstream systems that rely on table-level incremental data and generated columns.

For analytical processing (AP) scenarios, V4.4.2 offers significant enhancements to materialized views, including support for DDL operations, optimized incremental refresh, cascading refresh for nested views, and support for materialized views based on tables without primary keys. These improvements greatly enhance query performance and data analysis flexibility. The version also enables data import from V1.4.7, 2.x, and 3.x logical and physical backups into V4.x clusters, expanding cross-version data migration capabilities. Additionally, it supports automatic partition creation with INTERVAL partitions and MySQL Union Distinct RCTE, further strengthening Oracle and MySQL syntax compatibility. Spatial geometry functions in Oracle-compatible mode have also been extended to better support GIS and spatial analysis applications.

For key-value (KV) scenarios, V4.4.2 continues to improve OBKV with new features such as weak reads, TTL support for index scans, and hot key query optimizations. OBKV-HBase metrics governance is now complete, delivering lower latency and enhanced observability for high-concurrency KV and time-series workloads.

In terms of performance, V4.4.2 brings targeted optimizations: serial table creation is about 60% faster; UDF and trigger execution paths in PL are optimized with support for asynchronous transaction submission, improving business logic processing efficiency. On large-scale domestic CPU platforms, PDML performance is up by roughly 25%, and follower query performance for replicated tables has improved 14-fold, nearly matching leader query speeds and significantly boosting horizontal scalability. Adaptive task splitting for PX has been introduced, automatically identifying and splitting long-tail tasks for better load balancing in parallel queries and faster completion times.

For security and diagnostics, this release supports transparent column encryption and TDE encryption for clogs, creating a comprehensive security layer from data to logs. Deadlock detection mechanisms have been enhanced, Active Session History (ASH) data integrity improved, and SQLSTAT statistics restructured, giving database administrators more precise and reliable diagnostic tools for pinpointing performance bottlenecks and problematic SQL statements.

V4.4.2 is an LTS release recommended for transactional, analytical, and hybrid transactional/analytical (HTAP) workloads.

Key features

Kernel enhancements

• Partition exchange between partitioned and subpartitioned tables

  The partition exchange feature now supports exchanging partitions between partitioned and subpartitioned tables.

• OBCDC incremental data synchronization after table-level restore

  OBCDC now supports allowlist and blocklist functionality. During data synchronization, only tables on the allowlist that are not on the blocklist are synchronized. Previously, the table-level restore process (an offline DDL operation) prevented OBCDC from obtaining table names, making incremental data synchronization impossible for restored tables. In this version, when table-level restore completes on an OBServer node, the restored table name is recorded in the __all_ddl_operation table. This enables OBCDC to identify restored tables and match them against the allowlist/blocklist, supporting incremental data synchronization.

• Enhancements to materialized views

  V4.4.2 continues to enhance the capabilities of materialized views, including:

  • Enhanced DDL capabilities, supporting RENAME and adding columns to materialized view logs.
  • Enhanced incremental refresh capabilities, supporting outer joins, UNION ALL, single-table non-aggregate mode, and aggregate materialized views with LEFT JOIN. It also supports repeated SELECT ITEM and GROUP BY columns, and enhanced MIN/MAX aggregate materialized view incremental refresh capabilities.
  • Enhanced nested materialized view capabilities, supporting cascading refreshes.
  • During materialized view refreshes, dimension tables are not refreshed. When creating a materialized view, you can use the new AS OF PROCTIME() syntax to specify tables that do not need to be refreshed. During incremental refreshes, the incremental data of these tables will not be refreshed.
  • Single-table aggregate incremental refresh materialized views now support the MIN()/MAX() aggregate functions.
  • Automated management of materialized view log tables. When creating an incremental refresh materialized view, the system automatically creates or replaces the required materialized view log tables for the base table and periodically cleans up redundant materialized view log tables in the background.
  • Support for the md5_concat_ws function.
  • Optimized view content and error information for materialized view creation.
  • Support for incremental materialized views without a primary key.
  • Support for referencing views declared with AS OF PROCTIME().
  • Support for user-defined types (UDTs) and user-defined functions (UDFs), including the minimal mode.

• Enhancements to SQL capabilities

  V4.4.2 enhances several SQL capabilities, including the ability to specify WITH CHECK OPTION when the view filter condition contains a subquery.

• Enhanced binary protocol with parameterized prepare

  When the binary protocol is enabled, OBServer previously couldn't receive actual parameter information from the driver during the PREPARE phase. This caused incorrect overloaded function matching based on parameter types, resulting in result set retrieval exceptions. The new version resolves this by moving parameter parsing before the PREPARE operation, allowing the protocol to correctly match overloaded functions using driver-provided parameter information and ensuring successful result set retrieval.

• Session-level private temporary tables

  The temporary table feature was disabled in MySQL-compatible mode starting from V4.1.0 BP4. This version re-enables temporary table functionality in MySQL-compatible mode, supporting table creation, modification, deletion, and indexing operations.

• MySQL-compatible mode syntax extensions

  MySQL-compatible mode now supports additional syntax including CAST AS INTEGER, CAST AS ARRAY, SPLIT, CONTAINS, and NEXTVAL(SEQ)/CURRVAL(SEQ). The version also supports ARRAY<> format array definitions, JSON column conversion to TEXT/MEDIUMTEXT/LONGTEXT, and the INTO keyword with INSERT OVERWRITE. Additional improvements include allowing SQL statements to end with -- without errors and changing RANGE and MAXVALUE from reserved to non-reserved keywords.

• Standby database read optimization and stability enhancements

  V4.4.2 optimizes standby database read operations by improving transaction state inference. Instead of each replica independently collecting participant states, the leader coordinator now centrally collects and caches these states, significantly reducing message exchanges. A new retry mechanism automatically forwards requests to other replicas when one falls behind, preventing blocking and incorrect transaction state inference, thereby improving standby read stability.

• Heterogeneous zone support

  OceanBase Database 4.0 introduced homogeneous zone architecture, which simplified cluster deployment but removed some 3.x features. A key limitation was that single node failures required scaling down all zones, causing resource waste. This version introduces heterogeneous zone support to enhance scalability and reduce resource waste.

  With heterogeneous zone deployment, tenants can configure different UNIT counts for each zone. When a single node fails, it can be removed directly without affecting other zones, reducing operational overhead. Single node failures also don't impact load balancing in other zones, minimizing business traffic disruption and enabling smoother scaling operations.

• OBCDC virtual generated column synchronization

  Starting from OceanBase Database 4.0, virtual generated columns are no longer recorded in clogs, preventing OBCDC synchronization. This caused data loss for downstream systems that depend on virtual generated columns. This version of OBCDC now supports virtual generated column synchronization, meeting downstream system data requirements.

MySQL compatibility

• MySQL Union Distinct RCTE

  MySQL 8.0 supports Recursive Union All and Recursive Union Distinct with CTEs. OceanBase Database has supported Recursive Union in MySQL-compatible mode since V3.2.3, but only for Recursive Union All. The new version extends compatibility to support Recursive Union Distinct, ensuring the uniqueness of output data. Additionally, it enhances the Recursive Union All feature to support data persistence when memory is insufficient.

Oracle compatibility

• INTERVAL partitioning

  The new version implements INTERVAL partitioning in Oracle-compatible mode. When new data exceeds the range of existing partitions, new partitions are automatically created, reducing the complexity of partition management.

• Enhancements to DBMS_SCHEDULER

  V4.4.2 enhances DBMS_SCHEDULER by supporting the repeat_interval time expression, which includes fields such as BYMONTH, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, and BYSECOND to specify job execution times. It also supports Chinese job names.

OBKV/Multimodel enhancements

V4.4.2 enhances the capabilities of the OBKV/multimodel scenarios, mainly in the following aspects:

• OBKV supports weak reads and reads from nearby IDCs

  • Weak reads allow applications to read data from non-primary replicas (follower). These replicas may not have the latest data, so the read data may be slightly older than the primary replica.
  • Reads from nearby IDCs allow clients to prioritize reading data from the nearest IDC based on their current geographical location or network topology, reducing network latency and improving response speed.

• Time To Live (TTL) index scan support

  Users can now specify indexes to accelerate TTL data cleanup. By default, TTL tasks perform full table scans and read complete rows to check expiration status. Creating local indexes on expiration columns reduces I/O overhead from full table scans and accelerates cleanup operations.

• Enhancements to OBKV-HBase monitoring

  The monitoring capabilities of OBKV-HBase are enhanced, mainly in the following aspects: * Distinguishing between HBase get and scan operations in QPS, RT, and P99 monitoring statistics, using independent monitoring items for tracking. * In batch scenarios, distinguishing between single put and single delete operations to provide more granular monitoring statistics. * In non-distributed environments, supporting audit tracking for HBase batch get operations. * In the OBKV-HBase client, returning corresponding OPS, RT, and P99 data for operations.

• Support for put operations in the time series model

  Because the V column in the time series model is of the JSON type, and since large object (LOB) types do not support the put operation, time series put operations are implemented using the insert interface. The insert interface checks for primary key conflicts during execution. Stress testing in shared storage mode revealed that these conflict checks consume a significant amount of read bandwidth. When cold data is moved to OSS, conflict checking requires a get operation on the sstable, resulting in high read latency. Furthermore, in random write scenarios—which represent most user use cases—the I/O bandwidth consumed by minor and major compaction operations is also considerable. Together, these factors quickly push cloud disk bandwidth to its limit, triggering write throttling. To resolve these issues, support for the put operation was introduced in version V4.4.2.

• Query optimization in OBKV-HBase

  OBKV-HBase queries use a full-range scan strategy, scanning all qualifiers' data first and then filtering. This approach generates a large amount of redundant scanning and processing overhead on the server side, especially when querying a wide row or a multi-version row that involves only a few qualifiers, making the latency problem particularly evident. In V4.4.2, a new parameter HBASE_HTABLE_HOTKEY_GET_OPTIMIZE_ENABLE is introduced to specify the ability to quickly skip wide rows or multi-version rows to reduce query latency.

• Extension of spatial functions in Oracle-compatible mode

  V4.4.2 adds several spatial geometry functions in Oracle-compatible mode, including SDO_CONTAINS, SDO_ANYINTERACT, SDO_AREA, and SDO_UTIL.GETVERTICES, covering common GIS operations such as spatial containment judgment, intersection judgment, area calculation, and geometric vertex extraction. These functions are applicable to scenarios such as spatial data analysis, geographic information calculation, map rendering, and geometric quality verification.

Performance improvements

• Serial table creation performance optimization

  While V4.2.x introduced parallel execution for DDL operations like CREATE and DROP, unsupported DDL operations cannot utilize parallel capabilities, necessitating serial DDL performance optimization. This feature targets serial table creation by optimizing schema generation, writing, and refreshing processes to significantly improve table creation speed and moderately enhance other DDL operation performance. Testing demonstrates that V4.4.2 performs 60% better than V4.3.5 when creating 1,000 simple sysbench tables.

• PL execution performance optimization

  V4.4.2 enhances PL execution performance by optimizing common execution paths for UDFs, triggers, and procedures. The version also improves UDF constant folding, extends FORALL capabilities to support more batch execution scenarios, and adds support for asynchronous transaction submission within PL.

• Library function memory allocation optimization for high-frequency small objects

  V4.4.2 optimizes library function memory allocation in high-frequency small-object scenarios using mimalloc memory allocator concepts. By implementing sharded memory block organization, delayed idle memory recycling, and lock-free mechanisms, the version significantly improves memory allocation performance, reduces allocation latency and resource contention, and provides efficient, stable memory management for large-scale, high-concurrency workloads.

• Performance optimization for large-scale domestic CPU environments

  V4.4.2 optimizes CPU hotspots in domestic CPU environments, focusing on PDML and replicated table query performance. In 256-core environments, high-concurrency PDML operations see 25% performance improvements while reducing memory consumption in non-PDML scenarios. Replicated table queries from followers improve 14-fold, increasing from 20,000 QPS to over 270,000 QPS—within 10% of the 300,000 QPS achieved when querying leaders directly. These optimizations also benefit 32-core environments.

• Adaptive task splitting for PX

  To address the issue of long-tail tasks in PX scans, V4.4.2 adaptively splits long-tail tasks to achieve load rebalancing and accelerate query speed.

Security enhancements

• Transparent column-level encryption

  V4.4.2 supports transparent data protection that requires no application changes. Database administrators can create column-level data protection rules on tables through DDL statements with appropriate permission controls. SELECT operations on sensitive data without PLAINACCESS privileges return encrypted results, while DML operations are denied access.

Improvements in usability

• Optimized deadlock detection diagnostics

  To enhance the usability of deadlock detection, the new version introduces several diagnostic optimizations. When a deadlock is detected, the internal table now reports significantly richer information, improving the mapping logic from locks to transactions. Additionally, the system now supports deadlock detection in scenarios involving primary key switching. Furthermore, the issue of inaccurate diagnostic information maintenance during dump scenarios has been fixed, enhancing the stability of diagnostics.

• Real-time statistics collection

  GV$OB_SQL_AUDIT and GV$SQL_PLAN_MONITOR are commonly used SQL monitoring views that record key information for each SQL request, including source, execution status, resource consumption, wait time, SQL text, execution plan, operator consumption time, and output rows. However, in scenarios involving storage layer information collection, such as reverse scanning, there are still gaps in the information. To further improve the usability of SQL diagnostics, version 4.4.2 introduces real-time statistics collection from the storage layer and records them in the monitoring views. These include the number of microblocks and rows accessed, the number of microblocks and rows pushed down, the time spent on the push-down path, the time spent without the push-down path, and the number of microblocks and rows skipped by the index. Additionally, the number of rows filtered and the time spent on filtering are also recorded. The collection of statistical information in monitoring views such as SQL audit has been optimized to address issues of incompleteness and inaccuracy.

• Enhanced ASH data integrity

  In V4.2.5, ASH was restructured to track the status of tenant queue requests. Each request writes a record to the ASH buffer every second. Currently, the ASH buffer is 30M and can store approximately 50,000 records. It checks every two minutes whether to persist data to disk. However, in scenarios with a large number of queued requests, the ASH buffer may be overwhelmed before it can persist the data, leading to the loss of important diagnostic data. In V4.4.2, the __all_virtual_ash table has been modified to include a weight column, with a default value of 1. When the ASH buffer is at risk of being quickly filled (usually due to queue buildup), it does not write an ASH record for every queued wait event. Instead, it uses the weight to indicate the importance of the record, thereby enhancing the integrity of diagnostic data.

• SQLSTAT restructuring

  SQLSTAT records statistical information based on the SQL ID and plan hash. This information can be used to directly determine whether an SQL statement is problematic and to identify RT anomalies. However, the current version of SQLSTAT has some known issues:

  • Plan cache shares the library cache, and excessive usage by SQLSTAT can prevent plans from being added to the plan cache.
  • When updating SQLSTAT snapshots, only the leader node's data is updated, while the follower nodes' data snapshots remain unchanged, leading to data errors on the follower nodes.
  • SQLSTAT persists data every hour, which cannot promptly reflect the execution status of SQL statements. To address these issues, version 4.4.2 restructures SQLSTAT. The main changes include:
  • Removing SQLSTAT from the library cache and maintaining a tenant hashmap, which is periodically snapshotted and purged.
  • Accumulating data to the physical plan after each SQL execution and then to the tenant hashmap after reaching the cumulative threshold.
  • Accumulating data from the physical plan to the tenant hashmap before querying the virtual table and then outputting the data.

Compatibility changes

View changes

The following views have been added or modified:

Parameter changes

The following parameter has been added:

System variable changes

Function changes

Syntax changes

Recommended versions of components and tools

The following table lists the recommended versions of components and tools for OceanBase Database V4.4.2.

Upgrade notes

1. Upgrade paths

• Shared-nothing mode: Upgrade from V4.2.5 BP7, V4.4.0, V4.4.0 BP1, or V4.4.1 to V4.4.2 is supported.
• Shared-storage mode: Upgrade to V4.4.2 is not supported.
• Vector data clusters: Upgrade to V4.4.2 is not supported.

2. Upgrade considerations

   If you encounter the following error during pre-upgrade checks:

   tenant has sys table with progressive_merge_round=1: tenant_id xxx table_ids 'xxx'
   

• For V4.2.5 BP7: First upgrade to V4.2.5 BP7 hotfix3 or later, then upgrade to V4.4.2.
• For V4.3.5 BP2 or earlier: If you encounter this error, the upgrade is currently not supported.