OceanBase Database Enterprise Edition V4.2.1

V4.2.1 BP11 Hotfix6

Version information

• Release date: July 22, 2025
• Version: V4.2.1 BP11 Hotfix6
• RPM number: oceanbase-4.2.1.11-111060012025071816

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where executing SEQUENCE RESTART DDL operations during primary-standby switchover could lead to duplicate sequence values.
• Fixed an issue with libobclient where using a question mark in the prepared statement (PS) to specify output parameters was unsupported, causing problems with output parameter return packets.
• Fixed an issue that could cause a 4067 error during high concurrency of remote execution and remote LOB column queries when tenant CPU specifications are high, system load is significant, or there are bottlenecks in network I/O.
• Optimized the performance of TRUNCATE partitioning when there are a large number of records in the __all_table_history table.

V4.2.1 BP11 Hotfix5

Version information

• Release date: July 15, 2025
• Version: V4.2.1 BP11 Hotfix5
• RPM number: oceanbase-4.2.1.11-111050022025071110

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where the values of "Number of Transaction Lock Waits" and "Average Transaction Lock Wait Time" in the GV$SYSSTAT view were always 0.
• Fixed the issue where, in specific scenarios (such as incremental write operations), the merged minor compaction could prevent reuse of macroblocks, thereby increasing I/O and CPU usage.
• Fixed the issue where, in distributed routing scenarios, transactions could not be killed in a timely manner when a deadlock occurred on a temporary node, and deadlocks could not be detected in PL local retry scenarios.
• Fixed the issue where, when using the UTF-8 binary character set with a text type parameter, the result set might be incorrect in the in(a,b) scenario.
• Fixed the issue where, when a partition with a global index was being dropped, concurrent data writes to other partitions could cause log replay to halt or OBCDC to crash.
• Improved the accuracy of row count estimation in specific scenarios to avoid execution plans that deviate from the expected ones and incorrect index selection.
• Fixed the issue where, when a native Oracle DBLink connection was disconnected, network issues could cause the DBLink connection pool to be locked, potentially leading to blocked threads, exhausted resources, backed-up queues, and tenant unavailability.
• Fixed the issue where, when using array binding for execution, the JDBC driver would perform a row conversion from timestamp to date type on the first execution, leading to errors in identifying the actual timestamp type when reusing the plan.
• Fixed the issue where, in specific SQL scenarios, the generation of non-constant shared expressions could lead to a core dump during semi/anti join pushdown.
• Fixed the issue where, in Oracle-compatible mode, INSERT ALL did not perform user INSERT privilege checks, potentially allowing unauthorized data insertion.
• Fixed the issue where, in Oracle-compatible mode, CHAR columns with default values that included leading or trailing spaces could result in a false report of error 4103 when an index was created on the column.
• Fixed a kernel statistics error that could lead to a significant increase in OBKV latency.
• Fixed the issue where, when the internal precision of a DOUBLE value was very long (and the value could not be accurately represented), an error could occur when writing it to a VARCHAR column with a length limit.
• Fixed the issue where, in UDF precomputation scenarios, setting the nest_count value had type limitations, and an error would be reported if nest_count did not meet expectations during execution.
• Fixed the issue where, when restoring data using the plus archivelog mode, the specified restore point could not be reached when using the time=xxx method.

V4.2.1 BP11 Hotfix4

Version information

• Release date: June 12, 2025
• Version: V4.2.1 BP11 Hotfix4
• RPM number: oceanbase-4.2.1.11-111040032025061010

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where a memory leak occurs in a tenant when an execution plan uses a temporary table to extract a common table expression (CTE) containing more than 900,000 rows.
• Fixed the memory leak issue that arises when five or more tables are involved in left-to-anti/group by pushdown/join elimination rewriting or relevant hints.
• Fixed the issue where, during a connection with useArrayBinding=true, an update statement is executed. If the SQL statement does not contain bound parameters but specific values, the server does not send any content to the client, causing the client to hang.
• Fixed the issue where the query result is incorrect when the same table is present on both sides of a semi join without a direct join condition, while both sides have equivalent unique key conditions.
• Fixed the issue where the query result may be incorrect if rownum=1 is in the query conditions and the query can trigger view merging.
• Fixed the issue where, when executing DDL operations in PL, if the error code -4023 is triggered, automatic retries cannot occur, and the error code is returned to the application layer.
• Fixed the issue where, after an account is locked, if the time required to reach the connection_control_min_connection_delay threshold has not elapsed, the user cannot log in with the correct password.
• Fixed the issue where, if tenant memory usage remains at the tenant memory limit, automatic memory management will always set the minimum memory bound, leading to unexpected disk writes in the cluster and causing execution timeouts.
• Fixed the issue where, after direct load or offline DDL operations, the table_prefs statistics configuration item becomes empty.
• Fixed the issue where user variables defined in an SQL statement cannot hit the plan when the SQL statement is executed for the first time in the session.
• Fixed the issue where, in poor network conditions, updates to information data face bottlenecks, failing to complete read/write switching within one second, ultimately leading to incomplete migration and prohibiting writes during read/write switching, causing write jitter in the business.
• Fixed the issue where, in special scenarios, incorrect trimming of spaces leads to a zero-sized space, causing a thread to enter a deadlock and preventing the merge from completing.
• Fixed the issue where, when using multi-statement queries, even if retrying with single statements also fails, the connection is disconnected.
• Fixed the issue where, if a table contains a function-based index, executing SHOW CREATE TABLE will result in a syntax error due to missing parentheses, leading to a chain execution error.
• Fixed the issue where, if a table has many indexes, querying the execution plan of statements containing the table in the GV$OB_PLAN_CACHE_PLAN_EXPLAIN view will result in an error code 4016 due to insufficient length of the property field.
• Fixed the issue where, in specific scenarios, data that is backed up and restored may become unavailable after migration.
• Fixed the issue where, if migration kills transactions are enabled and concurrent active transactions are writing at the source, there is a low probability of migration being stuck.
• Fixed the issue where, in specific scenarios, if light_backtrace is called in the library function context, a coredump may occur.
• Fixed the issue where the cast(question_mark as udt) scenario might result in an error.
• Fixed the issue where, in specific scenarios after migration, querying the corresponding partition in the destination log stream may not find the transaction status, potentially leading to query errors or affecting read and write operations.
• Fixed the issue where a core dump may occur during the exit process of the observer in specific scenarios.

