Limitations

This topic describes the environment requirements for installing and deploying OceanBase Developer Center (ODC) and the limitations of each feature module.

Limitations on deployment environment

Web version

Desktop version

Limitations of product capabilities

Overview of supported data source types

Limitations on data source versions

Limitations on privileges

• To avoid affecting the metadata database, we recommend that you use an independent database as the metadata database of ODC. The user that ODC uses to access the metadata database must have all privileges on the database. You can grant all privileges to the user by running the GRANT ALL PRIVILEGES ON odc_metadb.* TO 'user'@'host'; statement.

• In OceanBase Database V4.0.0 and later, you must have the debugging privilege to perform debugging. You can grant the debugging privilege to a user by running the GRANT DEBUG CONNECT SESSION TO <user> or GRANT DEBUG ANY PROCEDURE TO <user> statement.

• For OceanBase data sources, to improve the data export speed, you must configure a sys tenant account.

Limitations on task concurrency

Concurrency of ticket scheduling

In ODC V4.3.3-bp2 and later, the maximum number of tasks that can be run on each node is 10 times the number of CPU cores of the Jvm. If the number of tasks exceeds the upper limit, the tasks fail. In addition, the number of data export tasks is limited. The upper limit is the maximum value of the number of CPU cores of the Jvm and 5.

Concurrency of job scheduling

The calculation logic for the maximum number of tasks that can be run on each ODC node is as follows:

1. Obtain the total physical memory, MemTotal.
2. Obtain the maximum memory of the current Jvm (the memory size of the ODC Docker container), MemTakenByODC.
3. Obtain the minimum memory required for a running task (1 GB by default), MinMemProcessNeed.
4. The calculation logic for the number of concurrent jobs is (MemTotal * 0.8 - MemTakenByODC) / MinMemProcessNeed.

Limitations on features

Session limitations

• ODC provides two transaction commit modes: manual and automatic. In manual mode, if the data source is OceanBase Database, to avoid the connection being terminated due to the execution interval between two SQL statements in a transaction exceeding the value of the ob_trx_idle_timeout parameter, you must set the ob_trx_idle_timeout parameter to a value greater than the SQL query timeout. However, if the value of the ob_trx_idle_timeout parameter is too large, the memory occupied by the session cannot be released in time. Therefore, you must set the parameter carefully.

PL limitations

The following table describes the PL features supported by ODC.

Limitations on SQL development

• You cannot edit a result set that contains SET or ENUM fields.

• End-to-end tracing is supported only in OceanBase Database V4.0.0 and later.

• Real-time SQL analysis is supported only in OceanBase Database V4.2.4 and later and V4.3.3.1 and later.

Limitations on command-line windows

• The command-line window is not provided in the ODC client for macOS.

• You can open at most three command-line windows at a time.

• Operations performed in the command-line window are not recorded.

Limitations on data desensitization

• Data desensitization is not supported in the command-line window.

• Data desensitization is not supported in the PL execution window.

• When you configure a recognition rule script, you can use only the Objects and String classes in Java.

• When you configure a recognition rule script, you cannot use Groovy closures or built-in closure functions.

• If the exported data from a MySQL data source contains sensitive data, the full masking algorithm is used for desensitization.

• If the exported data from an Oracle data source contains sensitive data, the full masking algorithm is used for desensitization.

• If the exported data from a Doris data source contains sensitive data, the full masking algorithm is used for desensitization.

Limitations on SSO integration

• Only the authorization code mode is supported for OAUTH and OIDC.
• When you log out of OAUTH or OIDC, only the login state of ODC is cleared. The login state of the SSO system is not cleared.

Limitations on large model integration

• You must configure a vector database. The OB version must be 433 or later.

Limitations on tickets

Limitations on import and export

• General limitations:

  • The files involved in import and export tasks are retained by default for 14 days.
  • The total number of records of the exported objects in the details of an export task is not accurate but depends on the OceanBase view.
  • In ODC 4.1.0 and later, you can configure the sys tenant account for an OceanBase data source to improve the import and export speed. In addition, when you export objects other than tables and views, you do not need to configure the sys tenant account.

• Limitations on export:

  • Web ODC has no hard limit on the number of rows in the result set exported, but the maximum size of the exported data is 2 GB (uncompressed).
  • Web ODC has a limit on the size of the exported data. The maximum size of the exported data is 2 GB (uncompressed). If the data exceeds this limit, it cannot be exported. To export large amounts of data, use the OBDUMPER tool.
  • If a foreign key contains multiple columns, the order of the columns in the foreign key cannot be guaranteed during export. For example, in the statement FOREIGN KEY(c1,c2) REFERENCE ..., the order of c1 and c2 cannot be guaranteed.

• Limitations on import:

  • Web ODC has a limit on the size of the imported file. The maximum size of the imported file is 2 GB (compressed). If the file exceeds this limit, it cannot be imported. To import large amounts of data, use the OBLOADER tool.
  • If the imported data contains a table with a foreign key, the import may fail because the import order of the associated tables cannot be guaranteed.
  • The name of the imported data file must be in the same case as the name of the target table.
  • If you import a single table and the selected data file contains data of other tables, the data of other tables is also imported.
  • If you import data by using an SQL file and the SQL file contains a CREATE TABLE statement, the structure is skipped and only an error is recorded in the log if the structure already exists.

Limitations on database changes

Limitations on automatic rollback scripts:

• Automatic rollback scripts can be generated only for UPDATE and DELETE statements.

• The maximum number of rows affected by a supported change is 1 million. If the number of rows affected exceeds 1 million, an automatic rollback script cannot be generated.

• If a table contains large objects (LOBs), an automatic rollback script cannot be generated.

• If a table in OceanBase Database or MySQL does not contain a primary key or unique key, an automatic rollback script cannot be generated.

