Migration fidelity

Known limitations for using Database Migration Service to migrate Oracle workloads into AlloyDB for PostgreSQL include:

  • The migration will be consistent eventually, and doesn't replicate each transaction as it happens. The migration brings in data from multiple tables. The order in which data is loaded into the destination may vary, but will re-align with the source after writes on the source are stopped and the migration buffer is cleared.
  • For performance reasons, we recommend that the destination schema doesn't have foreign keys enabled until the cut-over process is completed. Cut-over means that the destination AlloyDB for PostgreSQL instance is disconnected from the source and is now being used as your application write instance. Having to wait for foreign keys can delay data from entering the destination, and may result in temporary error messages while waiting for ordering to resolve.
  • Any transactions that are rolled back may be visible in the destination temporarily, if a transaction is long enough. To reduce lag, data from the Oracle database redo log files can be migrated before a transaction is committed, and will be removed when the transaction is rolled back.
  • All tables in the destination should have a primary key. This primary key must match the primary key of the source. If a table in the source doesn't have a primary key, then create one using one of the options in Migrate tables without primary keys.
  • During a migration, data definition language (DDL) changes to data, schemas, and metadata aren't supported. For schema changes, update the conversion workspace according to the new schema, and then update the relevant migration jobs.
  • Any tables that are created after the migration has started won't be migrated automatically. First, the tables must be created in the destination, and then the conversion workspace must be updated with the revised list of tables.
  • Any database table columns that have the ANYDATA, LONG/LONG RAW, NCLOB, UDT, UROWID, or XMLTYPE data types aren't supported, and will be replaced with NULL values.
  • Zero dates in DATE or DATETIME data types aren't supported. Zero dates are replaced with NULL values.
  • For Oracle 11g, any database table columns that have the ANYDATA or UDT data types aren't supported, and the entire table won't be replicated.
  • Index-organized tables (IOTs) aren't supported.
  • For database table columns that have the BFILE data type, only the path to the file will be replicated. The contents of the file won't be replicated.
  • Oracle Label Security (OLS) isn't replicated.
  • Migrating the initial snapshot of tables without primary keys that have more than 500 million rows isn't supported.
  • Sequence values are not migrated. Manually set sequence numbers to avoid data collision with the replicated data.