V4.2.1 BP11 Hotfix3

Version information

• Release date: May 20, 2025
• Version: V4.2.1 BP11 Hotfix3
• RPM number: oceanbase-4.2.1.11-111030012025051713

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where using multi-statement queries results in an error, and retrying with single statements also fails, leading to disconnection.

V4.2.1 BP11 Hotfix2

Version information

• Release date: May 15, 2025
• Version: V4.2.1 BP11 Hotfix2
• RPM number: oceanbase-4.2.1.11-111020032025051316

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where executing multiple PL statements in specific scenarios can cause a stack overflow with error code 4019, and excessively long PL text can lead to a core dump.
• Fixed the issue where query range extraction for LIKE expressions with non-precise matching can result in incorrect results in specific scenarios.
• Fixed the issue where using dictionary encoding in an ARM environment may result in NULL values not being filtered when pushed down to baseline microblocks in specific scenarios.
• Fixed the issue where queries that limit results using ROWNUM, especially when the lower bound is greater than or equal to 0, can lead to incorrect results.
• Fixed the issue where a core dump may occur if a UNION ALL statement contains constant values exceeding 128 items, and the IN clause contains more than 1,000 constants.
• Fixed the issue where a core dump may occur when multiple prepared statements are executed concurrently, which can trigger a key-value cache wash.
• Fixed the issue where a core dump may occur if the defined column count of a package changes concurrently to object type in specific scenarios.
• Fixed the issue where a core dump or an incomplete DDL operation may occur if the length of index_key exactly matches the allocated buffer length.
• Adjusted the default value of weak_read_refresh_interval from 100 ms to 500 ms (effective only for new clusters in V4.2.1) to optimize the internal table __all_weak_read_service (table_id 226), which triggers minor compactions due to excessive UPDATE operations on the same row, leading to memory bloat.
• Fixed the issue where the to_base64 function for LOB types raises error code 4016 when processing an empty string.
• Fixed the issue where error code OBE-00932 is reported during validation if a user-defined type (UDT) variable appears in a CAST function within a PL-updated view in a GBK tenant.
• Fixed the issue where an error is reported if a view being updated with PL contains an ORDER BY column not included in the SELECT clause.

V4.2.1 BP11 Hotfix1

Version information