• If the modified field (SET) and the condition field (WHERE) of an UPDATE statement are the same, an automatic rollback script cannot be generated.

• The maximum size of an automatic rollback script is 256 MB.

Limitations on data mocking

• The maximum number of rows in a single data mocking task is 100 million.

• Tables with check constraints cannot be used for data mocking.

• Tables with RANGE or LIST partitions cannot be used for data mocking.

Limitations on schema comparison

• Supported data source pairs:

  • OceanBase Database MySQL to OceanBase Database MySQL

  • OceanBase Database Oracle to OceanBase Database Oracle

  • MySQL to MySQL

• Supported schema objects for comparison: tables. Supported schema object attributes for comparison: columns, primary keys, constraints, indexes, partitions, and table attributes.

  • Supported column attributes for comparison: data type, character set, collation, comment, and default value.

  • Supported partition attributes for comparison: partitions. Subpartitions cannot be compared.

  • Supported table attributes for comparison: character set, collation, and comment.

• Check constraints cannot be compared in OceanBase Database MySQL.

• Tables with foreign keys cannot be compared.

Limitations on multi-database changes

• Multi-database changes are supported only for homogeneous data sources.

Limitations on online schema changes

• The table must contain a primary key or a non-null unique key and cannot contain foreign keys.

• The table name in OceanBase Database MySQL cannot exceed 54 characters, and the table name in OceanBase Database Oracle cannot exceed 118 characters.

• When ODC connects to OceanBase Database Community Edition, the cluster name and the sys tenant account must be specified in the data source configuration.

• By default, the system locks the user and disables the session to prevent data writes during the table name change. In some versions (OceanBase Database MySQL V4.2.5 and later and OceanBase Database MySQL V4.3.0 and earlier), you can use the LOCK TABLE statement to prevent data writes. For more information, see Create a online schema change task.

• If you perform a DDL operation on the table during a online schema change, the task fails.

• Before you create a online schema change task by using ODC of OceanBase Database on Alibaba Cloud, make sure that an idle OMS instance exists.

Supported schema changes for online schema changes:

Limitations on logical databases

• Supported data sources: OceanBase Database MySQL and MySQL.

• Supported operations: DDL operations.

• SQL checks and SQL window specifications in ODC security specifications are not supported.

Limitations on job use

Limitations on partitioning plans

• Supports only the OceanBase MySQL and OceanBase Oracle data sources.

• Range-partitioned tables only.

• If the maximum value of the upper bound of the last partition in a RANGE partitioned table is MAXVALUE, the database does not allow you to add a new partition. Therefore, you cannot create a partitioning strategy for such a table by using a DTS scheduled task.

• If a partitioning job is deployed and the table to be processed does not exist, the job cannot be executed.

Limitations on data archiving

• Prerequisites:

  • The archive table must contain a primary key. For data sources of the OceanBase MySQL or MySQL type, the archive table can also contain a unique index.

  • A database user used for archiving must have read/write permissions and access permissions to internal views. For information about how to configure these permissions, see View user privileges, Overview of users and privileges, and Modify user privileges.

  • Ensure that the field types of the source table are compatible with those in the destination table. Data archiving does not check field compatibility.

  • Structure synchronization and automatic table creation are not supported for data synchronization between a heterogeneous database and an ApsaraDB for PolarDB for MySQL instance.

• Archiving link support:

  • OceanBase MySQL to MySQL, and MySQL to OceanBase MySQL.

  • OceanBase Database compatible with Oracle to OceanBase Database compatible with Oracle.

  • MySQL data to OceanBase MySQL data.

  • OceanBase Database to OceanBase Database.

  • Migrate data from a PostgreSQL database to an OceanBase Database (MySQL mode) cluster.

  • Migration of OceanBase MySQL, OceanBase Oracle, MySQL, Oracle, and PostgreSQL databases to an object storage service (such as OSS, COS, OBS, or S3).

• The following scenarios are not supported:

  • If the table contains XMLTYPE fields, an OceanBase MySQL data source cannot be archived.

  • Tables containing JSON and XMLTYPE fields in OceanBase Database are not supported for archiving.

  • For a PostgreSQL data source, table definitions that include array, composite, enum, geometry, XML, HSTORE, or full-text search types are not supported.

  • If a LIMIT statement exists in an archiving condition, the archiving condition cannot be used.

  • Tables containing foreign keys are not supported for archiving.

• Automatic table link creation is supported.

  • From OceanBase Oracle to OceanBase Oracle.
  • OceanBase MySQL to OceanBase MySQL
  • From MySQL to MySQL (excluding versions earlier than MySQL 5.7).

• Table structure synchronization links are supported.

  • From OceanBase MySQL to OceanBase MySQL.

Limitations on data cleanup

• Prerequisites:

  • Tables to be cleaned must contain a primary key, or unique index in data sources of the MySQL or OceanBase MySQL type.

  • Database users used for cleanup must have read/write permissions and access to internal views. For more information about permission configuration, see View user permissions, Overview of users and permissions, and Modify user permissions.

• Clean-up data source support:

  • OceanBase MySQL data source.

  • OceanBase data source.

  • MySQL data source.

  • An Oracle data source.

  • PostgreSQL data sources.

• The following situations do not support cleaning:

  • If an XMLTYPE column exists in the MySQL OceanBase source table, data cannot be cleared.

  • OceanBase Oracle, Oracle, and PostgreSQL data sources cannot be cleaned up if the table does not have a PRIMARY KEY column.

  • If the tables in the Oracle data source of OceanBase Database contain JSON or XMLTYPE fields, data cannot be cleared.

  • If the clean-up conditions contain an LIMIT statement, cleaning up is not supported.

  • If the table contains foreign keys, the operation fails.