OceanBase Database Enterprise Edition V4.2.5

V4.2.5 BP7 Hotfix11

Version information

• Release date: May 29, 2026
• Version: V4.2.5 BP7 Hotfix11
• RPM version: oceanbase-4.2.5.7-107110022026052719

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed a core dump issue in utl_file.

• Fixed a hash join crash in nested loop mode and left-output join scenarios.

• Fixed an issue with automatic source switching when PALF log replication became stalled.

• Fixed a correctness issue in batched execution scenarios involving UPDATE statements and locking operations.

V4.2.5 BP7 Hotfix10

Version information

• Release date: May 12, 2026
• Version number: V4.2.5 BP7 Hotfix10
• RPM version number: oceanbase-4.2.5.7-107100012026050915

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where stop server failed with error -4019 and could not be executed when abnormal servers with full queues existed.

V4.2.5 BP7 Hotfix9

Version information

• Release date: May 09, 2026
• Version number: V4.2.5 BP7 Hotfix9
• RPM version number: oceanbase-4.2.5.7-107090012026050615

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Added support for ORDER BY in the left child of UNION.

V4.2.5 BP7 Hotfix8

Version information

• Release date: April 22, 2026
• Version number: V4.2.5 BP7 Hotfix8
• RPM version number: oceanbase-4.2.5.7-107080022026042120

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where direct load DDL tasks could hang.
• Added support for parallel DDL operations on empty sets in CTAS statements.
• Fixed several issues related to ob_log.

V4.2.5 BP7 Hotfix7

Version information

• Release date: April 14, 2026
• Version number: V4.2.5 BP7 Hotfix7
• RPM version number: oceanbase-4.2.5.7-107070012026041221

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where is_batched_multi_stmt was incorrectly set to 0 when VALUE was used as a column name.
• Added an asynchronous/procedural CPU sampler for scenarios with a large number of tenants.
• Fixed an issue where unit GC caused client disconnections.
• Fixed an issue where log_cb_pool resources were not properly released during GC.
• Allowed tenant workers to process MySQL requests and return error packets while tenant sessions are being killed.

V4.2.5 BP7 Hotfix6

Version information

• Release date: March 27, 2026
• Version number: V4.2.5 BP7 Hotfix6
• RPM version number: oceanbase-4.2.5.7-107060012026032514

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where the LEFT JOIN to ANTI JOIN rewrite incorrectly replaced partition expressions and caused error 4016.
• Fixed an issue in ObSPIService::get_result where flush_buffer was not handled correctly when rendering query results to the client.
• Fixed an issue where inconsistent row-change detection for global indexes during insert-up operations caused error 4377.
• Fixed an issue where insert-up operations did not use point get.
• Fixed an issue where a GOTO statement did not close local cursor variables.
• Fixed an issue where hash join did not skip NULL values from the left table.
• Fixed an issue where some fields were missing during serialization in hash CONNECT BY.
• Fixed a crash that occurred when duplicate keys were used with => in an associative array constructor.
• Fixed an issue where incorrect results were returned when pushing down LIMIT with SQL_CALC_FOUND_ROWS.

V4.2.5 BP7 Hotfix5

Version information

• Release date: February 27, 2026
• Version number: V4.2.5 BP7 Hotfix5
• RPM version number: oceanbase-4.2.5.7-107050012026022515

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Added support for app_trace_id.
• Fixed an issue where enabling cgroup did not fully take effect.
• Fixed an issue where LIMIT was incorrectly pushed down into recursive CTEs.

V4.2.5 BP7 Hotfix4

Version information

• Release date: February 10, 2026
• Version number: V4.2.5 BP7 Hotfix4
• RPM version number: oceanbase-4.2.5.7-107040022026020919

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where the table alias was missing when building ROWID expressions.
• Fixed an issue where CTAS cleanup did not force refresh table schemas after ALTER TABLE.
• Fixed an issue where SPF pkey distributed plans could drop rows with NULL values.
• Fixed the slow performance issue of DBMS_LOB.READ.
• Fixed an issue where backup memory allocation could outpace memory release.
• Added fsync before reading newly written macro blocks during SSTable construction.
• Fixed compatibility version issues.
• Fixed an issue where TRUNCATE TABLE could not clean up useless records in __all_monitor_modified.
• Fixed an upgrade script error that occurred when the -t parameter was added.

V4.2.5 BP7 Hotfix3

Version information

• Release date: January 16, 2026
• Version number: V4.2.5 BP7 Hotfix3
• RPM version number: oceanbase-4.2.5.7-107030012026011319

Release purpose

This release fixes issues reported by users and improves version stability.

Upgrade notes

When upgrading from V4.2.5 BP7, BP7 Hotfix1, or BP7 Hotfix2 to V4.4.2, run the following SQL statement in the production environment for pre-upgrade checks:

select count(*) from __all_tenant a where (
  select count(table_id) from 
  ((select table_id, progressive_merge_round from __all_virtual_table where tenant_id=a.tenant_id) union (select table_id, progressive_merge_round from __all_virtual_core_all_table where tenant_id=a.tenant_id))
  where progressive_merge_round=1 and table_id in (select table_id from __all_virtual_table_history where tenant_id=a.tenant_id and table_id < 10000 group by table_id having count(*) > 1)
) > 0;

• If the SQL output is non-zero, upgrade to V4.2.5 BP7 Hotfix3 before upgrading to V4.4.2.
• If the SQL output is non-zero and the environment involves backup and restore, upgrade to V4.2.5 BP7 Hotfix3 first, increase progressive_merge_round, and complete one backup before upgrading to V4.4.2.

Bug fixes

• Fixed incorrect results caused by ROWNUM-to-OFFSET constraint deduction.
• Added support for disabling shared expression extraction by using a hint.
• Added some transaction error codes to the internal error code list.
• Fixed an issue where Merge Join did not reset match_groups_.
• Fixed a memory leak caused by temporary file directory IDs.
• Fixed an issue where merge join returned incorrect results when the join condition contained shared expressions.
• Fixed an issue where the meta tenant did not adaptively update the throttle limit.
• Fixed an issue with deterministic UDFs.
• Fixed an issue where TO_CHAR returned results inconsistent with Oracle.
• Removed constant expressions during aggregate subquery pull-up.
• Fixed a uint64_t underflow issue in tablet statistics.
• Fixed an issue where error 4038 could occur when dropping tables with NOORDER auto-increment columns.
• Fixed a data inconsistency issue caused by concurrent batch insert operations.
• Fixed an issue where DBLink connection cleanup would hang under high concurrency.
• Fixed DBLink query failures on Chinese schema objects.
• Fixed an issue where SHOW CREATE TABLE lost template information.
• Fixed an issue where the map used by SYS_CONTEXT was not initialized because DDLResolver used ObSQLSessionInfo::test_init() to initialize the session.
• Improved compatibility of streaming cursors when reading uncommitted data.
• Fixed an issue where the return code was overwritten during range filter deserialization.
• Fixed a privilege issue in PL calls after switching databases.
• Fixed inaccurate upper_trans_version values for major SSTables.
• Fixed an issue where sessions could be pushed to the session pool after sys_vars_ allocation failed.
• Added row count checks before building new micro blocks in micro_writer.
• Updated progressive_merge_round for system tables.
• Fixed a use-after-free issue in ObIDiagnoseInfoMgr.

V4.2.5 BP7 Hotfix2

Version information

• Release date: December 12, 2025
• Version number: V4.2.5 BP7 Hotfix2
• RPM version number: oceanbase-4.2.5.7-107020022025121120

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Added support for unused columns in direct load.
• Fixed an alter routine compile debug issue.
• Improved window function performance by reusing frames.
• Fixed the ObInsertUpCtDef initialization issue.

V4.2.5 BP7 Hotfix1

Version information

• Release date: November 28, 2025
• Version number: V4.2.5 BP7
• RPM version number: oceanbase-4.2.5.7-107010032025112814

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed a plan matching issue caused by typed NULL values.
• Fixed incorrect exception handling for internal errors in MySQL-compatible mode.
• Fixed an issue where CREATE INDEX reported error 5019.
• Changed the default server_status_ value in OK packets from 0x22 to 0x02.
• Fixed the wild pointer issue in the log stream balancing module.
• Fixed an issue where overly long query strings could not be displayed.
• Fixed an issue with subquery pushdown.
• Fixed an issue where non-deterministic filters were incorrectly pushed down to base tables.
• Fixed charset conversion issues in nested exception stack messages.
• Avoided querying tablets before transfer during commit.
• Added support for remove_lock_priority in ob_admin.
• Added support for using hints to change the lock mode in DML statements.
• Fixed errors when :NEW columns were updated through IN OUT parameters in triggers.
• Adapted SLOG checkpoints for log-only replicas.
• Added an optional update path for InsertUp operations.
• Changed the default value of _update_all_columns_for_trigger to true.

V4.2.5 BP7

Version information

• Release date: November 3, 2025
• Version number: V4.2.5 BP7
• RPM version number: oceanbase-4.2.5.7-107000092025103121

Upgrade notes

• Versions V4.2.1 BP10 and earlier can be upgraded to V4.2.5 BP7 after first upgrading to V4.2.1 BP11 as an intermediate version.

• V4.2.2 must be upgraded to V4.2.5 BP7 through V4.2.2.1 as an intermediate version.

• Versions V4.2.3, V4.2.4, and V4.2.5 can be directly upgraded to V4.2.5 BP7.

Feature enhancements

• Optimized leader election policy

  In a 4F1A deployment where primary_zone is set to "z1,z2;z3,z4", if the region where z1 and z2 are located becomes unavailable, versions earlier than V4.2.5 BP7 elected the zone with the smallest IP address as the new primary zone. As a result, all Leaders were switched to z3 instead of being balanced across z3 and z4. In V4.2.5 BP7, the leader election policy is optimized so that when all higher-priority zones are unavailable, Leaders are evenly distributed across the zones at the next lower priority level. In this example, Leaders are distributed across both z3 and z4, thereby improving system high availability.

• Supported batch retrieval of index DDL

  In Oracle-compatible mode, the DBMS_METADATA package is extended to support the GET_TABLE_INDEX_DDL function, which retrieves the DDL of all indexes on a table in batches based on the primary table table_name and schema_name. By passing in table_name, users can retrieve the DDL of all indexes on the table, avoiding repeated table lookups based on individual index_name values. In addition, the implementation splits the stored procedure into multiple SQL statements that can use indexes, avoiding the performance overhead caused by full table scans.

• Enhanced SQLSTAT capabilities

  Added support for multi_query, which can be used to identify routing errors and synchronous commit; muti_query_batch_execute, which can be used to determine whether statements use batch optimization; full_table_scan, which can be used to count the number of full table scans performed by SQL statements; and error_count, which can be used to collect SQL error statistics. For more details, see views such as GV$OB_SQLSTAT and DBA_WR_SQLSTAT.

• Accelerated ASH report generation

  Because ASH report generation involves joining ASH data with WR data, the process can be time-consuming. This enhancement accelerates ASH report generation without changing the behavior of ASH reports.

• Supported PL/SQL Wrap in Oracle-compatible mode

  PL/SQL Wrap allows users to encrypt and obfuscate the source code of PL/SQL objects, preventing anyone from viewing the plaintext source code of encrypted objects in *_SOURCE views. This helps meet business requirements for protecting core algorithms and processes. OceanBase provides two methods for encrypting PL/SQL source code: Wrap Utility and the DBMS_DDL system package.

• Adapted backup and archiving to OSS WORM

  Alibaba Cloud OSS provides the WORM (Write Once Read Many) feature. After users configure a retention policy for a bucket, objects in the bucket can only be uploaded and read before the object retention period specified by the retention policy expires. Objects can be modified or deleted only after the retention period expires. In the new version, OceanBase Database backup and archiving is adapted to Alibaba Cloud OSS WORM, supporting OSS buckets with compliance retention policies configured as backup and archiving destinations. This helps users meet requirements for secure data storage and regulatory compliance.

Product behavior changes

OceanBase Database's Oracle-compatible mode now supports parameterized constructors for associative arrays. The parameter format is key=>value;.

Syntax changes

View changes

Bug fixes

