OceanBase Database Enterprise Edition V2.2.30

V2.2.30 BP14

Version information

• Release date: September 9, 2020
• Version: V2.2.30 BP14

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Fixed issues

• Issues about the core dump process of the OBServer are fixed.

• When the Perl driver is used for the MySQL-compatible mode of OceanBase Database, the INSERT ... ON DUPLICATE statement returns the number of affected rows that is inconsistent with the number of the affected rows of the MySQL database.

• When a distributed execution plan is executed, remote procedure calls (RPC) for DML statements are aggregated to improve efficiency and reduce bandwidth consumption. In this case, insufficient memory may lead to an execution error. However, the error code is overwritten and the execution continues, resulting in memory write failure and core dump.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

V2.2.30 BP15

Version information

• Release date: November 30, 2020
• Version: V2.2.30 BP15

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Function optimization

• Log printing at the transaction layer is optimized. The amount of logs printed to the observer.log file is reduced.

• Number system conversion by using the to_number function is supported in Oracle-compatible mode.

• The query performance of the all_tab_columns view in Oracle-compatible mode is optimized.

Fixed issues

• If a PL package is used in Oracle-compatible mode when the tenant memory is running out, the plan cache may access an invalid address, which leads to the unexpected exit of the observer process.

• In some cases, refreshing the location cache triggers circular dependency, which results in stack overflow and OBServer core dump.

• The throttling feature of OceanBase Database throttles the internal SQL statement for schema refresh, which results in slow schema refresh.

• The Duplicate Primary Key error is returned when data is inserted during the execution of the TRUNCATE TABLE statement.

• The major compaction is stuck due to the failure of check_micro_block_checksum.

• When the plan is added to the plan cache during the query of a temporary table, the table_name string does not end with \0, which results in OBServer core dump.

• The plan cache accesses released memory when a plan is evicted, which results in OBServer core dump.

• When the LOB data type is used, the total required_size indicated by the __all_virtual_meta_table is less than the actually occupied disk space. This is because the statistics do not take into account the space occupied by data of the LOB type.

• When HASH-RANGE partitioning is used, the memory of the HashNode module in the sys500 tenant of OceanBase Database leaks.

• An error is returned when index creation times out. This issue causes the default value of the ddl_timeout parameter to be ignored during index creation. The ddl_timeout parameter specifies the timeout period of index creation and is set to 2s by default. The creation of an index for a large table tends to time out, even if the system retries.

• The data write continues when the memory becomes insufficient because the error code is overwritten and not returned, which causes memory overflow and core dump.

• An error occurs during the comparison between the CHAR and VARCHAR data types of OceanBase Database in Oracle-compatible mode.

• The execution of the SUBTIME() function in MySQL-compatible mode may cause an out-of-bounds error and returns the error code 4016.

• The write of SSTable metadata fails when you create a partition table because an error is ignored, which results in an observer restart failure.

• The observer process may unexpectedly exit when you create an index for a subpartitioned table.

• You add columns to a table in MySQL-compatible mode and specify the column order, but the results are not as expected.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

V2.2.30 BP16

Version information

• Release date: March 11, 2021
• Version: V2.2.30 BP16

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Function optimization

• Repeated logs that are frequently printed are throttled and printed once every 100 logs.

• In earlier versions, the alter system minor freeze statement is executed without a timeout. In this version, its execution is subject to the timeout period for SQL statements.

• A minicore file is generated after OceanBase Database unexpectedly exits. The size of a minicore file is smaller than that of a core file.

• Symbols can be used in the compilation and packaging of OceanBase Database. By default, you can view the function names in a stack.

• You can add a column with a specified column_id.

• The log printing of the easy module is optimized.

• The processing of the signal by the observer process is optimized.

• The minor compaction of hot rows is optimized.

• The GBK character set is optimized.

• The speed of plan cache queries under the IS or IS NOT condition is increased.

• The logic for log printing of IO_MANAGER is optimized.

Fixed issues

• The major compaction is stuck due to the execution of the TIMESTAMPADD() function.

• After an operation at the storage layer fails, the released memory is accessed by the subsequent operation, which results in unexpected quit of the observer process.

• When the new parallel execution (PX) framework is used, the parameters are not cleared but reused, which results in the unexpected exit of the observer process.

• When the IFNULL() function and UNION ALL clause are used, the SQL execution thread does not respond and the execution does not return results.

• When a subquery is used as a filter in an expression, the SQL execution thread does not respond and the execution does not return results.

• The ring buffer operation causes the double free error, which results in the unexpected exit of the observer process.

• In MySQL-compatible mode, an error is returned during the conversion from the STRING data type to the INT data type.

• The observer process unexpectedly exits during the processing of the microblock cache.

• The memory may leak if an error occurs during the execution of a JOIN statement.

• When you insert a very long string that contains non-English characters, a schema error is returned and the subsequent DDL statements are stuck.

