Known issues, limitations, and notes v1.3
These are the known issues, limitations, and notes for:
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.
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.
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.