• Fixed an issue where space usage was reset before table data usage was calculated.
• Fixed a dynamic memory leak in internal call statements.
• Fixed a memory growth issue caused by dbms_lob using the alloc method of ObPLExecCtx to allocate memory.
• Fixed an issue where IO traffic was not counted when IO requests were canceled.
• Fixed an issue where regular expression execution reported the U_REGEX_TIME_OUT error.
• Fixed an issue where the ObBatchRpc singleton caused a core dump during destruction when OBServer exited.
• Fixed an issue where normal NL paths were ignored in CONNECT BY joins.
• Fixed an issue when populating results for non-streaming cursors without switching the memory context.
• Fixed an issue related to SQL-level memory limit optimization.
• Fixed an issue where constraints were missing after adding a non-null LOB column.
• Fixed a dynamic memory leak.
• Fixed an issue where hostnames in reverse links were printed incorrectly.
• Fixed an issue where the select_into operator was not reentrant.
• Fixed an issue where non-UTF-8 LOB data was encoded as hexadecimal during PL debugging.
• Fixed an issue where BEFORE UPDATE triggers reported error 4377.
• Fixed an issue where the system time zone was set incorrectly.
• Fixed an issue where the precision of numeric division was inconsistent with MySQL.
• Fixed an issue where DBMS_LOB.READ reported error 4002 because lob payload_size was not updated.
• Fixed SQL audit issues for PS cursor FETCH operations by adding more information.
• Fixed an issue where deleteColumns and deleteFamily on tables with maxversion could miss data.
• Fixed an issue where ObRowStore did not release buffers when exceptions occurred.
• Fixed a deadlock issue when updating parameters by avoiding holding the ObTenantConfigMgr::rwlock_ lock while querying internal SQL.
• Fixed an issue where online statistics collection and asynchronous statistics collection competed for locks, causing long insert latency.
• Fixed an issue related to dynamic sampling usage adjustment.
• Fixed a version-control issue in SHOW CREATE FUNCTION.
• Fixed an issue when obtaining the minimum active snapshot version from all sessions.
• Fixed an issue with old query ranges when merging key parts after range conditions.
• Fixed an issue with redundant removal constraints during predicate deduction.
• Fixed an issue with integration of associated table checks.
• Fixed an issue where first_exe_time for streaming cursors was measured from cursor open to the end of fetch.
• Fixed an issue where exiting was set in on_success of the 2PC abort log.
• Fixed an issue with the schema of open-source system views.
• Fixed an issue where outline data could not be obtained when the default database was used.
• Fixed an issue where compiling ALTER ROUTINE could create multiple objects with the same name.
• Fixed a null-pointer exception for session variables caused by malformed packets.
• Fixed an MVCC lock issue when reads failed.
• Fixed an issue where SQL requests were hard parsed in PS and SPM scenarios.
• Fixed an issue with using WaitGuard in SendMsgResponse::wait().
• Fixed an issue where generated columns could not match indexes.
• Fixed an issue where the profiler used an incorrect key_id as the unit_id for types and triggers.
• Fixed an issue where changing columns after table creation reported maximum key length exceeded.
• Fixed an issue where PX hung when internal SQL returned iter end.
• Fixed an issue where delayed materialization was disabled after empty partitions existed.
• Fixed an error that occurred when creating the recycle bin for hidden tables.
• Fixed an issue by adding fb_snapshot to the transaction snapshot of LOB locators.
• Fixed an issue by relaxing strict determinism checks for character types.
• Fixed an issue where constant values cached for precomputed LIMIT expressions were incorrect due to improper memory release timing of the temporary expression factory during plan generation.
• Fixed an issue where a session mistakenly considered an FD to be open because a closed FD was reused.
• Fixed an issue with incorrect shared sub-expressions.
• Fixed an issue with adjustments to the left-row output method of hash joins.
• Fixed occasional XA syntax errors.
• Fixed an issue with enabling parallel NLJ plans for value tables.
• Fixed the user-friendly error message shown when PL debugging lacks CAP_SYS_PTRACE.
• Fixed an issue where the oceanbase prefix was added to view definitions.
• Fixed an issue when restoring multiple small tables.
• Fixed an issue by removing unnecessary system schema change checks.
• Fixed an issue where enabling PL profiler caused compiled PL functions to be stored in the disk cache.
• Fixed an issue with range extraction optimization for information_schema.tables.
• Fixed a DATE_ADD overflow issue.
• Fixed an issue by optimizing memory usage of the JSON path cache.
• Fixed an issue with adjustments to row-count refinement rules.
• Fixed an issue with concurrent access to frames.
• Fixed an issue with range split sampling.

V4.2.5 BP6 Hotfix4

Version information

• Release date: March 31, 2026
• Version number: V4.2.5 BP6 Hotfix4
• RPM version number: oceanbase-4.2.5.6-106040012026033011

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Added an asynchronous/procedural CPU sampler for scenarios with a large number of tenants.

V4.2.5 BP6 Hotfix3

Version information

• Release date: November 25, 2025
• Version number: V4.2.5 BP6 Hotfix3
• RPM version number: oceanbase-4.2.5.6-106030012025112319

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed a plan matching issue caused by typed NULL values.
• Fixed incorrect exception handling for internal errors in MySQL-compatible mode.
• Fixed an issue where error code 5019 was reported during index creation.
• Fixed the wild pointer issue in the log stream balancing module.
• Fixed an issue with subquery pushdown.
• Fixed an issue where non-deterministic filters were incorrectly pushed down to base tables.
• Fixed charset conversion issues in nested exception stack messages.
• Avoided querying tablets before transfer during commit.

V4.2.5 BP6 Hotfix2

Version information

• Release date: October 24, 2025
• Version number: V4.2.5 BP6 Hotfix2
• RPM version number: oceanbase-4.2.5.6-106020012025102316

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where the cluster time zone was not as expected after deployment.
• Fixed an issue where the NOT NULL constraint was missing after a non-null LOB column was added.
• Fixed an issue where space usage was not reset before calculating shared_meta_bytes.
• Fixed an issue where the maximum key length exceeded error was reported when modifying a column definition after table creation.
• Fixed an issue where an optional configuration was missing for skipping required space checks during migration.
• Fixed an issue where SQL requests were hard parsed in PS + SPM scenarios.
• Fixed an issue where fb_snapshot was missing from transaction snapshots of LOB locators.
• Fixed an issue where empty outrow_lob data was not properly handled.
• Fixed an issue where errors were not reported when certain DDL operations caused the primary key length to exceed 16 KB.

V4.2.5 BP6 Hotfix1

Version information

• Release date: September 25, 2025
• Version number: V4.2.5 BP6 Hotfix1
• RPM version number: oceanbase-4.2.5.6-106010022025092415

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where SQL execution reported error 4377. The error occurred when MERGE ANTI JOIN was used by default, while the SQL executed normally after a hint was specified to use HASH ANTI JOIN.
• Fixed an issue where data deletion could be incomplete when deleteColumns or deleteFamily operations were performed on tables with maxversion.
• Fixed an issue where buffers were not released when an exception occurred in ObRowStore.
• Fixed an issue where stored procedure calls failed after an upgrade. A version control mechanism was added to ensure that the SHOW CREATE function can be called normally.
• Fixed a deadlock issue that occurred when updating parameters. The ObTenantConfigMgr::rwlock_ lock is no longer held when querying internal SQL.
• Fixed an issue where a session incorrectly determined that its file descriptor remained open because a closed file descriptor (fd) was reused.

V4.2.5 BP6

Version information

• Release date: August 25, 2025
• Version number: V4.2.5 BP6
• RPM version number: oceanbase-4.2.5.6-106000052025082216

Upgrade notes

• V4.2.1 BP10 and earlier versions can be upgraded to V4.2.5 BP6 after an intermediate upgrade to V4.2.1 BP11.
• V4.2.2 must be upgraded to V4.2.5 BP6 after an intermediate upgrade to V4.2.2.1.
• V4.2.3, V4.2.4, and V4.2.5 can be directly upgraded to V4.2.5 BP6.

Feature enhancements

• Distributed execution optimization

  By optimizing the RPC sending strategy and the GTS acquisition strategy, this release improves performance by 3% to 5% in scenarios where global indexes are used for table access by index rowid.

• Standby database read optimization and stability enhancement

  The transaction status inference mechanism is optimized. Instead of requiring each replica to independently collect participant status, the coordinator leader now centrally collects and caches the status, significantly reducing message interactions. A retry mechanism is also introduced to automatically forward requests to other replicas when a replica lags behind, preventing blocking or incorrect transaction status inference.

• Azure Blob support for object storage

  Azure Blob object storage can now be accessed by using the Azure Blob protocol.

• UDF performance optimization

  To improve the execution performance of UDFs in SQL statements, this release adds result caching for UDFs marked with the DETERMINISTIC clause. It also optimizes the execution path for scenarios where result caching cannot be used.

• Expression enhancement

  The to_pinyin expression now supports more output formats. An optional parameter is added to control the output case and whether the output uses full pinyin or initials.

Product behavior changes

• OceanBase Database can now start on x86 machines that do not support the AVX instruction set.
• When creating an OUTLINE from SQL text, throttling and plan binding can no longer be configured at the same time. To use both throttling and plan binding, bind the OUTLINE by SQL_ID.

View changes

Parameter changes

Bug fixes

• Fixed an issue where INSERT reported the SQL sequence illegal error in specific scenarios.

• Fixed an issue where tasks could fail in high-concurrency scenarios when the number of worker threads in the wait state on the streaming RPC processing side exceeded 100.

• Fixed an issue where a defect in the tablet allocation algorithm on the ADD PARTITION path caused SQL performance fluctuations.

• Fixed an issue with INNER PATH index pruning.

• Fixed an issue where the infos and complement_log directories remained after expired backups were cleaned up.

• Fixed an issue where duplicate sequence values could be generated for sequences during primary/standby switchover and DDL operations.

• Fixed an issue where some global indexes remained in the rebuilding state after global indexes were updated for DROP PARTITION or TRUNCATE PARTITION operations.

• Fixed an issue where NULL values did not hit the FALSE constraint, preventing plan matching and causing frequent hard parses.

• Fixed an issue where SQL statements that cannot generate plans, such as SET statements, occupied a large amount of Lib Cache memory.

• Fixed an issue where SELECT FOR UPDATE in multi-statement execution reported the SQL sequence illegal error.

• Fixed an issue where the PL Resolver reported a syntax error when processing *."LEVEL" if an SQL column name was LEVEL.

• Fixed an issue where, after a CREATE INDEX IF NOT EXISTS statement was executed, the system incorrectly returned success as long as it detected that the index name existed, without verifying the actual index status.

• Fixed an issue where CTE rewrite reported error 4201.

• Optimized heterogeneous zones for tenant replica count changes.

• Fixed an issue where concurrent execution of a large number of large transactions caused clog disks to become fully saturated and backlogged under multithreading.

• Fixed an issue where Query Range extraction was slow due to complex predicates and too many AND conditions.

• Fixed an issue where memory continuously accumulated during PL execution.

• Fixed an issue where vectorized execution had poor performance for INSERT SELECT statements on tables with triggers.

• Fixed an issue where the memory upper limit of each CTX was not checked during memory shrink, which caused error 4013 when LIMIT was smaller than HOLD.

• Fixed an issue where, when a DML RETURNING statement encountered a 6005 lock conflict, the statement could not be retried because some data had already been returned, causing the error to be exposed to users.

• Fixed an issue where execution plans could not be matched when public synonyms were used.

• Fixed an issue where nested subquery pull-up rewrite produced incorrect results.

• Fixed an issue where validation of DEFAULT VALUE reported an error in DDL when a NULL default value was set for a NOT NULL constraint field.

• Fixed an issue where compilation failed because correct dependencies could not be obtained when compiling CURRENT_USER objects.

• Fixed an issue where creating a package across schemas reported an error.

• Fixed an issue where PS cursors could not be routed for the second time.

• Fixed an issue where plan evolution did not occur due to a bound throttling OUTLINE, resulting in low execution efficiency.

V4.2.5 BP5 Hotfix2

Version information

• Release date: August 18, 2025
• Version number: V4.2.5 BP5 Hotfix2
• RPM version number: oceanbase-4.2.5.5-105020012025081414

Upgrade notes

For earlier versions, such as V4.2.5 BP5, if you need to use the INNER PATH index pruning feature, you must upgrade to V4.2.5 BP4 Hotfix5 or later and set the optimizer version parameter optimizer_features_enable to 4.2.5.6. Otherwise, this feature is disabled by default. After optimizer_features_enable is set to 4.2.5.6, subsequent version upgrades will enable all optimizer features introduced in V4.2.5.6 and earlier by default.

Bug fixes

• Fixed an issue where incorrect constraints were generated for rownum >= 0, preventing plans from being matched.

• Allowed outline binding for inner SQL in the oceanbase database.

• Fixed an issue where the infos and complement_log directories remained after expired backups were cleaned up.

• Fixed poor vectorized execution performance when an insert select table had triggers.

• Fixed an issue where ELR became ineffective by rolling back the optimization that caused an ELR performance regression.

• Fixed an issue with INNER PATH index pruning.

• Fixed slow query range extraction caused by complex predicates and excessive AND conditions.

• Made JSON constraint checking behavior compatible with Oracle.

• Fixed an issue where some global indexes remained in the rebuilding state after drop/truncate partition update global indexes was completed.

• Fixed an issue where NULL values failed to match FALSE constraints, preventing plans from being matched and causing frequent hard parsing.

• Fixed an issue where data grew continuously when SPM was used by limiting the storage of baseline-related internal tables. The maximum length of original SQL text was reduced from 10 MB to 64 KB.

• Fixed an issue where DML RETURNING returned an error code to users when a lock conflict occurred.

• Fixed an issue where time was displayed incorrectly in the internal deadlock record table.

• Optimized heterogeneous zones for tenant scale-out multiplier changes.

• Fixed an issue where, in heterogeneous zones, adding units could continue indefinitely when the enable_transfer configuration item was disabled.

• Fixed an issue where RT increased sharply during unit scale-in.

V4.2.5 BP5 Hotfix1

Version information

• Release date: July 18, 2025
• Version number: V4.2.5 BP5 Hotfix1
• RPM version number: oceanbase-4.2.5.5-105010032025071717

