Known issues, limitations, and notes

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

• General EDB Data Migration Service limitations

• Oracle limitations

• Postgres limitations

General EDB Data Migration Service limitations

• Case sensitivity in object names: EDB DMS doesn’t currently support migrating schemas, tables, and columns that have case-sensitive names.

• HM-managed destinations: For migrations to HM-managed destinations, you must ensure edb_admin is the owner of the destination database, schema, and table in Hybrid Manager (HM) environments 1.1 and earlier. Otherwise, the migration will fail. This limitation will be fixed in HM versions 1.2 and later.

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 Reader and Writer support 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;