Known issues, limitations, and notes v1.3

Suggest edits

These are the known issues, limitations, and notes for:

Data migration limitations

Case sensitivity in object names

EDB DMS doesn’t currently support migrating schemas, tables, and columns that have case-sensitive names.

Upgraded destinations clusters

Clusters provisioned in Hybrid Manager versions 1.2 and earlier cannot be used as migration destinations after the HM instance is upgraded to version 1.3 or later. You must create a new cluster in the upgraded environment to use it as a valid migration destination.

Considerations and limitations for multiple migrations to a single destination

The DMS supports running multiple data migrations from one source to one destination database, but certain restrictions apply.

  • Table usage: Each destination table can only be actively used in a single migration at any given time.

  • Unique resourceID (applies to migrations to external destinations): When running multiple migrations to an external destination, you must assign a unique resourceID to each instance of the EDB DMS Agent in writer mode with the DBCONFIG_DATABASES_0__RESOURCE_ID=${Resource_ID} parameter. This prevents concurrent migrations from attempting to use the same table simultaneously, which can cause data loss or duplication.

    Note

    This resourceID requirement does not apply to migrations targeting HM-managed Postgres instances.

  • Performance planning (applies to migrations to external destinations): While performance generally remains strong with the recommended specifications, if you run a large volume of migrations (five or more) to the same external destination database, you should consider allocating additional CPU, memory, and volume IOPS/throughput to the destination to prevent resource contention, specially if the destination is an external database.

  • Resource management: Each migration job requires a dedicated, non-concurrent use of the necessary DMS Agent components.

    DMS Agent in reader mode (source): Don't use a single running instance of the EDB DMS Agent in reader mode for more than one concurrent migration from the same source database. The HM Console will automatically remove a source database from the available list once it is active in a migration. However, you can use a single DMS Agent in reader mode for subsequent migrations or for concurrent migrations from different source databases.

    DMS Agent in writer mode (external destination): Each migration requires its own instance of the DMS Agent in writer mode, even if the migration shares the same destination as another migration.

Oracle limitations

Unsupported Oracle data types

A limited number of Oracle data types and features aren't supported by EDB Data Migration Service (EDB DMS).

See the Debezium documentation for detailed comments on supported data types.

Unsupported Oracle data types include:

  • BFILE
  • LONG
  • LONG RAW
  • RAW
  • UROWID
  • User-defined types (REF, Varrays, Nested Tables)
  • ANYDATA
  • XMLTYPE
  • Spatial

EDB DMS supports replicating Oracle tables that contain BLOB, CLOB, or NCLOB columns only if these also have the primary key constraint. If the tables don't have the primary key constraint, the streaming replication will only support INSERT operations.

BINARY_FLOAT and BINARY_DOUBLE types in Oracle that might contain Nan, +INF, and -INF values are not supported by EDB DMS.

EDB DMS does not support values containing a null character (0x00) for text field types like VARCHAR and CLOB in Oracle.

Oracle 21c databases

The Data Migration Service Agent supports migrating Oracle 21c databases. However, Migration Portal doesn't. This means that to migrate 21c databases, you must manually perform the schema migration.

Postgres limitations

Unsupported domain type definitions in columns

The EDB DMS doesn't support migrating tables with columns that have user-defined domains as data types for the following data type domains:

  • DATE
  • TIME
  • TIMESTAMP
  • INTERVAL
  • UUID
  • ENUM
  • JSON
  • XML
  • POINT
  • LTREE
  • TSVECTOR

TSVECTOR type migration workaround

Although we don't support the migration of TSVECTOR type columns, you can apply this workaround to enable their migration. For example, this messages table in source database contains a TSVECTOR column:

CREATE TABLE messages (
    title       text,
    body        text,
    tsv         tsvector
);

Before starting the migration, you need to create a table in the destination database without the TSVECTOR column like this:

CREATE TABLE messages (
    title       text,
    body        text,
);

When you perform the migration, you must exclude the TSVECTOR column in the HM console when you review the tables on the Review your Tables page by unchecking the tsv column.

After the migration finishes, you will get the title and body columns migrated to the target database. Now you can add the TSVECTOR column to the target table like this:

ALTER TABLE messages ADD COLUMN tsv TSVECTOR DEFAULT NULL;

And then you need to run the following UPDATE statement to populate the column for all migrated data:

UPDATE messages SET tsv = to_tsvector('english', CONCAT(title, ' ', body)) WHERE tsv IS NULL;

Schema ingestion known issues

Additional schemas ingested for EDB Postgres Advanced Server sources

When viewing the list of schemas for a source EDB Postgres Advanced Server database that you have registered with the HM Agent, you may observe additional schemas that do not directly correspond to schemas you explicitly created. These extra schemas are generated internally by EDB Postgres Advanced Server as part of its Oracle compatibility feature set to represent Oracle PACKAGE objects. This is currently a known issue that is expected to be corrected in a future release. In the meantime, you can disregard these generated schemas for migration purposes.

← Prev

Supported databases and operating systems

↑ Up

Migrating databases with the Hybrid Manager

Next →

Optimizing migration performance