Bug fixes

• Fixed an issue where the PL resolver reported a syntax error when handling *."LEVEL" if the SQL column name was LEVEL.

• Fixed an issue where, when a PL object had the same name as an object that depended on a synonym, the query cache was considered expired and had to be resolved again.

• Fixed a core dump issue in OBKV async query scenarios caused by a dangling pointer when a session was reused after being recycled.

• Fixed an issue where sequence values could become duplicated during primary/standby switchover and DDL operations.

V4.2.5 BP5

Version information

• Release date: July 18, 2025
• Version number: V4.2.5 BP5
• RPM version number: oceanbase-4.2.5.5-105010032025071717

Upgrade notes

• To upgrade from V4.2.2 to V4.2.5 BP5, you must first upgrade to V4.2.2.1, and then upgrade to V4.2.5 BP5.
• V4.2.2 must be upgraded to V4.2.5 BP5 through V4.2.2.1.
• V4.2.3, V4.2.4, and V4.2.5 can be directly upgraded to V4.2.5 BP5.

Feature enhancements

• Heterogeneous zones

  Tenants in OceanBase Database can now have up to two different UNIT NUM values, improving O&M capabilities and scale-in/scale-out flexibility. Previously, OceanBase Database required the UNIT NUM to be the same across all zones of the same tenant. When a failure occurred and no replacement server was available, the UNIT NUM had to be reduced for all zones, expanding the O&M scope. In addition, in scale-in/scale-out scenarios, this capability allows operations to be performed first on follower replicas. Then, the leader can be switched to the zone where scale-in or scale-out has been completed, enabling smoother scaling.

• Fast column drop in MySQL-compatible mode

  In MySQL-compatible mode, dropping a column in earlier versions was an offline DDL operation. It required synchronous waiting for data reorganization to complete, and the DDL execution time increased as the data volume grew. The new version introduces fast column drop. During column deletion, table data is not reorganized. Instead, the column is only marked as deleted in TableSchema, that is, as an UNUSED column. Because no data reorganization is performed, the disk high watermark does not decrease after the column is dropped. To completely remove columns marked as deleted, execute the ALTER TABLE TABLE_NAME FORCE command and wait for data reorganization to complete.

View changes

Parameter changes

Syntax changes

Bug fixes

• Fixed an issue where a performance bottleneck in log RPC caused clog persistence failures, resulting in transaction timeouts.

• Fixed an issue where residual information in GV$OB_LOCKS was not released after a parallel insert transaction had ended.

• Fixed an issue where the newly added index_length statistic caused low efficiency in left joins, resulting in excessive CPU usage when querying information_schema.PARTITIONS.

• Fixed an issue where Batch Insert degraded to single-row execution when the inserted values contained a mix of NULL and non-NULL values, resulting in poor performance.

• Fixed an issue where, when DBLink connected to an Oracle database over an unstable network, all worker threads could get stuck on session disconnection. After the threads were exhausted, the tenant became unavailable.

• Fixed an issue where Number-to-TO_CHAR() conversion behaved inconsistently with Oracle Database when scientific notation was involved.

• Fixed an issue where the inner SQL used for deadlock detection to report data to internal tables did not use the standard timeout period. As a result, collecting and reporting deadlock records could time out, and deadlock records might fail to be recorded in internal tables.

• Fixed an error that occurred when SELECT DISTINCT was used on LOB types.

• Fixed an issue where partitions were not deduplicated after physical RowID partition pruning, resulting in unexpected duplicate keys when statistics were fetched.

• Fixed an issue where the S3 driver returned a complete failure on the client side, while complete succeeded on the server side. During retry, the upload was found to no longer exist, causing backup failure.

• Fixed an issue where, under high concurrency in SPM, error code 5136 was incorrectly returned to the client when baselines were read from internal tables and added to memory, or when new plans were added to baselines in memory.

• Fixed an issue where different matching rules were used for Get Plan and Add Plan in direct OceanBase Database connection and OBProxy connection scenarios, causing Add Plan to report that the plan already existed.

• Fixed a data correctness issue caused by incorrect elimination of Cartesian-product Semi-Join.

• Fixed an issue where checksum errors occurred during compaction.

• Fixed an issue where DDL operations related to pseudocolumns were slow by optimizing view dependency calculation through RCTE and improving the read logic for foreign key checks in ALTER operations.

• Fixed an error that occurred when cursor projection columns contained character-type columns.

• Fixed an issue where, after UDR rewrote SQL and generated a remote plan, a mismatch in the number of parameters during remote execution could cause a core dump.

• Fixed an issue where, due to incorrect advisor_table_id configuration for replicated tables, the execution plan could not match replicas when constraints of replicated tables were set to ordinary tables (REMOTE).

• Fixed an issue where, in join queries between ordinary tables and replicated tables, replicated tables could not detect the replica selection of ordinary tables and directly selected a LOCAL replica. This incorrectly generated a distributed plan and caused the REMOTE plan to fail to be matched.

• Fixed an issue where sys_context took a long time to execute.

• Fixed an issue where SPM hard parsing took too long, and optimized the strategy for retrieving replay baselines.

V4.2.5 BP4 Hotfix7

Version information

• Release date: November 14, 2025
• Version number: V4.2.5 BP4 Hotfix7
• RPM version number: oceanbase-4.2.5.4-104070012025111400

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where ALTER TABLE failed.
• Avoided querying tablets before transfer during commit.

V4.2.5 BP4 Hotfix6

Version information

• Release date: September 08, 2025
• Version number: V4.2.5 BP4 Hotfix6
• RPM version number: oceanbase-4.2.5.4-104060012025090511

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Added log inspection and archive management to enable early issue detection and quick troubleshooting.
• Fixed an issue where data kept growing when SPM was used by limiting the storage of Baseline-related internal tables. The maximum length of the original SQL text was reduced from 10 MB to 1 KB.
• Fixed a crash issue caused by DBLink connection caching.
• Added version control to resolve an issue where SHOW CREATE FUNCTION reported an error after upgrade.

V4.2.5 BP4 Hotfix5

Version information

• Release date: August 01, 2025
• Version number: V4.2.5 BP4 Hotfix5
• RPM version number: oceanbase-4.2.5.4-104050032025073119

Upgrade notes

If earlier versions, such as V4.2.5 BP5, need to use the INNER PATH index pruning feature, they must be upgraded to V4.2.5 BP4 Hotfix5 or later, and the optimizer version (optimizer_features_enable) must be set to 4.2.5.6. Otherwise, this feature is disabled by default. After the optimizer version (optimizer_features_enable) is upgraded to 4.2.5.6, subsequent version upgrades will enable all optimizer features introduced in version 4.2.5.6 and earlier by default.

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where residual infos and complement_log directories were left after expired backups were cleaned up.

• Fixed an issue where ELR became ineffective, and rolled back an optimization that caused ELR performance regression.

• Fixed an issue where Query Range extraction was slow due to complex predicates and too many AND conditions.

• Fixed an issue with INNER PATH index pruning.

V4.2.5 BP4 Hotfix4

Version information

• Release date: July 15, 2025
• Version number: V4.2.5 BP4 Hotfix4
• RPM version number: oceanbase-4.2.5.4-104040042025071121

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where hard parsing took too long when SPM was used. The strategy for retrieving replay baselines was optimized.

• Fixed a crash issue where, during two-phase commit, after a participant was killed due to an exception, the primary transaction entered the commit process and sent a commit request to the participant.

• Fixed an issue where recovery over the S3 protocol was slow.

• Fixed an issue where a parameter type mismatch error occurred during PL execution.

• Fixed an issue where sequence values could become duplicated during primary/standby switchover and DDL scenarios.

• Fixed an issue where NULL values did not hit the FALSE constraint and could not match a plan, resulting in frequent hard parsing.

• Fixed an issue where, during migration and replication, I/O on the source side was not correctly tagged. I/O that should have been classified into the background group was incorrectly classified into the other group reserved for SQL foreground requests, causing foreground I/O to be occupied by unrelated operations and affecting user TPS/QPS.

V4.2.5 BP4 Hotfix3

Version information

• Release date: July 03, 2025
• Version number: V4.2.5 BP4 Hotfix3
• RPM version number: oceanbase-4.2.5.4-104030012025070212

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where execution plans failed to match replicas when the advisor_table_id of a duplicated table was incorrectly configured and the table constraint was set to a normal table (REMOTE).

• Fixed an issue where, in join queries between normal tables and duplicated tables, duplicated tables could not detect the replica selected for normal tables and directly selected a LOCAL replica. This caused distributed plans to be generated incorrectly and prevented REMOTE plans from being matched.

• Fixed an issue where, when SPM encountered high concurrent traffic at the time an evolved plan was completed, traffic was continuously assigned to a less optimal evolved plan. As a result, the average CPU time of the evolved plan was underestimated, and the plan was incorrectly selected as the winner.

• Fixed a crash issue that occurred when SPM was enabled and the ALTER SYSTEM FLUSH LIB CACHE GLOBAL; command was executed to flush the Lib Cache, which caused Baselines to be forcibly cleared from memory.

• Fixed an issue where execution plans failed to match replicas when the advisor_table_id of a duplicated table was incorrectly configured and the table constraint was set to a normal table (REMOTE).

V4.2.5 BP4 Hotfix2

Version information

• Release date: June 24, 2025
• Version number: V4.2.5 BP4 Hotfix2
• RPM version number: oceanbase-4.2.5.4-104020022025062018

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed a correctness issue caused by incorrect predicate derivation during query rewrite.

• Fixed an error that occurred when cursor projection columns contained character-type columns.

• Fixed an error in PL Profiler in parallel execution scenarios.

• Optimized the calculation of dependencies between views by using RCTE.

• Fixed an execution error caused by swapped filter order in the ALL_INDEXES view.

• Fixed a crash issue caused by accessing released memory when SPM used a fixed baseline or BaselineFirst mode.

V4.2.5 BP4 Hotfix1

Version information

• Release date: June 16, 2025
• Version number: V4.2.5 BP4 Hotfix1
• RPM version number: oceanbase-4.2.5.4-104010032025061319

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where concurrent loading and writing of baselines could cause memory access conflicts and trigger error 5136.

• Fixed an issue where incorrect calculation of range prefix cnt containing dynamic parameters caused plans to be pruned unexpectedly.

• Fixed an issue where plan retrieval was repeatedly retried when adding a plan failed in SPM + PS mode.

• Fixed an issue where, for large transactions, the checksum state machine was maintained incorrectly when a log was concurrently called back, causing the checksum calculated on the Leader to differ from the checksum reported by followers.

• Fixed an issue where transactions timed out due to clog persistence failures.

• Fixed a performance regression in OLTP index queries.

V4.2.5 BP4

Version information

• Release date: May 30, 2025
• Version number: V4.2.5 BP4
• RPM version number: oceanbase-4.2.5.4-104000082025052817

Upgrade notes

• Versions V4.2.1 BP10 and earlier can be upgraded to V4.2.5 BP4 after first upgrading to V4.2.1 BP11 as an intermediate version.
• V4.2.2 must be upgraded to V4.2.5 BP4 via V4.2.2 BP1 as an intermediate version.
• V4.2.3, V4.2.4, and V4.2.5 can be upgraded directly to V4.2.5 BP4.

Feature enhancements

• Direct load supports cross-version backup import

  Supports table-level data import into OceanBase Database V4.2.5 BP4 through direct load, using logical backups from OceanBase Database V2.2.30 and physical or logical backups from OceanBase Database V2.2.77.

• System view performance optimization

  Refactored the information_schema.COLUMNS view. In most point query scenarios, query_range can now be extracted from fields such as TABLE_NAME.

• Optimizer enhancements

  Some serial plans are optimized into parallel plans for faster execution. In certain scenarios, subqueries are changed from deferred evaluation to early evaluation to reduce the amount of data to be processed.

• Enhanced stability of full schema refresh performance

  After DDL operations are executed, schema refresh behavior is changed from session-level updates to server-level updates. In scenarios with a large number of concurrent session connections, this resolves performance fluctuations caused by each session connection triggering a schema refresh after a DDL operation.

• MySQL-compatible mode supports adding and dropping subpartitions

  In MySQL-compatible mode, when subpartitions use range [columns] or list [columns] partitioning, new rows cannot be inserted once the data exceeds the upper bound of the largest partition created initially. Without the ability to dynamically add subpartitions, this issue could only be resolved by rebuilding the table, which created significant O&M overhead. The new version extends MySQL-compatible mode with new syntax for adding and dropping subpartitions, improving the usability and flexibility of partition management.

• SQL Plan Manager evolution strategy upgrade

  To reduce the impact of low-frequency queries and poorly performing evolved plans, plans with fewer than 150 successful executions are no longer added to baselines. During evolution, traffic is allocated based on total CPU time. This strategy reduces the total number of executions for relatively poor-performing plans because they consume more CPU time per execution, thereby reducing the cost of evolution.

• Optimized index creation speed for empty tables

  Significantly reduced the time required to create indexes on empty tables. The improvement is more pronounced when there are more partitions. Index creation is about twice as fast for non-partitioned tables, 8 to 16 times faster for tables with 16 partitions, and 16 to 40 times faster for tables with 1,024 partitions.