• Release date: April 15, 2025
• Version: V4.2.1 BP11 Hotfix1
• RPM number: oceanbase-4.2.1.11-111010032025041110

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where, in specific constraint scenarios, two consecutive constraints evaluating to true in a plan could cause an incorrect plan to be matched from the plan cache, resulting in wrong results.
• Fixed the issue where, when _enable_enhanced_cursor_validation is enabled, if a transaction has opened at least eight tables before the cursor is opened, and the cursor needs to access the eighth table or later, the cursor will not see the modifications made by the current transaction to those tables.
• Fixed the issue where, in the same session, modifying a package variable of type object and then concurrently changing its column definition during the synchronization phase may lead to a core dump.
• Fixed the issue where a public synonym becomes invisible if there is an object with the same name, causing PL cache misses and requiring recompilation for each execution, which is slow.
• Fixed the issue where the clause TTL = (\create_time` + INTERVAL 30 DAY)` in the CREATE TABLE statement may mistakenly delete data that has not expired due to the create_time column being enclosed in backticks.
• Fixed the issue where exceeding an I/O bandwidth of 1.5 GB may cause I/O calibration data to be underestimated, reducing the effectiveness of I/O isolation.

V4.2.1 BP11

Version information

• Release date: March 28, 2024
• Version: V4.2.1 BP11
• RPM number: oceanbase-4.2.1.11-111000052025032520

Upgrade notes

• You can upgrade to this version from V4.1.0 BP1-BP4, V4.2.0 GA, V4.2.0 BP1, V4.2.1 GA, and V4.2.1 BP1-BP10.
• During the upgrade from V4.2.1 GA/hotfix versions to V4.2.1 BP11, jobs cannot be created while both the old and new versions are running at the same time.

Feature enhancements and stability improvements

• Support for specifying backup/archiving sources

  OceanBase clusters are commonly deployed in configurations such as three IDCs within the same region, three IDCs across two regions, or five IDCs across three regions. In these configurations, cross-IDC and cross-region network bandwidth is often more limited compared to local bandwidth. Database backup processes generate significant network traffic. To control the impact on these scarce network resources, the new version introduces options to configure paths for data backup and log archiving. By specifying the zones, IDCs, and regions accessible to the backup/archiving paths, you can define the range of nodes used for data backup and archiving.

• Pre-expansion

  This release introduced the concept of an expansion factor, which defines the number of log streams to be split from each existing log stream, and provides new log stream maintenance commands to modify their location and primary zone information, laying the groundwork for future scaling.

Syntax changes

Bug fixes

• Fixed the issue where, in specific execution plan scenarios, a large intermediate result set caused high disk usage when a Cartesian product without equivalent join conditions was involved in a GROUP BY operation.
• Fixed the issue where, during protocol processing for the dual protocol, unexpected errors occurred due to the lack of session variable synchronization, resulting in the use of outdated session variables.
• Fixed the issue where excessive recursion during PL compilation could result in a core dump in special scenarios.
• Fixed the issue where using a generated column as the partitioning key for a LIST partition, with a filter that depends on the original column, could result in error 4016 due to partition pruning.
• Fixed the issue where a partitioned table with more than 128 columns would return error 4016 when using the default statistics collection parameters.
• Fixed the issue where error 4016 would be returned when using the win magic rewrite feature for SQL statements of the MERGE INTO type.
• Fixed the issue where the use of aggregate functions like wm_concat that temporarily store data could lead to memory exhaustion and error 4013.
• Fixed the issue where casting a TINYINT to a signed integer should result in a BIGINT, but was unexpectedly cast to TINYINT.

V4.2.1 BP10 Hotfix6

Version information

• Release date: February 28, 2025
• Version: V4.2.1 BP10 Hotfix6
• RPM number: oceanbase-4.2.1.10-110060022025022409

Overview

This release fixed issues reported by customers and enhances the stability of the version.

Bug fixes

• Fixed the issue where a core dump could occur during the processing of SQL hints by the lexer when memory allocation fails.
• Fixed the issue where a core dump could occur in query statements containing duplicate aggregate functions and involving implicit type conversion.
• Fixed the issue where the sequence step could become abnormal due to non-deterministic UDF variable assignments when the _enable_var_assign_use_das option is enabled.
• Fixed the issue where the optimizer thread hangs and cannot be terminated via KILL SESSION during execution plan generation when join conditions contain redundant equality conditions in multi-table queries.
• Fixed the issue where the semantic analyzer and query rewriter threads are blocked and cannot be terminated via KILL SESSION when a query statement contains an extremely large IN clause.
• Fixed the issue where session variables are not correctly rolled back to the default values of global system variables after executing the RESET CONNECTION statement.
• Fixed the issue where table deletion operations are blocked due to accidental deletion of associated constraints when dropping a unique constraint in Oracle-compatible mode.
• Fixed the issue where a core dump could occur during batch processing of foreign key constraints.
• Fixed the issue where a core dump could occur during join elimination in large-scale join queries (more than 1,000 tables) when using the optimizer.
• Fixed the issue where a core dump could occur due to ORDER BY clause rewrite logic in specific scenarios.
• Fixed the issue where insufficient serialization buffer capacity could cause a core dump.
• Fixed the issue where the UNPIVOT operation in distributed execution plans could trigger error 4016.
• Fixed the issue where an invalid SQL statement is generated when a partition name consists only of numbers in dynamic sampling for partitioned tables, causing error 4016.
• Fixed the issue where a FETCH statement could trigger error 4002 after a RETURN statement.
• Fixed the issue in Oracle-compatible mode where, after dropping a primary key constraint, the NULL attribute of the original primary key column fails to update and NULL values cannot be inserted.
• Fixed the issue where startup (bootstrap) of a new cluster fails if the IP address and RPC port of an observer node in the old cluster are reused and some observer nodes in the old cluster are still running.
• Fixed the issue where the dependency relationship table is not updated synchronously after a PL object’s dependent table is renamed.

V4.2.1 BP10 Hotfix5

Version information

• Release date: January 22, 2025
• Version: V4.2.1 BP10 Hotfix5
• RPM number: oceanbase-4.2.1.10-110050012025011614

Bug fixes

• Fixed the issue where executing RESET CONNECTION could cause memory accumulation.
• Fixed the issue where using the IN condition to filter JSON fields could produce incorrect results in specific scenarios.
• Fixed the issue where incorrect pruning in specific ORDER BY UNION statements could lead to a core dump.
• Fixed the issue where merging and rewriting subqueries in specific UPDATE SET statements could lead to a core dump when shared subquery expressions exist.
• Fixed the issue where optimizer strategy adjustments could prevent the selection of a covering index in some scenarios.

V4.2.1 BP10 Hotfix4

Version information

• Release date: December 25, 2024
• Version: V4.2.1 BP10 Hotfix4
• RPM number: oceanbase-4.2.1.10-110040012024122218

Bug fixes

• Fixed the issue where exceeding the tenant_id limit could cause the system to become unavailable.
• Fixed the issue where altering a sequence in PL required recompilation.
• Fixed the issue where queries could return incorrect results when outer joins and certain complex filter predicates are present.
• Fixed the issue where an error occurs when using dbms_session with the GB18030 character set.

V4.2.1 BP10 Hotfix2

Version information

• Release date: December 5, 2024
• Version: V4.2.1 BP10 Hotfix2
• RPM number: oceanbase-4.2.1.10-110020012024120420

Bug fixes

• Fixed the issue where query and write performance drops under heavy write load in some scenarios.
• Fixed the issue where stored procedures report error code 4002 in specific character set scenarios.
• Fixed the issue where dynamic sampling leads to inaccurate row count estimation in some scenarios.
• Fixed the issue where LIKE expressions produce incorrect results in specific character set scenarios.
• Fixed the issue where local index row estimation is excessively low in partitioned table scenarios.
• Fixed the issue where resources are not released after unit migration in specific scenarios.
• Fixed the issue where error code 14037 is reported when creating specific partitioned tables.
• Fixed the issue where the system hangs during major compactions caused by parallel unique index creation.

V4.2.1 BP10

Version information

• Release date: November 15, 2024
• Version: V4.2.1 BP10
• RPM number: oceanbase-4.2.1.10-110000072024111216

Upgrade notes

• You can upgrade to this version from V4.1.0 BP1-BP4, V4.2.0 GA, V4.2.0 BP1, V4.2.1 GA, and V4.2.1 BP1-BP9.
• During the upgrade from V4.2.1 GA/hotfix versions to V4.2.1 BP10, jobs cannot be created while both the old and new versions are running at the same time.

Feature enhancements

• Backup configuration items

  Users also expect to back up source cluster-level and tenant-level parameters during data backup to enable quick restoration of cluster and tenant states. The new version supports backing up cluster-level parameters to a specified path using the ALTER SYSTEM BACKUP CLUSTER PARAMETERS TO 'xxxx' command, and also allows including tenant parameters in the backup dataset. Additionally, the ob_admin tool provides the dump_backup command to view information about backed-up parameters.

• Backup tenant resource configuration information

  To avoid business disruptions, it is recommended that the resource parameters of the target tenant during physical restoration match those of the source tenant. The new version supports backing up tenant resource-related parameters in the backup dataset, including specifications such as primary_zone, unit_num, locality, and unit config, facilitating restoration of tenants with equivalent specifications.

• Optimization of archived standby database latency

  In cross-cloud disaster recovery architectures, the latency of archived standby databases can now be reduced to within 1 second.

• Hot partition diagnosis using ASH

  If there are no abnormally slow SQL queries but a node has high CPU load, a hot partition issue may exist. The new version collects tablet_id information in ASH to help monitor hot partitions, facilitating subsequent O&M handling.

• Batch import of existing execution plans into SPM baselines

  OceanBase Database now supports importing execution plans from the cache into SPM baselines using sql_id. However, importing many plans individually can be cumbersome, so the new version includes the DBMS_SPM.BATCH_LOAD_PLANS_FROM_CURSOR_CACHE procedure for batch importing.

Product behavior changes

• The composite DDL operation that allows dropping and adding indexes in one DDL statement is disabled.

  Starting from V2.x, OceanBase Database supports a composite DDL operation that allows dropping and adding indexes in one statement. However, this operation is not atomic, which can result in a period during which no indexes are available. To mitigate the business risk, this composite DDL operation is currently disabled. If you need to use this feature, ensure you understand the implementation logic and set the _enable_drop_and_add_index parameter to true.

System variable changes

View changes

Bug fixes

• FFixed the issue where Truncate operations could occasionally take a long time during batch runs.
• Fixed the issue where JSON indexes could not be used to accelerate queries in some scenarios.
• Fixed the core dump issue when using OSS backup with higher versions of glibc.
• Fixed the issue where statistics collection in some scenarios caused disk space to increase.
• Fixed the issue where index selection was suboptimal in specific cases.
• Fixed the issue where a size overflow error occurred when the primary zone was excessively long.
• Fixed the issue where SPM selected poor execution plans in special scenarios.
• Fixed the issue where JDBC batch sending of LOB data could lead to coredump.

V4.2.1 BP9 Hotfix2

Version information

• Release date: October 25, 2024
• Version: V4.2.1 BP9 Hotfix2
• RPM number: oceanbase-4.2.1.9-109020012024102319

Bug fixes

Fixed the issue where the IFNULL function's return type for type promotion was inconsistent with MySQL.

V4.2.1 BP9 Hotfix1

Version information

• Release date: October 12, 2024
• Version: V4.2.1 BP9 Hotfix1
• RPM number: oceanbase-4.2.1.9-109010022024101120

Bug fixes

• Fixed the issue where the ob_admin check_exist command did not take effect during backup and restore, which caused the tenant_backup_set_infos.obbak file to fail to dump.

V4.2.1 BP9

Version information

• Release date: September 20, 2024
• Version: V4.2.1 BP9
• RPM number: oceanbase-4.2.1.9-109000092024091919

Upgrade notes

• You can upgrade to this version from V4.1.0 BP1-BP4, V4.2.0 GA, V4.2.0 BP1, V4.2.1 GA, and V4.2.1 BP1-BP8.
• During the upgrade from V4.2.1 GA/hotfix versions to V4.2.1 BP9, jobs cannot be created while both the old and new versions are running at the same time.

Feature enhancements

• Automatic routing for primary and standby databases

  OceanBase Database V2.x and V3.x support cluster-level primary and standby databases, using CLUSTER_NAME as the unique identifier for a group of primary and standby clusters. When connecting to OceanBase Database through ODP, you can automatically route to the primary cluster by specifying the cluster name. Starting from V4.x, OceanBase Database supports tenant-level primary and standby databases. The primary tenant does not record information about the standby tenant, and the standby tenant does not record information about the primary tenant. The primary-standby relationship is maintained by external tools such as OCP, so you cannot automatically route to the primary tenant when connecting through ODP. The new version introduces the SERVICE_NAME concept for managing a group of primary and standby tenants. You can log in to the primary tenant by specifying SERVICE_NAME through ODP, for example: obclient -h $ip -P $port -u$user_name@SERVICE:$service_name. ODP can route the connection to the primary tenant based on SERVICE_NAME, meeting the automatic routing requirements for OceanBase Database V4.x. Additionally, a set of SERVICE_NAME management commands is provided in the sys tenant for creating, deleting, starting, and stopping SERVICE_NAME.

  This feature requires ODP V4.3.1 and OCP V4.3.1 or later.

• Scheduled or manual partition balancing

  OceanBase Database V4.2 supports partition balancing based on the Transfer feature. The tenant-level parameter partition_balance_schedule_interval controls the scheduling interval for balancing tasks. By default, a balancing task is scheduled every 2 hours, starting from the OBServer startup time. However, this parameter is not user-friendly and does not allow precise control over the execution time of partition balancing tasks. Transfer operations may block read and write access to the affected partitions, so performing partition balancing during peak hours may impact response time (RT). If many partitions need to be balanced, this may also temporarily increase cluster load and affect overall performance. To optimize this scenario, the new version provides the DBMS_BALANCE system package, which allows you to manually trigger partition balancing using the method DBMS_BALANCE.TRIGGER_PARTITION_BALANCE(balance_timeout). Additionally, a scheduled partition balancing task, SCHEDULED_TRIGGER_PARTITION_BALANCE, is automatically created for each user tenant and triggers partition balancing daily at 00:00 by default. You can modify the scheduled time, frequency, and other settings of the task using the DBMS_SCHEDULER subprogram according to your business needs, enabling flexible and reliable management of partition balancing tasks.

• Statistics collection for function-based indexes

  In earlier versions, statistics were not collected for function-based indexes, which could prevent the optimizer from choosing execution plans that use these indexes in some scenarios, resulting in suboptimal performance. The new version supports collecting statistics for function-based indexes.

• Performance optimization for multi-query Insertup and Replace statements

  The INSERT ... VALUES ... ON DUPLICATE KEY UPDATE ... and REPLACE ... VALUES ... statements now support batch processing in multi-query scenarios, improving DML execution performance.

• Support for the addressing_model parameter in S3 object storage access

  The new version supports the optional parameter addressing_model in S3 path configuration, with valid values virtual_hosted_style and path_style. If you set addressing_model=path_style in the S3 path, object storage is accessed using the path style addressing model. If you set addressing_model=virtual_hosted_style or do not specify the parameter, the virtual hosted style addressing model is used by default.

• Support for controlling the maximum number of rows returned by an SQL statement through the JDBC setMaxRows interface

  In Oracle-compatible mode, the JDBC setMaxRows interface is supported at the protocol layer to control the maximum number of rows returned after the execution of the original SQL statement.

• Storage-layer row estimation

  The optimizer supports row estimation based on statistics. However, this method can be insufficient in scenarios such as data skew, column correlation, or expired statistics. Inaccurate row estimation may lead to incorrect index selection and suboptimal execution plans. Therefore, in these cases, the optimizer uses storage-layer row estimation to directly obtain the relevant row count through index information, ensuring real-time and accurate results. Previously, storage-layer row estimation was not used for partitioned tables or when the number of extracted ranges exceeded 10. The new version relaxes some of these restrictions, allowing storage-layer row estimation in more scenarios for improved row count accuracy.

Product behavior changes

• Removal of job failure limit in DBMS_SCHEDULER

  In versions prior to V4.2.1 BP8, a periodic job would stop being scheduled after 16 consecutive failures. Starting from V4.2.1 BP9, this behavior has been aligned with Oracle: by default, max_failures is set to 0, meaning the job will continue to be scheduled regardless of the number of failures. If you want a job to stop scheduling after N failures, set max_failures to N. To resume scheduling for jobs that have stopped, you can use the DBMS_SCHEDULER.ENABLE procedure to reset their status. From V4.2.1 BP9 onward, it is important to pay closer attention to problematic jobs—resource-intensive jobs with high scheduling frequency may cause excessive resource usage.

• Default change: no longer actively collecting statistics for text columns

  Collecting statistics for large outrow LOBs is inefficient and can slow down the statistics collection process. The new version adjusts the strategy for text columns: if you manually specify statistics collection for text columns, it will be performed; otherwise, statistics for text columns are no longer collected by default. However, if function indexes exist on a text column, their statistics will be used for that column. If there are no function indexes but the column has been used, statistics will still be collected.

• Decoupling histogram collection from basic statistics collection

  Two new parameters, hist_est_percent and hist_block_sample, are added for statistics collection. These allow independent control of the histogram sampling ratio and whether block sampling is used.

Parameter changes

System variable changes

View changes

Bug fixes

• Fixed the issue where an SQL execution error was reported due to overly strict permission checks for UPDATE statements.
• Fixed the issue where the JSON_UNQUOTE function executed incorrectly due to parameterization problems with the JSON EXTRACT expression.
• Fixed the issue where an error was reported when using the outer table's * in an EXISTS subquery in MySQL-compatible mode.
• Fixed the issue where the LOCK TABLES statement was not supported in PL in Oracle-compatible mode.
• Fixed the issue where error -4007 was reported in specific anonymous block scenarios.
• Fixed the issue where hex strings were not supported in load data operations.
• Fixed the issue where concurrent direct load might affect tables that had already completed direct load.
• Fixed the issue where the ORDER BY clause produced unordered results in specific scenarios.
• Fixed the issue where the CREATE INDEX syntax for generated columns in Oracle tenant mode was inconsistent with native Oracle.
• Fixed the issue where poor baseline plans were used by SPM in specific scenarios.
• Fixed the issue where PL/SQL experienced a core dump in specific scenarios.
• Fixed the issue where table-level backup and restore operations were stuck in specific scenarios.
• Fixed the issue where results were incorrect when ROWNUM was used as an execution parameter in some scenarios.
• Fixed the issue where the result of PARTITION BY ROUND did not meet expectations.
• Fixed the issue where error -4016 was reported in specific merge join scenarios.
• Fixed the issue where error codes were lost during reverse scan in specific scenarios.
• Fixed the issue where, when executing DBMS_SCHEDULER.CREATE_JOB, if end_date was set to NULL or more than 100 years, the end_date viewed in the DBA_SCHEDULER_JOBS view did not meet expectations.

V4.2.1 BP8 Hotfix1

Version information

• Release date: August 28, 2024
• Version: V4.2.1 BP8 Hotfix1
• RPM number: oceanbase-4.2.1.8-108010012024082314

Bug fixes

• Fixed the issue where an error was returned during backup restore to object storage if the destination did not support MD5 or was not fully compatible with MD5.
• Fixed the issue where OCP could not display restore information when the dump_backup command in ob_admin printed more than 99 backup sets.
• Fixed the issue where an error was returned if a user variable name contained invalid characters.
• Fixed the issue where the Hint now supports _push_join_predicate to disable predicate pushdown for non-base tables.
• Fixed the issue where the return type of a custom function was incompatible with MySQL.
• Fixed the issue where error 4023 was returned when calling a stored procedure.
• Fixed the issue where a memory leak occurred in the PlJit module in specific scenarios.

V4.2.1 BP8

Version information

• Release date: July 25, 2024
• Version: V4.2.1 BP8
• RPM number: oceanbase-4.2.1.8-108000052024072217

Upgrade notes

• You can upgrade to this version from V4.1.0 BP1-BP4, V4.2.0 GA, V4.2.0 BP1, V4.2.1 GA, and V4.2.1 BP1-BP7.
• During the upgrade from V4.2.1 GA/hotfix versions to V4.2.1 BP8, jobs cannot be created while both the old and new versions are running at the same time.

Feature enhancements

• Log stream replica management

  In versions earlier than V4.0, OceanBase Database provided a series of O&M commands for partition replica management, such as adding, deleting, and converting the type of a partition replica. Starting from V4.x, the concept of partition is replaced by log stream, and the new version redesigns the operations for log stream replica-level tasks. It provides a range of syntax to support adding, deleting, converting the type, migrating, modifying the number of Paxos members, and canceling disaster recovery tasks for log stream replicas, meeting the manual O&M needs for log stream replica management.

• Support for specifying a domain name for DBLink access

  OceanBase Database supports accessing remote databases through DBLink. In earlier versions, you had to specify the IP address of the remote database when creating a DBLink. The new version allows you to specify a domain name instead.

• Verification of primary and standby tenant role switchover

  OceanBase Database supports primary and standby tenant role switchover. In the case of zero data loss, you can switchover the standby tenant to the primary tenant or vice versa. In the case of data loss, you can failover the standby tenant to the primary tenant. Since role switchover operations may fail, the new version introduces the SWITCHOVER/FAILOVER VERIFY feature. By adding the VERIFY keyword to the SWITCHOVER or FAILOVER command, you can verify in advance whether the operation can be successfully executed. If it cannot be executed, an error message will be returned.

• Display of primary and standby tenant events

  Before OceanBase Database V4.2.1 BP8, events such as primary and standby tenant SWITCHOVER and FAILOVER were recorded in RS events. RS events are periodically cleaned up, and tenant-level events are difficult to find among cluster-level events. The new version records primary and standby tenant events separately for each tenant and displays them in the CDB/DBA_OB_TENANT_EVENT_HISTORY view.

• Cursor access after transaction commit

  Starting from V4.0, cursors cannot fetch data after a transaction is committed. In V4.2.1 BP8 and later, cursors can fetch data after a transaction is committed, as long as they do not read tables modified by the current transaction. This feature must be enabled by enabling the _enable_enhanced_cursor_validation parameter.

• SM3 encryption function

  The MySQL-compatible mode adds support for the SM3 encryption function. In Oracle-compatible mode, the DBMS_CRYPTO.HASH subprogram adds support for the HASH_SM3 hash encryption algorithm.

• Arbitration support for hybrid cloud active-active architecture

  As the control service of OceanBase Database, the RS provides important features such as resource management, disaster recovery, load balancing, and schema management. In the 2F1A or 4F1A deployment mode, network issues may trigger arbitration degradation. After the degradation, if the log stream leader is still disconnected from the RS, features that depend on the RS, such as DDL operations, cannot be executed, which affects system availability.

  To solve this issue, a new cluster-level parameter, arbitration_degradation_policy, is added to specify different arbitration degradation strategies:

  • LS_POLICY: the default degradation strategy.
  • CLUSTER_POLICY: checks connectivity with the RS before the degradation.

  When CLUSTER_POLICY is enabled, the log stream leader checks whether the network is connected to the RS before the degradation. If the network is disconnected, the degradation is not executed, and the system enters the "silent" election mode. In this state, the current replica can no longer be elected as leader, ensuring that the leader is eventually switched to a replica that is connected to the RS. follower replicas that enter the election "silent" state will periodically check their connectivity with the RS. Once connectivity is restored, they exit the "silent" state and can again be elected as leader.

• Response time statistics histogram for OBKV

  The new version adds OBKV-related statistical categories to the [G]V$OB_QUERY_RESPONSE_TIME_HISTOGRAM system view, building upon the response time statistics histogram feature introduced in V4.2.1 BP7. The categories include TABLEAPI SELECT, TABLEAPI INSERT, TABLEAPI DELETE, TABLEAPI UPDATE, TABLEAPI REPLACE, TABLEAPI QUERY AND MUTATE, TABLEAPI OTHER, HBASE SCAN, HBASE PUT, HBASE DELETE, HBASE APPEND, HBASE INCREMENT, HBASE CHECK AND PUT, HBASE CHECK AND DELETE, and HBASE HYBRID BATCH.

• Column pagination for OBKV-HBase

  Native HBase supports column pagination, which improves query performance in scenarios involving very wide tables. The new version of OBKV-HBase also supports column pagination, allowing users to limit the number of returned columns using the ColumnPaginationFilter.

• Reverse scan for OBKV-HBase

  OBKV-HBase stores data sorted by RowKey. In scenarios requiring ordered data access, scans are typically performed in ascending order of RowKey. However, some use cases require accessing data in descending order. To address this, the new version introduces the reverse scan feature, allowing users to scan data in descending order of RowKey, thereby enhancing query performance.

• Operating system compatibility

  The new version allows users to run OceanBase kernel scripts—such as upgrade and time zone import scripts—using Python 3, to accommodate Python environment dependencies in certain newer operating system versions.

Parameter changes

View changes

Bug fixes

• Fixed the issue where the standby database may fail to synchronize data due to a timeout when the replay lag between log streams is excessively large.
• Fixed the issue where, in Oracle-compatible mode, the trigger If Updating(expr) does not support using a cursor as expr.
• Fixed the issue where index table compaction is slow when there are a large number of delete operations during minor compaction.
• Fixed the issue where executing a delete statement with the PHP driver reports the error Cannot execute queries while other unbuffered queries are active.
• Fixed the issue where memory leaks and core dumps may occur when using PL in specific scenarios.
• Fixed the issue where a core dump may occur when using PL on specific hardware models.
• Fixed the issue where an overflow may occur due to the use of LIMIT + OFFSET.
• Fixed the issue where, in specific scenarios, a sequence operator is still generated by default even when not used, resulting in long execution times for insert or update operations.
• Fixed the issue where a core dump may occur due to non-atomic access to released reference objects during PS eviction.
• Fixed the issue where granting user privileges with dcl_restriction set reports a "user does not exist" error if the user does not exist.
• Fixed the issue where stopping a dbms_scheduler job after a job execution failure may result in a core dump.
• Fixed the issue where memory leaks may occur when using Tencent Cloud Object Storage (COS) for archive backups.
• Fixed the issue where, in Oracle-compatible mode, using the PS protocol may result in error 4016 due to type inference in CASE WHEN statements.
• Fixed the issue where error 4016 is reported during prefix index scans in OBKV mode.
• Fixed the issue where abnormal data may be generated during minor compaction of transactional tables.
• Fixed the issue where errors may occur during COMMENT ON TABLE operations.
• Fixed the issue where, in some scenarios, passing an empty array to PL results in error 4013.
• Fixed the issue where, in some scenarios, CDC may fail to pull data, causing an exit.
• Fixed the issue where frequent vertical scaling may result in a core dump.
• Fixed the issue where backup cleanup did not delete table lists, resulting in OCP statistics errors.
• Optimized PX thread calculation to fix the issue of high parallel execution time.
• Fixed the issue where memory inflation occurs in the sqlexecutor during specific insert operations.
• Fixed the issue where, during cluster migration, running traffic on OBKV may lead to a core dump.
• Fixed the issue where, in specific scenarios, PL fails to allocate memory.
• Fixed the issue where a core dump occurs during concurrent direct load and DDL operations.
• Fixed the issue where garbled characters appear when exporting with the GB18030 character set.
• Fixed the issue where spatial indexes are not utilized in GIS scenarios.
• Fixed the issue where negative numbers inserted into unsigned decimal columns are not converted to 0.
• Fixed the issue where, after certain upgrade paths, cluster triggers fail to work.
• Fixed the issue where a core dump occurs due to connect by in specific scenarios.
• Fixed the issue where, when ob_enable_batched_multi_statement is enabled, batch optimization produces incorrect results for insertup.
• Fixed the issue where a core dump occurs during specific external table import scenarios.
• Fixed the issue where incorrect results are returned due to the combination of distinct and row_number in specific scenarios.
• Fixed the issue where, when using the decode function in PS mode, an error is reported due to incorrect type inference.
• Fixed the issue where major compaction cannot be triggered in specific scenarios.
• Fixed the issue where, under mixed PS/PS hybrid protocol, output parameters cannot be obtained.
• Fixed the issue where the return value of a JSON field accessed via JDBC is incorrect.
• Fixed the issue where the global index is lost after canceling a truncate statement.
• Fixed the issue where execution plans do not match synonyms.
• Fixed the issue where, when SQL statements contain comments, an incorrect execution plan and error packet are returned.
• Fixed the issue where, during SPM evolution, refreshing the plan cache causes the in-memory baseline manager to mistakenly treat a new plan as a verified plan, resulting in SPM not working correctly.
• Fixed the issue where, when multiple threads concurrently generate poor execution plans, the evolution results may not be stored in the plan cache after the evolution task completes.

V4.2.1 GA

Version information

• Release date: September 28, 2023
• Version: V4.2.1 GA
• RPM version: oceanbase-4.2.1.0-100000182023092722

Overview

OceanBase Database V4.2.1 is the first long-term support (LTS) version in the V4.2.x series. This version introduced new features compatible with MySQL, such as the VALUES statement and JSON_TABLE expression. It also provides compatibility with Oracle through features like DBLink for package calling and sequence reading. Additionally, this version introduced the Workload Repository (WR)-based data collection framework and enhanced end-to-end diagnostic capabilities for commercialization. It optimized system resource utilization and supports table-level restore and Tencent Cloud Object Storage (COS). This version is recommended in production environments for routine business operations both in the cloud and offline.

Key features

Compatibility with MySQL

• VALUES statement

  The VALUES statement was introduced in MySQL 8.0.19. It can be used to quickly construct a table of data or as a standalone DML statement with support for ORDER BY and Limit clauses. It can also be used as a special table in regular DML statements. OceanBase Database V4.2.1 is compatible with MySQL Database and supports the VALUES statement, making table value construction more convenient and easy to use. For more information, see VALUES.

• RENAME COLUMN

  The RENAME COLUMN syntax was supported since MySQL 8.0. It allows users to rename columns without changing their definitions, which is more lightweight than the CHANGE COLUMN syntax. OceanBase Database is compatible with the RENAME COLUMN syntax of MySQL 8.0 since V4.2.1. For more information, see RENAME COLUMN.

Compatibility with Oracle

• Extended DBLink capabilities

  In OceanBase Database V4.1.0, the Oracle mode already supported the ability to read and write native Oracle tables through DBLink. Starting from V4.2.1, it also supports reading remote packages through DBLink. After you establish a connection with Oracle Database, you can call remote stored procedures by using a string in the format of remote stored procedure name @DBLink name in the Oracle tenant of OceanBase Database. You can also call a stored procedure by using remote synonyms defined in the remote database or local synonyms defined in DBLink. For more information, see PL DBLink.

  In addition, OceanBase Database V4.2.1 supports access to remote SEQUENCE objects. Similar to data tables, you can access remote SEQUENCE objects, including calculating the NEXTVAL and CURRVAL values of SEQUENCE objects, by using a string in the format of SEQUENCE object name @DBLink name.

• Partition or subpartition renaming

  Oracle Database supports the RENAME PARTITION and RENAME SUBPARTITION syntax for renaming a partition or subpartition. OceanBase Database has supported partitioned and subpartitioned tables since its early versions but lacked a simple method to change partition names. Starting from V4.2.1, OceanBase Database is compatible with the RENAME PARTITION and RENAME SUBPARTITION syntax of Oracle Database, making it easier to rename partitions or subpartitions. For more information, see Rename a partition or subpartition.

OBKV features

• JSON_TABLE expression

  JSON is a semi-structured data format where users can extract specific values from JSON strings based on a path. The JSON_TABLE expression allows users to convert semi-structured data into structured data. The earlier versions of OceanBase Database already supported the JSON data type in both MySQL mode and Oracle mode, but the JSON_TABLE expression was not implemented in MySQL mode. To meet the needs of users who want to convert JSON data into structured data for computations, OceanBase Database V4.2.1 also supports this expression in MySQL mode. For more information, see JSON_TABLE.

• OBKV TTL

  Time-to-live (TTL) is a commonly used feature in NoSQL databases, designed to automatically expire data. For example, in businesses that deal with historical data, there is a need to periodically scan the data, determine its expiration time, and delete it accordingly. Many businesses currently rely on the TableAPI of OBKV. To simplify the management of periodic data, OceanBase Database provided the OBKV TTL capability since V4.2.1. Users can define TTL attributes at the table or row level using the CREATE TABLE statement so that expired data is not processed during read and write operations in OBKV.

Performance improvements

• Concurrent execution of CREATE TABLE

  In the earlier versions of OceanBase Database, DDL requests were executed serially in RootService queues. Starting from OceanBase Database V4.1.0, the concurrent DDL capability was introduced, with support for concurrent execution of TRUNCATE TABLE. To address the performance issues related to schema migration for tables with millions of data rows, V4.2.1 now supports concurrent execution of CREATE TABLE, providing a performance improvement of tenfold or even more compared with serial execution.

• Improved foreign key check performance

  Prior to OceanBase Database V4.2.1, foreign key checks were implemented using nested SQL statements, incurring significant overhead. From V4.2.1, foreign key checks are performed using Database Autonomy Service (DAS) tasks, and batch checks in single-table DML operations is supported. Additionally, with the check result caching strategy, noticeable performance improvements have been achieved in INSERT and UPDATE scenarios. In a single-node scenario (where the parent table and child table are on the same node), the performance degradation caused by foreign key checks during INSERT and UPDATE operations on foreign key tables is generally controlled to around 10% compared with tables without foreign keys. In a distributed scenario (where the parent table and child table are on different nodes), the performance degradation is generally controlled to around 30% compared with tables without foreign keys during INSERT and UPDATE operations.

• Dynamic sampling on MemTables

  OceanBase Database V4.2.0 introduced the dynamic sampling feature, which samples data during the generation of an execution plan. When the number of rows in the SSTable exceeds that in the MemTable, dynamic sampling is performed on SSTable blocks. When the number of rows in the MemTable exceeds that in the SSTable, dynamic sampling is performed on the MemTable. In V4.2.0, this was achieved through full read of the MemTable, which was relatively inefficient. However, in V4.2.1, direct sampling for the MemTable is implemented, utilizing RANGE partitioning to perform interval reads. This enhancement significantly improves the efficiency of dynamic sampling on the MemTable.

• Parallel read of archived logs

  In OceanBase Database V4.1.0, OceanBase Change Data Capture (CDC) can read archived logs through the CDC service or directly read logs from the archive destination. In V4.2.0, a network-based standby database reuses the log pulling framework of OceanBase CDC to pull logs from the primary database by using the CDC service. After the CDC service receives a log pulling remote procedure call (RPC) request from OceanBase CDC or a network-based standby database, the service first attempts to read logs from the local disk. If the corresponding logs do not exist in the local disk due to reasons such as log stream garbage collection (GC) or log recycling, and if the tenant has enabled log archiving, the CDC service reads logs from the log archive destination, such as the network file system (NFS) or Alibaba Cloud Object Storage Service (OSS). The log reading performance of the CDC service determines the log consumption speed at the downstream. If the performance of the CDC service in reading archived logs from OSS is poor, the synchronization link or the network-based standby database may lag behind the primary database and may be unable to become synchronized with the primary database. To address this issue, V4.2.1 allows the CDC service to read OSS-archived log files based on the basic capability of parallel read of OSS files.

Resource optimization

This version optimized the utilization of system resources in public cloud environments, including user tenant memory, memory of the SYS500 tenant, and operating system memory. For example, for Elastic Compute Service (ECS) instances with specifications of 128 GB or higher, the memory utilization of system resources has been reduced from around 30% to approximately 15%.

High availability enhancement

• Table-level restore

  Prior to OceanBase Database V4.2.1, tenant-level data restore was supported. If data within a table was damaged due to a misoperation, users needed to rely on the physical restore feature to restore the tenant to a previous point in time or use the import/export feature for table-level restore. V4.2.1 added support for table-level restore, allowing users to specify which backup data to use, which databases or tables to restore, which tenant to operate on, and the desired recovery point in time on the target cluster. For more information, see Table-level restore.

• Support for COS

  OceanBase Database V4.1.0 supports OSS as the backup media. OceanBase Database V4.2.1 supplements this support by allowing users to back up logs and data to COS and read backup data from COS for data restore.

Security enhancement

Data integrity protection: The Security Assessment of Commercial Cryptography Application imposes requirements for confidentiality and integrity protection on stored data in information systems. In the versions earlier than V4.2.1, the transparent encryption feature of OceanBase Database has already supported AES_ECD and SM4_CBC (which are named in the format of encryption algorithm_encryption mode), providing confidentiality protection for stored data. V4.2.1 added support for the GCM mode. In addition to data encryption, the checksum of ciphertext is calculated based on the key, and the ciphertext is checked during decryption to determine whether the ciphertext has been changed, thereby protecting data integrity.

Diagnostic capabilities improvement

• WR-based data collection framework

  The ease of use of the database performance diagnostics feature is closely related to the efficiency of system tuning. Oracle Database 10g introduces proactive automatic diagnostic capabilities such as Active Session History (ASH), Automatic Workload Repository (AWR), and Automatic Database Diagnostic Monitor (ADDM), and provides an inside-out (with information collected by internal components) and top-down (based on the database time and other metrics) database optimization and analysis framework. After decades of development, these capabilities have become industry benchmarks. OceanBase Database V4.2.1 implements a data collection framework similar to AWR of Oracle Database. The framework collects existing data such as ASH reports, statistics, wait events, and SQL execution details, and periodically persists performance-related views of OceanBase Database. OceanBase Database V4.2.1 introduces WR views and supports configuration adjustment and snapshot management by using DBMS_WORKLOAD_REPOSITORY packages. The new version also unifies, streamlines, enriches, and enhances SYSSTAT, ASH, and other statistical metrics for higher comprehensiveness and accuracy. The performance diagnostic capabilities will be further enhanced in future OceanBase Database versions. For more information, see Overview of WR.

• Enhanced ASH feature

  The ASH feature was introduced in OceanBase Database V4.0.0_CE. It samples the status of all active sessions in the system at an interval of 1 second and records the information in internal tables. In OceanBase Database V4.2.1, additional sampling points related to transactions, storage, and DAS were added. The ASH data is collected into the WR internal table at a default sampling rate of 10:1 and a collection interval of 1 hour. By analyzing ASH data, you can easily identify issues such as long wait events, slow SQL statements, and resource utilization of active sessions, which helps in performance optimization.

• End-to-end diagnostics feature

  OceanBase Database V4.2.0 supports visualized end-to-end tracing of SQL requests, and in V4.2.1, the configuration management capability for end-to-end diagnosis is further enhanced. A new view GV$OB_FLT_TRACE_CONFIG is added to record the configuration policies for end-to-end diagnostics at different levels. The GV$OB_PROCESSLIST view now includes LEVEL, SAMPLE_PERCENTAGE, and RECORD_POLICY columns to display the monitoring level, sampling frequency, and recording/printing policy that are effective for each session. Additionally, the GV$OB_SQL_AUDIT view includes a new column FLT_TRACE_ID to record the end-to-end trace information, enabling comprehensive SQL tracing. OceanBase Cloud Platform (OCP) will also provide corresponding page functionality to support this feature.

Product form

Public cloud primary address mode: In the public cloud architecture, the Client -> SLB -> ODP -> OceanBase Database link can be too long, resulting in significant performance loss in scenarios that require extremely high performance. For businesses whose data is stored on a single node and does not require read/write splitting, OceanBase Database V4.2.1 provides the primary address mode where a client can directly connect to a database through Alibaba Cloud Server Load Balancer (SLB), greatly reducing performance loss in the link.

Product behavioral changes

The following table describes the product behavioral changes made in this version.

View changes

The following table describes the changes to views made in this version.

Parameter changes

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

Recommended versions of tools

The recommended platform tool versions for OceanBase Database V4.2.1 are described in the following table:

Upgrade notes

• An online upgrade of OceanBase Database Community Edition from V4.2.0 to V4.2.1 is supported.
• An online upgrade of OceanBase Database Community Edition from V4.1.0 to V4.2.1 is supported.
• We recommend that you upgrade OceanBase Database before you upgrade ODP.
• During the upgrade, the system automatically disables major compactions and DDL operations. After the upgrade is complete, the system resumes normal operation.
• An online upgrade of OceanBase Database Community Edition from V3.x to V4.2.1 is not supported.
• You can upgrade OceanBase Database Community Edition from V3.x to V4.2.1 through logical data migration by using OMS.