• No plan in the plan cache is hit when the SQL statement involves negative numbers and NULL.

• The replay is stuck when a single-partition transaction is converted to a distributed transaction in specific scenarios.

• The observer process unexpectedly exits due to the access to the released memory during the replay.

• After the ALTER TABLE statement is executed to delete all prefixed indexes that contain the same column at a time, an error occurs when you delete the column.

• In Oracle-compatible mode, an error occurs due to incorrect processing of the null values in the UPDATE SET statement.

• The observer process unexpectedly exits when the SQL engine processes a null string.

• SQL audit keeps printing false positive logs to the observer.log file due to PX.

• If the __all_server table does not contain the target server specified in the STOP SERVER statement, the system keeps retrying.

• The error code 4019 is returned when concurrent INSERT operations are performed on an auto-increment column.

• The observer process unexpectedly exits due to the concurrent empty intermediate result sets.

• When the UNION ALL clause is used, strings of the SQL statements that match the same execution plan may be truncated.

• An overflow error is returned when the length of an SQL expression exceeds 8 KB.

• The query_cache_type variable is incompatible with MySQL Database.

• The value field in the NLS_SESSION_PARAMETERS view is incompatible with Oracle Database.

• The information of time zone offset or region cannot be obtained when the time zone information is obtained.

• The plan ID of the execution plan for a deleted table remains in the plan cache, which results in an error indicating that the table does not exist when you query the gv$plan_cache_plan_explain view by using that plan ID.

• After you truncate a table that contains a trigger when the recycle bin is enabled, the execution of the PURGE RECYCLEBIN statement returns the error code 4016.

• A forced refresh of the location cache is performed after a piece of location information is hit, which results in frequent refreshes.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode.

V2.2.30 BP17

Version information

• Release date: May 19, 2021
• Version: V2.2.30 BP17

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Fixed issues

• An error is returned due to the incorrect processing of the HASH INTERSECT DISTINCT operator during the execution of the SELECT INTERSECT statement.

• The observer process unexpectedly exits when a string of only zeros is converted from the STRING data type to the NUMBER data type during the implicit type conversion.

• In Oracle-compatible mode, an error occurs during the execution of the INSERT (SELECT FROM DUAL) UNION (SELECT FROM DUAL) statement.

• The observer process may unexpectedly exit when you drop a global index.

• The major compaction is stuck when the MEDIUMTEXT data type is changed to the LONGTEXT data type.

• The memory for the sys500 tenant leaks because you drop a partition when a global index exists.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode.

V2.2.30 BP18

Version information

• Release date: July 8, 2021
• Version: V2.2.30 BP18

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Function optimization

• The performance of the optimizer in estimating and sampling rows of ultra-large partitions is optimized.

• The connection with a MySQL tenant by using UNIX domain sockets is supported.

Fixed issues

• When a node fails and the file descriptor feature is not disabled during the generation of the core dump file, other nodes still send RPCs to the failed node.

• The data disk cannot be automatically detected and identified when it does not respond.

• If the NESTED LOOP JOIN algorithm is used in a query, the observer process unexpectedly exits when a row that is relocated after the minor compaction of the MemStore is queried during the table access by the index primary key.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode.

V2.2.30 BP19

Version information

• Release date: August 5, 2021
• Version: V2.2.30 BP19

Applicable versions

You can upgrade OceanBase Database V2.2.1-20200731153445 and V2.2.20 directly to this version.

Notice

• To upgrade from V2.2.1 to V2.2.30, you must upgrade to V2.2.30-BP10 or later.

• If you want to upgrade from an earlier version to V2.2.1 and then to V2.2.30, make sure that you first upgrade to V2.2.1-1865649 or later. Then, you must perform a major or minor compaction before you can upgrade to V2.2.30.

Fixed issues

• In Oracle-compatible mode, the TO_TIMESTAMP() function always populates the date in UTC.

• The logical restoration fails after a function-based index is added.

• The observer process unexpectedly exits when it is in the progress of obtaining the freeze information.

• The 16 KB length limit of keys can be exceeded.

• The plan binding fails due to the comment added to the first row.

Known issues

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode. Otherwise, the thread that executes the SQL query may not respond.

• In Oracle-compatible mode, you must not set sql_mode to PAD_CHAR_TO_FULL_LENGTH. Otherwise, a query error may occur.

• In Oracle-compatible mode, you must not specify the alias of a system view in the statement when you query the system view. Otherwise, an error is returned.

Limitations

• You must not store clogs and data on the same disk, especially an HDD. Otherwise, the observer process may unexpectedly exit due to the latency of clog writes. In addition, if the disk is fully occupied by clogs, core tables of the system may become leaderless.

• When OceanBase Database is running, you must not set the time of the operating system back to the past.

• We recommend that you do not use the NVARCHAR2 data type in Oracle-compatible mode.