• Standby database log pruning

  In a one-primary-multiple-standby architecture, when the primary tenant fails, failover preferentially selects the standby tenant with the highest synchronization point as the new primary tenant. However, some standby tenants may have log SCNs that exceed the synchronization point of the new primary tenant, preventing them from directly joining the synchronization link of the new primary tenant. In this case, log pruning can be used to remove redundant logs on these standby tenants that exceed the synchronization point of the new primary tenant, allowing them to join the synchronization group of the new primary tenant normally.

• Log stream rebalancing

  Eliminates potential performance hotspots caused by concentrated distribution of non-partitioned tables or continuous distribution of table partitions for partitioned tables. After a non-partitioned table is unbound from a table group, the table is evenly distributed across multiple log streams to avoid concentrated distribution. For partitioned tables, if primary_zone/unit_num is decreased and then increased, table partitions are randomly and evenly distributed across log streams.

• Direct load supports asynchronous commit

  Direct load consists of two stages: write and commit. By making the commit stage asynchronous, a single import task only counts the time spent in the write stage, reducing cases where the entire import task is rolled back due to timeout.

Product behavior changes

• Semantics of session ID fields in system views changed to client session ID

  ODP V4.2.3 and later, together with OceanBase Database V4.2.5 and later, support globally unique client session IDs for cross-component session management. In earlier implementations, however, only views related to session management, such as GV$OB_PROCESSLIST and INFORMATION_SCHEMA.PROCESSLIST, were adapted. Other views, such as GV$OB_SQL_AUDIT, GV$OB_ACTIVE_SESSION_HISTORY, and GV$OB_TRANSACTION_PARTICIPANTS, still used the legacy server session ID, making it difficult to perform correlation analysis and diagnostics for the current session. The new version unifies the semantics of session IDs in system views so that they generally display the client session ID.

• Calling some system packages of regular tenants from the sys tenant

  To improve O&M convenience, the relevant subprograms of DBMS_STATS, DBMS_SCHEDULER, DBMS_RESOURCE_MANAGER, and DBMS_BALANCE can now be called from the sys tenant.

Function changes

View changes

Syntax changes

Bug fixes

• Fixed an issue where plan matching failed for cross-database queries because no database was specified when querying views through synonyms.

• Fixed an issue where SPM could not evolve because the number of plan constraints generated by EXPLAIN differed from the number of plan constraints restored from an outline.

• Fixed a compatibility issue where public synonyms could not be queried due to permission issues.

• Fixed an out-of-memory issue in partition balancing caused by an excessively large table partition.

• Fixed an issue in Oracle-compatible mode where user-defined functions could not be named Year or Month because Year and Month were treated as keywords.

• Fixed an issue where the auto-increment ID returned by select LAST_INSERT_ID() was incompatible with MySQL behavior.

• Fixed an issue where rownum=1 returned unexpected results under constant false conditions.

• Fixed an issue in ARM environments where unexpected NULL values were returned when filter pushdown was used with SIMD optimization.

• Fixed an issue where ASH failed to be persisted to the WR repository because some field lengths were incorrectly checked against boundary values.

V4.2.5 BP3 Hotfix6

Version information

• Release date: November 13, 2025
• Version number: V4.2.5 BP3 Hotfix6
• RPM version number: oceanbase-4.2.5.3-103060032025111215

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where repeated use of the DBMS_LOB.WRITEAPPEND package in PL loops caused memory bloat.
• Fixed an issue where utl_file triggered a core dump in specific scenarios.
• Fixed an issue where temporary table isolation caused deadlocks.
• Fixed an issue where migration failed with error 4551.

V4.2.5 BP3 Hotfix5

Version information

• Release date: June 19, 2025
• Version number: V4.2.5 BP3 Hotfix5
• RPM version number: oceanbase-4.2.5.3-103050012025061710

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where incorrect calculation of range prefix cnt involving dynamic parameters caused plans not to be pruned as expected.
• Fixed a queue backlog issue in DBLink scenarios.

V4.2.5 BP3 Hotfix4

Version information

• Release date: June 03, 2025
• Version number: V4.2.5 BP3 Hotfix4
• RPM version number: oceanbase-4.2.5.3-103040042025052114

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where memory bloat occurred in nested PL Cursor calls.

• Fixed an issue where, after the _push_join_predicate parameter was modified, an original nested loop join (NLJ) execution plan that included non-base-table predicate pushdown was rewritten by the optimizer during Outline replay into a regular NLJ plan that first produced a Cartesian product and then applied the join condition. Because the difference in optimizer calculation logic between the two plans was not reflected in the Plan Hash Value, SPM (SQL Plan Management) could not identify that execution plan replay had failed.

• Fixed an issue where error 4200 was reported when OPEN and CLOSE in UTL were called concurrently by multiple threads.

• Fixed an issue where PL Cache could not be hit in scenarios where PL depended on views and synonyms.

• Fixed an issue where an IPv6 Locality change got stuck when nodes were added.

• Fixed an issue with DAS Rescan plan pruning.

• Fixed an issue where ASH data collection reported an error due to length limits on collected data.

V4.2.5 BP3 Hotfix3

Version information

• Release date: May 9, 2025
• Version number: V4.2.5 BP3 Hotfix3
• RPM version number: oceanbase-4.2.5.3-103030032025050809

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where execution plans could not be hit when querying views through synonyms.
• Fixed an issue where storage pushdown returned incorrect results on ARM platforms.
• Fixed an issue where redundant plans were generated, preventing SPM from evolving.

V4.2.5 BP3 Hotfix2

Version information

• Release date: April 30, 2025
• Version number: V4.2.5 BP3 Hotfix2
• RPM version number: oceanbase-4.2.5.3-103020062025042921

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where the PL/SQL cursor cache became invalid when a public synonym had the same name as a cross-schema stored procedure.

V4.2.5 BP3 Hotfix1

Version information

• Release date: April 23, 2025
• Version number: V4.2.5 BP3 Hotfix1
• RPM version number: oceanbase-4.2.5.3-103010072025041817

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where, when _enable_enhanced_cursor_validation was enabled and a transaction had already been associated with eight or more tables, a cursor accessing the eighth and subsequent tables could not read the current transaction’s modifications to those tables.

• Fixed a correctness issue when a statement contained a constant FALSE condition and rownum=1.

• Fixed a core dump issue that occurred when an NLJ Batch + Union statement was a SELECT constant statement and the number of Union statements exceeded 128.

• Fixed an issue where, during parsing of a package with 6,000 lines, error 4019 was reported due to stack overflow; on the exception path, PL text was printed directly using a stack buffer, causing out-of-bounds memory access and eventually a core dump.

• Fixed an issue where the _ST_GeoHash function returned abnormal results.

• Fixed an issue where assignment could not continue when a Cursor definition used a NULL column.

• Fixed an issue where backup import parsing reported an error when Comment content contained Primary Key.

• Fixed an issue where predicates were lost during Group By pushdown rewrite.

• Fixed an issue with dbms_utility.name_resolve parsing when a public synonym had the same name as a PL object.

• Fixed a correctness issue in paginated queries.

• Fixed a core dump issue in transaction concurrency scenarios.

V4.2.5 BP3

Version information

• Release date: March 31, 2025
• Version number: V4.2.5 BP3
• RPM version number: oceanbase-4.2.5.3-103000142025033110

Upgrade notes

• V4.2.1 BP10 and earlier V4.2.1 versions can be upgraded to V4.2.5 BP3 only after first upgrading to V4.2.1 BP11.
• V4.2.2 must first be upgraded to V4.2.2 BP1 before upgrading to V4.2.5 BP3.
• V4.2.3, V4.2.4, and V4.2.5 can be directly upgraded to V4.2.5 BP3.
• V4.2.5 BP3 adds instruction set requirements for X86 environments. Before startup, OceanBase Database checks whether the current environment supports the AVX instruction set. If the instruction set is missing, startup is prohibited. Upgrading an earlier OceanBase Database version on an X86 machine that does not support the AVX instruction set to this version may cause OceanBase Database to fail to start and be unable to roll back. Please pay close attention to this requirement.

Feature enhancements

• Performance optimization for equality queries on Oracle-compatible views

  More than 30 commonly used data dictionary views in Oracle-compatible mode are optimized. For query scenarios that use table_name and column_name as equality conditions, execution efficiency is improved through base table index optimization.

• I/O optimization in high-TPS scenarios

  The reclamation strategy for transaction data tables is optimized, significantly reducing I/O load in high-TPS scenarios.

• Backup speed optimization

  Backup speed is improved by supporting parallel compensation logs.

• DML execution speed optimization for correlated UPDATE scenarios

  The support scope of PDML is expanded to enable parallel processing of UPDATE statements that contain correlated subqueries, significantly improving the execution efficiency of such DML operations.

• Foreign key optimization in MySQL-compatible mode

  MySQL-compatible mode now supports foreign keys referencing columns with non-unique indexes, relaxes type constraints between parent keys and child keys, and disables cascaded updates for cyclic self-referencing foreign keys.

• Enhanced diagnostics capabilities

  A series of optimizations and enhancements are made to diagnostic capabilities in terms of user readability, collection stability, collection performance, richness of collected metrics, and the time span of collected data.

  • Enhanced ASH REPORT readability

    The presentation of ASH REPORT is restructured across multiple dimensions, including tenant, node, and Top SQL, helping users better understand the running status of OceanBase Database. In addition, ASH REPORT incorporates persisted ASH data obtained from the WR repository to generate reports over a longer time period.

  • New I/O diagnostics capability

    ASH adds collection of I/O-related parameters and corresponding views, providing the ability to monitor the number of I/O reads and writes sampled by ASH and the cumulative size of files read and written.

  • Enhanced SQL collection capability of ASH

    A new feedback mechanism is introduced, enabling ASH to collect SQL statements that could not be collected in earlier versions, including SQL statements in the parsing phase at the sampling point, SQL statements in the optimization phase, and SQL statements in the deserialization phase of cross-level transmission.

  • New transaction-related statistics

    The execution count and execution time of COMMIT and ROLLBACK statements can be monitored through [G]V$SYSSTAT.

  • Stability enhancements and performance optimization

    On machines with Intel CPUs, time collection is combined with CPU frequency to provide more accurate time collection. Stability issues are also resolved, such as some metrics not being correctly collected and ASH REPORT pop-up windows adapting their display width automatically. Memory allocation overhead on the RPC protocol path is reduced.

  • Enhanced SQL plan query capability

    When data in [G]V$OB_SQL_PLAN is empty, the DISPLAY_CURSOR and DISPLAY_SQL_PLAN_BASELINE functions in the DBMS_XPLAN package can query saved historical plans from the WR repository.

Product behavior changes

• When the DBMS_XPLAN package cannot find a plan in the [G]V$OB_SQL_PLAN view, it uses data from the DBA_WR_SQL_PLAN view for the query.

• In scenarios where the backup path is specified as object storage, the backup destination can be changed without re-entering the Access Key and Secret Key.

View changes

Parameter changes

Bug fixes

• Fixed an issue where a minor compaction was triggered when more than 100,000 rows of incremental data had been committed but the incremental data accounted for less than 50% of the baseline data, causing increased CPU and I/O consumption.

• Fixed an issue where, after the audit log buffer of a MySQL-compatible mode became full, the system waited for synchronous writes to disk, causing audit performance degradation.

• Fixed an issue where, when multiple log streams existed on one node, writes performed concurrently in the same disk write thread caused a high number of write tasks, filling up the I/O queue.

V4.2.5 BP2 Hotfix6

Version information

• Release date: October 15, 2025
• Version number: V4.2.5 BP2 Hotfix5
• RPM version number: oceanbase-4.2.5.2-102060012025101315

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed the issue where the cluster time zone did not meet expectations during deployment.
• Optimized performance in large transaction scenarios.

V4.2.5 BP2 Hotfix5

Version information

• Release date: June 06, 2025
• Version number: V4.2.5 BP2 Hotfix5
• RPM version number: oceanbase-4.2.5.2-102050032025060612

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed the queue backlog issue in the DBlink scenario.

V4.2.5 BP2 Hotfix4

Version information

• Release date: May 14, 2025
• Version number: V4.2.5 BP2 Hotfix4
• RPM version number: oceanbase-4.2.5.2-102040012025050823

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where memory bloat occurred in nested PL Cursor calls.
• Fixed an issue where ASH diagnostic information was inaccurate.

V4.2.5 BP2 Hotfix3

Version information

• Release date: March 27, 2025
• Version number: V4.2.5 BP2 Hotfix3
• RPM version number: oceanbase-4.2.5.2-102030052025032518

Release purpose

This release fixes issues reported by users and improves version stability.

Bug fixes

• Fixed an issue where UPPER_TRANS_VERSION in an SSTable could not be correctly calculated when the SSTable contained dumped uncommitted data.

• Fixed an issue where custom TYPE OBJECT IDs became unavailable when the number exceeded 1,048,575.

• Fixed an issue in MySQL-compatible mode where, in XA transactions, the creation and release interfaces of Stash Savepoints used in Trigger scenarios did not match. When the system attempted to release a Savepoint, it returned "not found", causing the Trigger to report an error.

• Fixed an issue where, after some fields in the information_schema.COLUMNS view were changed to the longtext type, the LOB type was not adapted, causing error 4016.

V4.2.5 BP2 Hotfix2

Version information

• Release date: March 17, 2025
• Version number: V4.2.5 BP2 Hotfix2
• RPM version number: oceanbase-4.2.5.2-102020022025031414

Bug fixes

• Fixed an issue where I/O usage was excessively high during partition major compaction.

• Fixed an issue where the DBMS_SQL.DESCRIBE_COLUMNS system package returned incorrect information.

V4.2.5 BP2 Hotfix1

Version information

• Release date: March 11, 2025
• Version number: V4.2.5 BP2 Hotfix1
• RPM version number: oceanbase-4.2.5.2-102000122025011711

Product behavior changes

Added the utl_file_open_max parameter to control the maximum number of UTL_FILE files that can be opened simultaneously on a single node in Oracle-compatible mode.

Bug fixes

• Fixed an issue where error 4016 occurred during the Prepare phase when a query statement contained more than 14 Enum-type fields.

• Fixed an issue where error 4016 occurred when updating data in OBKV mode for wide tables with time-based secondary partitions.

V4.2.5 BP2

Version information

• Release date: January 20, 2025
• Version number: V4.2.5 BP2
• RPM version number: oceanbase-4.2.5.2-102000122025011711

Upgrade notes

• For V4.2.1 BP9 and earlier V4.x versions, upgrade to V4.2.1 BP10 first, and then upgrade to V4.2.5 BP2. V4.2.1 BP10 can be upgraded directly to V4.2.5 BP2.
• For V4.2.2, upgrade to V4.2.2 BP1 first, and then upgrade to V4.2.5 BP2. V4.2.2 BP1 can be upgraded directly to V4.2.5 BP2.
• V4.2.3, V4.2.4, V4.2.5, and later minor versions can be upgraded directly to V4.2.5 BP2.

Feature enhancements

• Weighted partition balancing

  In some business scenarios, access frequency can vary significantly across partitions. For example, if data is partitioned by province, large provinces and small provinces may have significantly different TPS. If balancing is performed only based on the number of partitions, hotspot partitions may still be balanced onto the same OBServer, which can lead to uneven cluster pressure and limit overall throughput. The new version supports weight-based partition balancing. Users can specify weights for partitions, and the partition balancing algorithm then minimizes the variance of the total partition weight across user log streams through partition movement and partition swapping. This helps distribute business traffic more evenly. For more information, see Intra-tenant balancing.

• Manual log stream creation

  Some business scenarios require the primary zone of specific tables or partitions to be specified separately. In V4.x, under the single-log-stream architecture, such fine-grained control was not supported. The new version provides commands for manually creating log streams. Users can create separate log streams and manually transfer partitions to meet these requirements.

• Manual pause and resume of balancing tasks

  Transfer or migration operations triggered by balancing tasks may have an impact on foreground workloads. To facilitate O&M operations at specific times, the new version supports pausing and resuming balancing tasks.

• Control switch for PS parameterization

  OceanBase Database parameterizes constants in prepared statement text, allowing statements with different constants to hit the same execution plan. However, in business scenarios involving large and small accounts, users may intentionally write account-related parameters as constants directly in the prepared statement text instead of parameterizing them with question mark placeholders. Parameters unrelated to account size are still represented by placeholders and bound variables. This approach is expected to allow different execution plans to be used for accounts of different sizes, avoiding suboptimal plans caused by plan sharing. Therefore, the new version adds a tenant-level switch, enable_ps_parameterize, for PS parameterization. For scenarios where question mark placeholders are not used, users can selectively disable PS parameterization.

• Real-time SQL-level memory display

  In earlier versions, SQL Audit recorded memory information for completed SQL statements, but did not provide real-time memory usage information. In some business scenarios, users need to monitor overall memory usage and, when memory usage reaches a certain threshold, generate alerts for SQL statements that are consuming large amounts of memory to facilitate subsequent O&M operations. The new version adds real-time SQL/PL-level memory resource usage statistics to the [G]V$OB_PROCESSLIST view, which can be used to display the top N SQL statements in real time.

• Enhanced SQL Audit information

  To support business diagnostics, the new version adds descriptive fields to the [G]V$OB_SQL_AUDIT view, including the client port, transaction information, and PL compilation time.

• Support for specifying source nodes for backup and archiving paths

  Common OceanBase cluster deployment modes include three data centers in the same city, three data centers across two regions, and five data centers across three regions. In these deployment modes, cross-data center and cross-region network bandwidth is typically more limited than local bandwidth. Database backup often generates a large amount of network traffic. To control the use of limited network bandwidth during backup, the new version provides path configuration options for data backup and log archiving. Users can configure accessible zones, data centers, or regions to specify the range of nodes that can be used as source nodes for data backup and archiving.

• Enhanced Event functionality in MySQL-compatible mode

  Event Scheduler now supports time expressions such as CURRENT_TIMESTAMP and NOW, and also supports calling stored procedures by using CALL statements in the body. EVENT privilege control has also been added.

• Passwordless login with TLS certificates

  Added TLS certificate-based login, providing a more secure authentication method for ecosystem components to access the database.

• SM algorithm support for RPC transport encryption

  The ssl_external_kms_info parameter now supports setting SCENE to 'ANT_SM', so that RPC communication uses SM cryptographic algorithms.

• OLTP performance optimization for small specifications

  In small-specification Sysbench read/write scenarios, performance is improved by 10% to 20% compared with V4.2.5. In single-row query scenarios using unique indexes, performance is significantly improved across different specifications.

• OBKV-HBase compatibility and feature enhancements

  Earlier versions were compatible with most HBase 1.x features. The new version further improves compatibility with HBase 1.x and 2.x, including support for multiple namespaces, ColumnRangeFilter, ColumnValueFilter, CheckAndMutateBuilder, mixed Batch operations, and CheckAndMutateBuilder. In addition, the new version supports batching Get, Put, and Delete operations through the batch API in the OBKV-HBase client. Put operations are also adapted to group commit, resolving the issue where users could not fully benefit from Batch performance because each Put operation wrote too few qualifiers.

• Enhanced OBKV-Table functionality

  In earlier versions, checkAndInsUp performed no operation if the check failed. In some customer scenarios, users use checkAndInsUp to implement CAS operations, which are atomic operations. Such atomic operations require an error to be returned when the check fails. To meet this requirement, the new version adds support for RollbackWhenCheckFailed in checkAndInsUp. If the check fails, the [-10518][OB_KV_CHECK_FAILED] error is returned and the transaction is rolled back.

• OBKV-Redis performance optimization

  OBKV-Redis performance is improved through periodic refresh of parameters and variables, a lock-free session pool, optimized connection statistics, and Redis model-layer optimizations. Depending on the operation type, performance is improved by 4% to 96%.

• ob_admin support for parsing AssumeRole access parameters

  V4.2.5 introduced support for accessing object storage by using AssumeRole. The new version further adds support for ob_admin to parse parameters related to AssumeRole-based access.

• Performance optimization for statistics collection

  Statistics collection on large tables relies on block sampling. In the new version, block sampling is adapted to vectorized execution, resulting in a noticeable performance improvement.

Parameter changes

View changes

System package changes

Function changes

Syntax changes

Ecosystem compatibility changes

OceanBase Database V4.2.5 BP2 must be used with ODP V4.3.3 Hotfix1 or later.

Bug fixes

• Fixed an issue where the EXPLAIN INTO SET statement_id statement reported an error under the PS protocol.
• Fixed memory leak and core dump issues caused by PL in specific scenarios.
• Fixed inaccurate syntax error positioning when PL text contained a Chinese right parenthesis.
• Fixed an issue where a session could not be killed when an SQL statement contained more than 64 OR conditions.
• Fixed an issue where no metrics were collected for OBKV batch checkAndInsertUp.
• Fixed an issue where, if dynamic sampling was triggered when a partition name was numeric, abnormal reverse parsing caused an SQL error.
• Fixed an issue where a large IN list combined with implicit type casting caused high plan generation latency and high memory usage.

V4.2.5 BP1 Hotfix2

Version information

• Release date: January 15, 2025
• Version number: V4.2.5 BP1 Hotfix2
• RPM version number: oceanbase-4.2.5.1-101020052025011421

Bug fixes

• Fixed an issue where Query Range Size overflow caused incorrect pruning.
• Fixed an issue where, when the OBServer version was V4.2.2 or later and the ODP version was earlier than V4.2.3, the Change User command could hang if users logged in by using a native MySQL driver of a later version and the caching_sha2_password authentication method.
• Fixed an error that occurred during KV parameter template initialization.
• Fixed error 4016 that occurred during system package upgrades.
• Fixed an issue where SqlSession memory bloat occurred under the ResetConnection protocol.
• Fixed a core dump issue caused by the SUBSTR function with two parameters in the WHERE condition of an SPJ subquery.

V4.2.5 BP1 Hotfix1

Version information

• Release date: January 2, 2025
• Version number: V4.2.5 BP1 Hotfix1
• RPM version number: oceanbase-4.2.5.1-101010012024123117

Bug fixes

• Fixed an issue with optimizer DAS rescan path pruning.
• Fixed an occasional issue where materialized views became unreadable.

V4.2.5 BP1

Version information

• Release date: December 6, 2024
• Version number: V4.2.5 BP1
• RPM version number: oceanbase-4.2.5.1-101000182024120722

Upgrade notes

• If you are running V4.2.1 BP9 or any earlier V4.x release, you must first upgrade to V4.2.1 BP10 before upgrading to V4.2.5 BP1. You can upgrade directly from V4.2.1 BP10 to V4.2.5 BP1.
• If you are running V4.2.2, you must first upgrade to V4.2.2 BP1 before upgrading to V4.2.5 BP1. You can upgrade directly from V4.2.2 BP1 to V4.2.5 BP1.
• If you are running V4.2.3, V4.2.4, or V4.2.5, you can upgrade directly to V4.2.5 BP1.

Feature enhancements

• DBMS_SCHEDULER enhancements

  DBMS_SCHEDULER has been moved from the Root Service (RS) into individual tenants to provide tenant-level task isolation. This also improves overall scheduling performance. You can now use set_attribute to modify the max_failures attribute of a job, and use commands to recover jobs whose state is BROKEN. This release also adds support for JOB_CLASS, including creating and dropping job classes, setting job class attributes, and binding job classes to jobs.

• MYSQL_EVENT enhancements

  MYSQL_EVENT compatibility has been further improved. This release adds support for modifying EVENT_DEFINER, using SHOW EVENT, using time expressions, and calling stored procedures and functions through CALL statements.

• Column encryption

  Column encryption based on TDE transparent encryption is now supported for MySQL-compatible tenants. Two functions are provided: enhanced_aes_encrypt() for encrypting column data and enhanced_aes_decrypt() for decrypting column data. Two user-level privileges, ENCRYPT and DECRYPT, are also added for secondary authorization. A user can use the encryption or decryption functions in DML statements only when the user has both the required DML privileges and the corresponding ENCRYPT or DECRYPT privilege.

• OBKV enhancements

  OBKV-HBase compatibility with HBase has been significantly improved. OBKV-Redis performance has also been optimized through group commit. In addition, OBKV-Redis now provides three new monitoring metrics: P99 latency, total command executions, and total command execution time. Users can query these metrics through views for sampling and statistics, and export them to Prometheus for visualization and analysis.

• OBCDC data dictionary DUMP scheduling optimization

  Data dictionary scheduling is now integrated with DBMS_SCHEDULER. This enhancement supports specifying a scheduling interval, pausing and resuming scheduling, immediately triggering data dictionary generation, purging historical data dictionary records, and adjusting the retention period for dictionary history records.

• Pre-scaling

  A scaling factor has been introduced to define how many log streams a log stream should be split into. New log stream O&M commands are also added to modify the location and primary_zone information of log streams, preparing the system for future scaling.

• Weak-consistency reads at the Serializable isolation level

  Weak-consistency read requests are now supported at the Repeatable Read and Serializable isolation levels.

• PL enhancements

  Added support for AFTER LOGON and BEFORE LOGOFF triggers. Improved the performance of index-by tables used in anonymous blocks, as well as the query performance of the mysql.proc view. For Oracle-compatible tenants, this release adds compatibility with the UTL_SMTP and UTL_TCP system packages, and the DBMS_UTILITY.COMMA_TO_TABLE subprogram. For MySQL-compatible tenants, this release adds support for the ALTER PROCEDURE ... COMPILE and ALTER FUNCTION ... COMPILE syntax, allowing users to manually compile procedures and functions when needed.

• Optimized replica selection for replicated tables

  For replicated tables that have been modified within a transaction, query plans now select the leader replica of the replicated table. Overall, replica selection for replicated tables now falls back to the same behavior as regular tables.

• NFSv3 support for backup and restore

  Backup and restore in OBServer already supported NFSv4 in earlier versions. This release adds support for NFSv3.

• Arbitration service support for hybrid-cloud active-active deployments

  A new cluster-level parameter, arbitration_degradation_policy, is added to configure different arbitration degradation policies. When this parameter is set to CLUSTER_POLICY, the log stream leader checks whether it can communicate with the Root Service (RS) before degradation. If it cannot communicate with the RS, degradation is not performed. Instead, the log stream enters an election "silent" state, preventing the current replica from being elected as leader again. This ensures that the leader is eventually switched to a replica that has network connectivity to the RS.

• Batch DML performance optimization

  Batch DML performance is significantly improved by implementing true batch interfaces in the storage layer. This improves performance in scenarios such as batch insert, deleting large amounts of data, and insert on duplicate key update.

• Parallel DROP TABLE support

  DROP TABLE statements are now executed in parallel instead of serially, improving throughput in scenarios where tables are dropped frequently.

• Additional Latin collations

  Added support for the following Latin collations: latin1_german1_ci, latin1_danish_ci, latin1_german2_ci, latin1_general_ci, latin1_general_cs, and latin1_spanish_ci.

• Batch import of existing execution plans into SPM baselines

  In addition to importing execution plans from the plan cache into an SPM baseline by specifying a SQL_ID, this release adds support for importing multiple execution plans in batches.

• Full support for Rocky Linux 9

Product behavior changes

Disabled combined ALTER TABLE ADD INDEX + DROP INDEX operations

The behavior of ALTER TABLE ADD INDEX and DROP INDEX differs from that of MySQL. Running these operations together may leave the system without a usable index. To avoid errors and impact on business workloads, combined ALTER TABLE ADD INDEX and DROP INDEX operations are disabled by default. To use this feature, make sure you fully understand its impact and enable it through the corresponding parameter.

Parameter changes

Static system variable changes

View changes

Syntax changes

Considerations

At the Serializable isolation level, a transaction snapshot is retained after a transaction starts and is released only after the transaction is committed. Therefore, when using the Serializable isolation level, make sure transactions are committed in a timely manner. Otherwise, disk usage may increase, or read performance may gradually degrade.

Bug fixes

• Fixed issues such as memory leaks caused by PL in specific scenarios.
• Fixed issues such as I/O-related memory leaks in specific scenarios.
• Fixed abnormal errors related to backup and restore.
• Fixed issues such as log replay failures and unit migration failures after upgrades.
• Fixed an issue where DBMS LOB caused memory bloat.
• Fixed a performance regression caused by adaptive joins.
• Fixed a performance regression in the OBKV single-operation interface.
• Fixed an issue where local index creation was slow.
• Fixed several upgrade compatibility issues.

V4.2.5

Version information

• Release date: October 21, 2024
• Current version: V4.2.5
• RPM version: oceanbase-4.2.5.0-100000082024102022

Version overview

OceanBase Database V4.2.5 is a new Long-Term Support (LTS) version designed for transaction processing (TP) and key-value (KV) services. Building on the foundation of V4.2.4, this version introduces several enhancements. Notably, it supports baseline-prioritized SQL plan management (SPM) evolution and partitioned table-based late materialization. Additionally, improvements to the cardinality estimation system, common table expression (CTE) extraction, and inlining cost verification significantly enhance the optimizer's capabilities. To further boost system stability and reliability, the new version includes features such as consumption logs, forcible stopping of archiving jobs, active transaction transfer, and adaptive arbitration upgrades or downgrades based on I/O load.

In terms of compatibility, V4.2.5 introduces features like lock functions, invalid dates, and eXtended Architecture (XA) transactions in MySQL-compatible mode, making it easier to migrate business operations from MySQL databases. For Oracle-compatible mode, enhancements include improvements to the DBMS_LOCK package, support for quick column dropping, and the ability to handle complex parameter types in remote stored procedure calls between Oracle-compatible tenants. The new version also optimizes table-level restore performance and upgrade processes, significantly reducing the time required for these operations. Furthermore, it enhances resource isolation by supporting isolation for statistics collection, clog commit, and DDL operations. Memory management has also been improved, with the ability to limit memory usage at the SQL statement level and optimize memory usage for stored procedures, ensuring greater stability across various scenarios.

Ease of use is another key focus of this release. The Active Session History (ASH) diagnostic module now provides row lock wait and retry wait events, response time histograms, and log transmission link views, greatly improving system observability. Additional enhancements include optimized parallel log replica migration, real-time application of unit configuration changes, and the introduction of the ./alert/alert.log file, which records logs of interest to database administrators (DBAs), further streamlining usability. The new version also expands the multi-model ecosystem of OceanBase Database. It introduces support for the OBKV-Redis model and optimizes expired data deletion in the OB-HBase model, addressing issues related to excessive data versions in hotkey scenarios. Moreover, it adds the ColumnPaginationFilter filter and reverse scan functionality to enhance compatibility with Apache HBase.

Key features

Kernel enhancements

• Global indexes bound with the same table group as the primary table when the SHARDING attribute of the table group is set to NONE

  In earlier versions, global indexes are not bound with table groups. The primary table within a table group and its global indexes may be located on different OBServer nodes. Since V4.2.5, if the primary table is bound with a table group for which the SHARDING attribute is set to NONE, the database requires that the global indexes have the same data distribution as the primary table before you perform DDL operations related to the global indexes, such as CREATE TABLE, CREATE TABLE LIKE, CREATE INDEX, ALTER TABLE ADD INDEX, TRUNCATE TABLE, and TRUNCATE PARTITION. If you execute the ALTER TABLE statement to bind the primary table with a table group for which the SHARDING attribute is set to NONE, the global indexes are bound with the primary table for table group alignment.

• Adaptive join

  In earlier versions, the optimizer selects the optimal join method for a query with a join during the plan generation phase based on statistics. If the statistics are inaccurate or outdated, the join method selected by the optimizer is not the optimal one. For example, if the optimizer estimates that the table contains a few rows based on statistics, it may select nested-loop join (NLJ). However, if the table actually contains much more rows than estimated, hash join may be the optimal choice for higher performance. To resolve this issue, the new version introduces the adaptive join feature, which allows the database to select the most appropriate join method dynamically rather than merely depending on statistics.

• Improvement on the cardinality estimation system of the optimizer

  Cost estimation by the optimizer relies on accurate cardinality estimation for each operator. Accurate cardinality estimation relies on an appropriate estimation strategy and accurate statistics. OceanBase Database V4.2.2 has restructured the base table-based and selectivity-based cardinality estimation methods to improve the cost estimation accuracy of the optimizer. OceanBase Database V4.2.4 makes improvements for some complex scenarios. OceanBase Database V4.2.5 further enhances the cardinality estimation system in the following aspects to improve its accuracy in some scenarios:

  • A lower bound is specified for the selectivity of complex joins that contain multiple types of join conditions and loop joins that involve multiple tables. This requires that when an inner or outer join contains complex join conditions, each row of the small table be joined with at least one row of the large table. That is, the selectivity is not lower than 1/N, where N is the number of rows in the large table. This resolves the issue that the number of rows estimated for a loop join is too small.
  • The number of rows joined after a filter is corrected to improve the accuracy in estimating the number of rows to be joined.
  • For an anti-join that contains predicates, if the predicates on one table are highly selective, cardinality estimation uses base containment assumptions instead of simple containment assumptions for improved accuracy.

Enhanced DBLink capabilities: domain name resolution and remote binary data writing

OceanBase Database allows you to use a DBLink to access a remote database. In earlier versions, you need to specify the IP address of the remote database when you create the DBLink. In V4.2.5, you can configure a domain name and write binary data to the remote database by using the DBLink.

• Support for using a hint to specify to use hash join for a CONNECT BY hierarchical query

  You can select NLJ or hash join for a CONNECT BY hierarchical query. In earlier versions, a join method is selected based on rules. Hash join is selected only when no index is available. However, in some scenarios, hash join is a better choice even if an index is available. In V4.2.5, you can use the USE_HASH hint to specify to use the hash join method for a hierarchical query. You can also bind an outline for the hierarchical query.

• Serverless-oriented optimization

  OceanBase Database V4.2.5 is optimized in the following aspects to better adapt to the serverless architecture:

  • The meta tenant and user tenant can share the memory. This resolves the issue where the meta tenant of a large-sized user tenant has insufficient memory space whereas the meta tenant of a small-sized user tenant has low memory usage.
  • Threads in the commonly used thread pool ObSimpleThreadPool can be dynamically adjusted. In earlier versions, the number of threads in a thread pool is statically specified when the thread pool is created. In V4.2.5, the number of threads in a thread pool can be dynamically increased or decreased based on the request queue length. This dynamic resizing is supported by some background thread pools.
  • The local memory for threads is reduced. The local memory for threads is reduced by removing unnecessary local variables of threads, decreasing the memory usage by local variables, and minimizing the lifecycle of local variables.

• Distributed late materialization

  In a single-table query, the database usually uses the index table to identify matching rows and then queries row data from the primary table, preventing a full-table scan. Each access to the primary table is a random I/O query. If a large amount of data is involved in table access during the execution of an SQL statement, a significant amount of performance resources is consumed. Take the statement select * from t1 where c1 > 1 order by c2 limit 10 as an example. If a composite index on c1 and c2 exists, the generated execution plan typically filters data that meets the c1 > 1 condition in the index table, then accesses the t1 table to retrieve data, and finally selects the top 10 data records. If a large amount of data is involved in table access, the performance may deteriorate. However, if you modify the execution plan to first filter data based on the index table, then sort the data and select the top 10 data records, and finally query the primary table for 10 times, the amount of performance resources consumed by random I/Os is significantly reduced. This optimization strategy is called late materialization. Simply put, late materialization is a strategy where a single-table query sorts the filtered data and limits the number of data records returned before retrieving data from the primary table, thus reducing performance resource consumption by random I/Os.

  OceanBase Database supports late materialization for non-partitioned tables in earlier versions, and supports late materialization for partitioned tables in V4.2.5.

• Index selection optimization

  In V4.2.5, when statistics expire, only rule-based optimization is retained and dynamic sampling is enabled to address the issue of index deviation. Global statistics are used to prevent index deviation caused by the absence of histograms after partition pruning when data skew occurs in indexed columns. New cost coefficients are used to calculate the projection overhead and filtering overhead of large object (LOB) columns to improve the index selection accuracy.

• Improvements in cost-based rewrite deviation and time consumption

  Queries can be rewritten based on rules or costs. Unlike rule-based rewrite, cost-based rewrite cannot ensure that the rewritten query can achieve the optimal performance in all scenarios. Generally, the performance of a query is subject to data distribution and whether an appropriate index is available. Therefore, cost-based rewrite requires cost verification. Cost verification remains incomplete and incurs two issues: rewrite deviation and high time consumption in hard parsing. OceanBase Database V4.2.5 reduces the time consumed in a single cost verification and limits the number of retries allowed in cost-based rewrite to reduce the time consumption of cost-based rewrite.

• SQL query interface enhancements

  OceanBase Database V4.2.5 implements access isolation for read-only replicas. This feature defines the routing rule for internal data requests. It is prohibited to forward requests destined for a read-only replica to a non-read-only replica, thereby implementing resource isolation between TP and analytical processing (AP) services and ensuring long-term stable operation in hybrid transaction/analytical processing (HTAP) scenarios. This rule does not apply to requests destined for non-read-only replicas. The metadata structure in the result set is modified. OBServer nodes obtain server metadata based on the tenant mode. Based on the server metadata obtained, the Java Database Connectivity (JDBC) driver derives the metadata to serve metadata access requests of users.

• Improvements in CTE extraction and inlining cost verification

  CTE extraction and inlining are two choices for the common calculation module. CTE extraction materializes the calculation results of CTEs by using the WITH clause. The calculation results can then be directly referenced. CTE inlining does not materialize the calculation results of CTEs. The result of each CTE is calculated in the context where it is used. OceanBase Database V4.2.5 abstracts a common inlining and materialization cost verification module to enhance cost verification for CTE inlining, improving the accuracy of local cost verification.

• Enhanced query range extraction capabilities

  OceanBase Database V4.2.5 enhances the query range extraction capabilities. It supports range extraction for spatial columns, implicit conversion, and quick path extraction in NLJ rescan scenarios. In addition, the query range pruning feature is associated with the cost model. The database determines the query range and the end column of the query range based on costs.

• Enhancement in lock contention management

  The new version enhances lock contention management for local executions by removing reliance on the wakeup mechanism and eliminating unnecessary wait times. It also introduces improved lock contention management for remote executions. By combining proactive detection at the source with wakeup notifications at the destination, the new version avoids aimless retries during remote lock contention, thereby reducing CPU and network overhead. For hotspot rows with multiple transactions requesting locks, the database prioritizes wakeups based on the order of the requests. This ensures older requests are not blocked by newer ones, prevents CPU jitter caused by simultaneous retry attempts from multiple requests, and minimizes wakeup delays in exceptional cases.

• Log stream replica migration optimization

  In a disaster recovery scenario in earlier versions, unit migration from one OBServer node to another triggers replica migration. If the amount of data is large, the migration may take a long time. If you migrate the units back to the source OBServer node, you can migrate the corresponding replica back to the source OBServer node only after the replica migration to the destination OBServer node is completed. These meaningless migrations compromise the replica migration efficiency. This scenario is optimized in V4.2.5. If the database detects any unneeded replica migration tasks during log stream replica migration, it automatically cancels the tasks to improve the replica migration efficiency.

• Forcible stopping of log archiving jobs

  A log archiving job writes corresponding metadata in the archive directory of the archive media when each round begins and ends. When you stop an archiving job in earlier versions, the archiving job advances to the STOP state only after the archiving stopping metadata is written. If the archive media cannot be accessed, metadata cannot be written to the archive directory. As a result, the archiving job cannot be stopped and remains in the STOPPING state. To address this issue, OceanBase Database V4.2.5 provides the forcible archiving job stopping feature. An archiving job can advance to the STOP state without the need to forcibly write archiving stopping metadata. When archive logs are consumed, the system cannot determine whether the forcibly stopped archiving round has been completed, which affects archive log consumption by downstream systems.

• Globally unique client session ID

  Prior to OceanBase Database V4.2.5 and OceanBase Database Proxy (ODP) V4.2.3 BP1, when the client executes SHOW PROCESSLIST through ODP, the client session ID in ODP is returned. However, when the client queries the session ID by using an expression such as CONNECTION_ID or from a system view, the session ID on the server is returned. A client session ID corresponds to multiple server session IDs. This causes confusion in session information queries and makes user session management difficult. The uniqueness of the client session ID cannot be ensured across ODPs. Therefore, killing a session across ODPs may fail or such a session may be mistakenly killed. In the new version, the client session ID generation and maintenance process is reconstructed. If the version of OceanBase Database is not earlier than V4.2.5 and the version of ODP is not earlier than V4.2.3 BP1, the session IDs returned by various channels, such as the SHOW PROCESSLIST command, the information_schema.PROCESSLIST and GV$OB_PROCESSLIST views, and the connection_id, userenv('sid'), userenv('sessionid'), sys_context('userenv','sid'), and sys_context('userenv','sessionid') expressions, are all client session IDs. You can specify a client session ID in the SQL or PL command KILL to terminate the corresponding session. If the preceding version requirements for OceanBase Database and ODP are not met, the handling method in earlier versions is used.

• Enhanced CDC

  OceanBase Database V4.2.5 enhances the Change Data Capture (CDC) feature in the following aspects:

  • The beforeimage output of LOB data stored in OUTROW mode is improved to resolve the issue where the beforeimages of LOB columns in updated rows are incomplete in the following scenarios: a DELETE statement is executed, an UPDATE statement is executed on the primary key, an UPDATE statement is executed to change the storage mode of a LOB column from OUTROW mode to INROW mode, and an UPDATE statement is executed on a non-LOB column.

  • The storage structure of transaction logs in CDC is optimized and the log pullback framework is restructured. This optimization improves the efficiency of OBServer nodes providing logs to CDC and allows for faster retrieval of missing transaction logs when CDC is started during a transaction, thereby increasing CDC startup efficiency during a transaction.

  • Newly generated data can be synchronized to a table created through a table-level restore.

  • Synchronization of data in virtual generated columns is supported to meet the data consumption requirements of downstream systems.

• Support for data synchronization from the standby tenant in CDC

  Standby database is an important part in the high-availability system of OceanBase Database. OceanBase Database supports primary/standby tenants since V4.1. A standby tenant serves as a backup of a production tenant, namely, the primary tenant. When the primary tenant fails to provide services, the standby tenant can switch to the PRIMARY role to provide services. This shortens the unavailability time and improves the error tolerance capability of the database system. CDC formats and delivers incremental transaction data in OceanBase Database in units of transactions to downstream components for consumption. Synchronization of data from the standby tenant is supported for the following purposes:

  • Consume data in the local database: If an application that needs to consume CDC data is located in a different region from the primary tenant, it preferentially consumes incremental transaction data from the local standby tenant.
  • Consume data in the standby tenant after a switchover. After a switchover, CDC can switch to the consumption link of the standby tenant to avoid interrupting the data link.
  • Reduce the impact on the primary tenant and ensure business stability in the primary tenant.

• Baseline-prioritized SPM evolution

  In earlier versions, SPM evolution proceeds online. When a new plan is generated, it immediately evolves based on the baseline plans. If the SPM module verifies that the new plan is superior to the baseline plans based on the average CPU time required for plan execution, the new plan is used and marked as a baseline plan. Online evolution can address most execution plan deviation issues. However, bad cases also occur. For example, if the data amount is small when a new plan is generated, the SPM module misjudges that the new plan outperforms existing plans. When the data amount surges, the new plan is no longer suitable. OceanBase Database V4.2.5 provides an SPM evolution mode that prioritizes a baseline plan. In this mode, the optimizer always uses a baseline plan unless no reproducible baseline plan is available. In this case, all baseline plans are considered to be in the FIXED state.

Compatibility with MySQL

• Lock functions

  OceanBase Database V4.2.5 supports the following MySQL lock 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, such as 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. Lock functions are a type of built-in functions that allow you to define and use locks.

• Table locking

  OceanBase Database V4.2.5 supports the LOCK TABLE and UNLOCK TABLE syntaxes. After a table is locked, other locking, writing, and DDL operations on the table are blocked. To lock a table in a tenant, you must have the LOCK TABLE privilege. The tenant-level parameter ENABLE_LOCK_PRIORITY is provided to specify to enable table lock priorities. After table lock priorities are enabled, the RENAME TABLE statement has the highest priority in obtaining a table lock. When a RENAME TABLE statement is waiting for a table lock together with another DDL operation, a locking operation, or a DML operation, the RENAME TABLE statement is the first to obtain a table lock. At present, the support for the table locking feature of MySQL is limited.

• Restructured ENUM and SET data types

  The ENUM and SET data types are generally used to store strings of a limited number of types, to save the storage space and improve data processing efficiency. ENUM and SET data is stored as numeric values and explained as character arrays. The new version optimizes the metadata storage structure of the ENUM and SET data types. It saves information about complex character arrays in a subschema context to reduce the attention of developers for ENUM and SET metadata transfer. In addition, the general type conversion logic makes the derivation of the ENUM and SET data types simpler and more efficient.

• Compatibility with invalid date types of MySQL

  OceanBase Database V4.2.5 supports invalid date types. The sql_mode system variable specifies whether to allow the storage of invalid date types. For example, you can add the ALLOW_INVALID_DATES keyword to store a date that does not exist, such as 2024-2-30, or the NO_ZERO_IN_DATE keyword to store such a date as 2022-01-00. The _enable_mysql_compatible_dates parameter is provided to specify whether to support invalid date types of MySQL.

• Quick insertion of columns in the middle of a table

  The DDL operation for inserting columns in the middle of a table is changed from an offline operation in earlier versions to an online operation in V4.2.5 to improve the operation performance. At present, you can use ADD COLUMN in combination with MODIFY COLUMN or use ADD COLUMN alone to insert columns in the middle of a table online.

• XA transaction support

  OceanBase Database V4.2.5 supports syntaxes related to XA transactions, namely, XID, XA_START, XA_END, XA_PREPARE, XA_COMMIT, XA_ROLLBACK, and XA_RECOVER. Pay attention that XA transactions cannot be implicitly committed. If you execute a DDL statement in an XA transaction, an error is returned.

• Character set improvement

  To meet the requirements for specific character sets in different regions outside the Chinese mainland, OceanBase Database V4.2.5 supports the hkscs and hkscs31 character sets of Oracle. It also supports the Japanese character set SJIS along with UTF16LE, DEC8, and BIG5 in MySQL, as well as their associated collations. Moreover, it supports Unicode Collation Algorithm (UCA) collations for UTF8 and UTF16, and collations related to UCA 9.0.

Compatibility with Oracle

• 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.2.5 supports the RELEASE and REQUEST(release_on_commit = FALSE) subprograms for manually releasing locks and requesting session-level locks.

• Quick column dropping

  In OceanBase Database V4.2.5, dropping a column marks it as deleted instead of physically removing it, significantly improving performance. Dropped columns are stored as hidden columns. If frequent drops accumulate 128 or more hidden columns in a business system, further column additions or deletions on the table are blocked. To resolve this, you need to execute the ALTER TABLE FORCE statement to clear the hidden columns. During the clearing process, the table is locked and the data is reorganized, which blocks other transactions.

• Support for complex parameter types in remote stored procedure calls between Oracle-compatible modes

  OceanBase Database V4.2.4 supports remote stored procedure calls between Oracle-compatible tenants but only basic parameters are supported in the calls. OceanBase Database V4.2.5 supports complex parameter types and three nesting methods: record(basic), array(basic), and array(record(basic)).

OBKV enhancements

• Expired data deletion optimized for OBKV-HBase

  To improve the query performance in a scenario with hotspot keys, namely, a large amount of data of expired versions is accumulated within a short period of time, OceanBase Database V4.2.5 optimizes the expired data deletion feature. It measures HBase rowkeys with an expired time-to-live (TTL) or MaxVersion value when executing HBase queries and quickly generates a TTL-based deletion task to delete expired HBase rowkeys, so as to reduce the amount of data to be scanned during queries, thereby improving the query performance.

• ColumnPaginationFilter supported for OBKV-HBase

  The ColumnPaginationFilter filter is provided to limit the number of columns to return. You can use this filter to specify to return data of the latest version in the specified number of columns starting from a specific column. This filter is usually used in column pagination. To use this filter, you need to specify the offset and number of columns to return.

• Reverse scan supported for OBKV-HBase

  The new version supports the reverse scan feature. You can scan data in the table in the reversed order of rowkeys (from large to small). HBase data is sorted and stored by rowkey. Therefore, the reverse scan feature applies to scenarios where data needs to be accessed in descending order of rowkeys.

Client information views

OBKV supports the client/server access mode. In OBKV, data is accessed through RPC. It does not have the concept of session and cannot show client parameters in sessions. OceanBase Database V4.2.5 provides the [G]V$OB_KV_CLIENT_INFO views to display client information and the __all_virtual_kv_client_info table to record client parameters, such as the connection pool size, response timeout period, and number of retries upon failure. You can query the views for the configurations of the business client to improve troubleshooting efficiency.

• OBKV-HBase enhancement

  This version introduces the ColumnPaginationFilter, a filter designed to limit the number of returned columns. Starting from a specified column, it retrieves the latest version of a defined number of columns, making it particularly useful for column pagination. To use this filter, you must specify both the offset and the limit. Additionally, the Reverse Scan feature is now supported, enabling users to scan table data in reverse RowKey order (from largest to smallest), which is the opposite of the standard forward scan order (from smallest to largest). Since HBase stores data sorted by RowKey, the Reverse Scan feature is especially beneficial in scenarios where data needs to be accessed in descending RowKey order.

• OBKV-Redis model

  OBKV-Redis is a persistent database compatible with Redis APIs, designed to address the limitations of traditional Redis combined with relational database services (RDS). These limitations include the inability to ensure data consistency, complex architecture management, poor scalability, lack of transactional capabilities, and high O&M costs. OBKV-Redis integrates caching and database functionalities, storing hot data in memory and cold data on disk. It also provides transactional capabilities to ensure data consistency, meeting the RT and throughput requirements for 80% of user scenarios. OBKV-Redis is primarily compatible with native Redis 3.2, 4.0, and 5.0, supporting five basic data types: string, hash, list, set, and zset, as well as some common commands such as TTL, EXPIRE, and DEL.

OBKV performance optimization

The multi_set API of the storage layer is supported for multi-PUT operations. Batch data reads and conflict checks are supported to improve the batch import performance of OBKV. OceanBase Database V4.2.3 supports group commit. You can execute PUT or GET operations on the server in batches. This improves the performance of GET and PUT operations by 20% to 30%. OceanBase Database V4.2.5 optimizes the group commit feature. Apart from GET and PUT, group commit is also supported for INSERT, DELETE, REPLACE, UPDATE, INSERTUP, and INCREMENT/APPEND operations. Local indexes and global indexes are supported in group commit of the operations, except PUT. Operations are grouped by log stream instead of tablet and the request queue is transformed to a lock-free queue. This addresses performance issues incurred from frequent group locking in high concurrency scenarios. The batch size for group commit can be smoothly adjusted. The tenant-level parameters kv_group_commit_batch_size and kv_group_commit_rw_mode are added to respectively specify the batch size for group commit in OBKV and the operation types supported for group commit when the feature is enabled. The enable_kv_group_commit parameter is deprecated. The (G)V$OB_KV_GROUP_COMMIT_STATUS views related to group commit are provided to monitor the status information about each log stream group, such as the request queue size, batch size, number of log stream groups, and queue size of a failed group.

Performance improvements

• Table-level restore performance optimization

  The overall table-level restore process comprises three steps: (1) Restore an auxiliary tenant to the specified point in time based on the backup data; (2) Import the specified table from the auxiliary tenant to the destination tenant; (3) Clear the auxiliary tenant.

  In earlier versions, the task scheduling strategy in the table import task scheduler enforces serial execution of multiple table import tasks. The degree of parallelism (DOP) is low in the data completion and index creation phases of the primary table. To improve the table-level restore performance, the new version optimizes the parallelism in the following aspects:

  1. The tenant parameter recover_table_concurrency is provided to control the maximum number of table import tasks (up to K) that can execute simultaneously, enhancing the parallelism of multi-table imports.
  2. Table-level recovery parallel control parameters provided by DDL are leveraged to increase the concurrency of index creation.

• Upgrade process optimization

  OceanBase Database V4.2.5 optimizes the upgrade process to improve the post-upgrade performance. Batch upgrade is supported for system variables, system tables, and virtual tables (views), and unnecessary schema refresh operations are reduced. After these optimizations, the average upgrade time per tenant is approximately one-tenth of what it was before.

• DML performance optimization

  The new version supports batch processing of the INSERT ... VALUES ... ON DUPLICATE KEY UPDATE ... and REPLACE ... VALUES ... statements in multi-query scenarios to improve the DML execution performance. When you execute the MERGE INTO statement on a table with a unique key, parallel DML (PDML) is supported to improve the execution efficiency in scenarios with large amounts of data.

Resource optimization

• DDL resource isolation

  DDL requests occupy worker threads and share thread resources with DML requests and query requests. In this case, resource contention may occur. If a large number of DDL requests are initiated at a point in time, normal business requests may be affected. After parallel DDL is introduced, the tenant may face higher DDL pressure. OceanBase Database V4.2.5 isolates worker threads used by DDL operations from other requests, and provisions additional worker threads when DDL synchronization is pending. This ensures that sufficient worker threads are available for other tasks during heavy DDL workloads, thereby improving system stability.

• Resource isolation for statistics collection and clog commit

  In a high-performance computing environment, reasonable resource allocation and isolation are decisive in ensuring system stability and improving efficiency. An effective resource isolation strategy can prevent resource contention and interference between tasks, thereby improving the resource utilization efficiency and overall service quality. In earlier versions, you can configure different unit configs for tenants to implement resource isolation between the tenants, and use the resource manager to configure resource isolation within a tenant. Resource isolation is supported for CPU and I/O resources. To reduce the impact of background tasks on user requests, resource isolation is required for background tasks, and has been supported for most background tasks. The new version supports resource isolation for statistics collection and clog commit to further enhance the resource isolation mechanism and reduce the impact of background tasks on user requests. In terms of I/O resource isolation, three parameters MIN_IOPS, MAX_IOPS, and WEIGHT_IOPS are provided for respectively specifying the minimum IOPS, maximum IOPS, and IOPS weight. According to the I/O resource scheduling strategy, the database guarantees resources to meet the minimum IOPS, and schedules resources based on the IOPS weight while ensuring that the maximum IOPS is not exceeded. The resource isolation strategy is described as follows:

  1. Set the MAX_IOPS parameter to 10 for clog commit, which means that a maximum of 10% IOPS resources can be used for committing clogs.
  2. Set the MAX_IOPS parameter to 20 for statistics collection, which means that a maximum of 20% IOPS resources can be used for collecting statistics.
  3. Limit the IOPS weight for foreground tasks and statistics collection. Specifically, set the default WEIGHT_IOPS value to 100 for foreground tasks, and to 20 for statistics collection. According to the weight-based scheduling strategy, the bandwidth resources for foreground tasks and those for statistics collection conform to the ratio 5:1.

  OceanBase Database provides a default isolation template to simplify resource isolation configuration. Background resource isolation is supported for CPU and I/O resources. The control group (cgroup) feature is required for CPU resource isolation, and is optional for I/O resource isolation.

• Memory limits for SQL queries

  OceanBase Database can track the memory usage of individual SQL queries and take actions, such as returning an error to the client or logging a warning, when the memory usage exceeds the specified threshold. To ensure overall system stability in scenarios of large queries or nonoptimal plans, make sure that a single SQL query does not occupy excessive memory resources. The tenant-level parameter query_memory_limit_percentage is provided to specify the maximum percentage of memory in the tenant available for a single SQL query. When the memory usage reaches the specified threshold, the SQL query is interrupted with an error returned.

• Memory optimization for stored procedures

  OceanBase Database V4.2.5 replaces the general memory allocator used for stored procedures with a custom memory allocator, which implements proactive memory release and shortens the memory lifecycle of stored procedures. The new version also optimizes the design of the symbol table, memory usage of basic data types, memory management for complex data types such as RECORD and ARRAY, and memory management for expressions. This addresses the issue of memory accumulation in various scenarios, and improves the memory usage stability of stored procedures and the calculation performance of some expressions.

Reliability improvements

• Migration of active transactions during tablet transfer

  In the design of standalone log streams, data is in the unit of tablets, while logs are in the unit of log streams. Multiple tablets are aggregated into one log stream, saving the high cost of two-phase commit of transactions within a single log stream. To balance data and traffic among different log streams, tablets can be flexibly transferred between log streams. However, during the tablet transfer process, active transactions may still be handling the data, and even a simple operation may damage the atomicity, consistency, isolation, and durability (ACID) of the transactions. For example, if active transaction data on the transfer source cannot be completely migrated to the transfer destination during concurrent transaction execution, the atomicity of the transactions cannot be guaranteed. In earlier versions, active transactions were killed during the transfer to prevent transaction problems. This mechanism affects the normal execution of transactions to some extent. To resolve this problem, the new version supports the migration of active transactions during tablet transfer, which enables concurrent execution of active transactions and ensures that no abnormal rollbacks or consistency issues occur in concurrent transactions due to the transfer.

• Adaptive arbitration upgrade or downgrade based on the I/O load

  The arbitration service provides an algorithm for detecting faults on log disks based on the I/O load, which can effectively detect cloud disk faults and perform arbitration downgrade to prevent cloud disk faults from continuously affecting business requests. Specifically, the fault detection algorithm continuously monitors the write performance of a log disk. If the write performance of the log disk decreases to a value (specified by a parameter) that is significantly lower than the baseline, the algorithm marks the log disk as faulty and performs arbitration downgrade. The algorithm continues monitoring the log disk performance after marking the log disk as faulty, and marks the log disk as normal when the performance recovers to the normal range. This way, business requests submitted after the arbitration upgrade are not affected by log disk faults. The cluster-level parameter log_storage_warning_trigger_percentage is provided for specifying the write performance threshold in percentage for triggering a log disk fault.

• Backup support for parameters and tenant resource configurations

  V4.2.5 introduces support for backing up both cluster-level and tenant-level parameters. Cluster-level parameters can be backed up separately by specifying the path information using the ALTER SYSTEM command. Tenant-level parameters are included in the backup data set and are backed up automatically during data backup. When performing tenant-level physical recovery, it is recommended that the target tenant's resource configuration matches that of the source tenant to ensure a higher success rate for physical recovery and maintain the stability of subsequent production operations. To assist with configuring resources for the target tenant, V4.2.5 also supports backing up the resource configuration and replica distribution information of the tenant.

Usability improvements

• Parallel log stream replica migration optimization

  In earlier versions, before RootService generates a load balancing task that needs to modify the paxos_replica_num parameter, such as data synchronization to replicas or replica deletion, RootService needs to wait for the previous member change task in the log stream to be completed and obtain the accurate paxos_replica_num value. In other words, multiple replica tasks, such as replica migration, in the same log stream can only be executed in serial. The serial execution limitation results in low efficiency of some load balancing tasks and O&M operations. For example, if you migrate two units in two zones at the same time, the two replicas of the same log stream in the two units must be migrated in order rather than in parallel. Since V4.2.5, replicas of the same log stream in different zones can be migrated in parallel. This can accelerate scaling, improve load balancing efficiency, and reduce the probability of replica rebuilding for the standby tenant. The primary tenant requires parallel log stream replica migration to accelerate scaling in proof of concept (POC) scenarios. It may not enable parallel migration in regular scenarios. This is because a large amount of data needs to be replicated during parallel replica migration, which may compromise the I/O performance of the leader. The standby tenant requires parallel replica migration to effectively reduce the probability of replica rebuilding. The tenant-level parameter replica_parallel_migration_mode is provided for controlling the parallel migration mode for log stream replicas.

• Row lock wait and retry wait events provided in the ASH diagnostic module

  When row lock contention occurs, multiple sessions may be blocked, compromising the system performance. In earlier versions, you can query the V$OB_LOCKS and V$OB_TRANSACTION_PARTICIPANTS views for troubleshooting when row lock contention occurs. The ASH diagnostic module provides row lock wait time statistics and implements a wait loop based on session blocking to implement performance diagnostics for the row lock link. The ASH diagnostic module also provides retry wait event statistics and categorizes wait events into the LOCATION, SCHEMA, SQL, STORAGE, TX, and Other classes.

• Response time histograms

  OceanBase Database of earlier versions provide statistics on the average response time and maximum response time in different SQL categories, which lack fine-grained statistics that reflect the SQL execution performance at a specific percentile. OceanBase Database V4.2.5 provides response time histograms. You can query and monitor response time statistics of a specific SQL type at a specific percentile, such as P90 or P95, based on the [G]V$OB_QUERY_RESPONSE_TIME_HISTOGRAM view.

• Statistics monitoring optimization

  OceanBase Database V4.2.5 restructures the statistics monitoring framework. The new framework records all diagnostic data generated during database execution and stores the data in an appropriate form. You can query the data from different dimensions, such as tenants, groups, and sessions. The memory and CPU overheads of the framework are controlled at an appropriate level to avoid blocking or affecting regular database tasks. In the new framework, after a session is disconnected, the corresponding wait events and statistical items can no longer be queried from diagnostic views. Diagnostic data that only reflects the internal running situation is no longer recorded to avoid confusing customers. Apart from tenant-level and session-level statistical views, group-level statistical views are provided to help you better monitor diagnostic data in resource isolation scenarios.

• Log synchronization link optimization

  OceanBase Database V4.2.5 provides the GV$OB_LOG_TRANSPORT_DEST_STAT and V$OB_LOG_TRANSPORT_DEST_STAT views related to log transmission links to facilitate observation and monitoring. You can query the views in the following scenarios:

  1. Observe the number of log synchronization links and the traffic in the downstream systems of the primary tenant, and take actions when the read I/Os in the log synchronization links affect the write I/Os of the primary tenant.
  2. When a specific log synchronization link with a slow progress is detected, you can query the views to check whether the RPC processing time is as expected and determine whether the log synchronization link is normal based on the check result.

• System log optimization

  The ./alert/alert.log file is added to the system log directory to record log information concerned by DBAs. This log file can help resolve the issue where the observer.log file has poor readability because it contains a large volume of logs. You can use the cluster-level parameter alert_log_level to set the log level to INFO, WARN, or ERROR.

• Dynamic modification of memory specifications for OBServer nodes

  Memory specification modification for OBServer nodes takes effect upon a restart in earlier versions, and in real time in the new version, which improves the elastic scaling capability.

• Improvement of the SHOW PROCESSLIST command

  The SHOW PROCESSLIST command shows the status information about the nodes of a tenant. The virtual tables and views related to the SHOW PROCESSLIST command are reconstructed. The total_time column indicates the total request time, which starts from when a request is received to when a response is returned to the client. If no request is received, the total_time column indicates the duration of the current status. The total_cpu_time column is provided to describe the duration of a request remaining in the active state in a session. The remote execution status and information are also improved. With these improvements, the semantics of time-related columns are clearer and more scenarios are covered.

• SPM evolution information stored on the disk and import or export of baselines

  To better monitor SPM execution, OceanBase Database V4.2.5 provides the DBA_OB_SPM_EVO_RESULT view for recording detail results of SPM evolution tasks. You can call stored procedures in the DBMS_SPM package to import and export SPM baselines based on intermediate tables. Specifically, you can call DBMS_SPM.CREATE_STGTAB_BASELINES to create a baseline cache table, call DBMS_SPM.PACK_STGTAB_BASELINES to export baselines to the cache table, and call DBMS_SPM.UNPACK_STGTAB_BASELINES to import baselines from the cache table. To facilitate migration across tenants, the new version also allows you to import and export baselines by using CSV files. Specifically, you can call DBMS_SPM.PACK_CSV_BASELINES to export baselines to a CSV file and call DBMS_SPM.UNPACK_CSV_BASELINES to import baselines from a CSV file.

Compatibility changes

Product behavior changes

View changes

Parameter changes

System variable changes

System package changes

Syntax changes

Recommended versions of tools

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

Upgrade notes

• If your cluster contains a large number of tablets, it takes much time to restart OBServer nodes during the upgrade. It takes about 20 minutes to restart OBServer nodes if the cluster contains more than 3 million tablets. If a large number of tablets are involved, you need to reserve sufficient time for the upgrade.
• Only OceanBase Database V4.2.1 BP2 and earlier can be upgraded to V4.2.5. OceanBase Database V4.2.1 BP3 and later cannot be upgraded to V4.2.5. Support for upgrading from all V4.2.1 BP versions is expected in V4.2.5 BP1. Pay special attention to the upgrade path.
• V4.2.2.1 is a barrier version for V4.2.2.0. To upgrade OceanBase Database from V4.2.2.0 to a future later version, you need to upgrade OceanBase Database to V4.2.2.1 first.
• You can directly upgrade OceanBase Database from a version of the V4.2.3 or 4.2.4 series to V4.2.5.
• To upgrade ODP and OBServer nodes, we recommend that you first upgrade OBServer nodes to OceanBase Database V4.2.5 and then upgrade ODP to V4.3.2.
• Major compactions and DDL operations are prohibited during the upgrade.