Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describen las limitaciones conocidas (incluidas las consideraciones especiales para controlar entidades como
claves principales o
claves externas y activadores), así como las
prácticas recomendadas para las migraciones heterogéneas de Oracle con Database Migration Service.
Qué no se migra
No se migran los usuarios ni los permisos.
Los cambios de esquema que se producen durante un trabajo de migración activo no se migran automáticamente. Si cambias el esquema durante la migración, primero debes actualizar el lugar de trabajo de conversión con los cambios del esquema y, luego, actualizar los trabajos de migración pertinentes. Para obtener más información, consulta
Cómo agregar un esquema o tablas actualizados al trabajo de migración.
Las sentencias SAVEPOINT no se admiten y pueden
causar discrepancias en los datos en caso de reversión.
Database Migration Service replica los tipos de datos definidos por el usuario, pero solo almacena el tipo de datos base del que derivas tus tipos definidos por el usuario.
Por ejemplo, si defines un tipo de datos USERNAME basado en el tipo de datos VARCHAR2, los datos se almacenan en el destino como VARCHAR.
Base de datos, transacciones y coherencia de los datos
La migración es coherente de forma eventual, ya que Database Migration Service no replica cada transacción a medida que ocurre. La migración incorpora datos de varias tablas. El orden en el que se cargan los datos en el destino puede variar, pero se vuelve a alinear con el origen después de que se detienen las escrituras en el origen y se borra el búfer de migración.
En el caso de las migraciones heterogéneas de Oracle, Database Migration Service solo puede migrar una base de datos por trabajo de migración.
Database Migration Service admite la arquitectura multiusuario de Oracle (CDB/PDB),
pero solo puedes migrar una sola base de datos conectable por trabajo de migración.
La seguridad de etiquetas de Oracle (OLS) no se replica.
La base de datos de destino debe tener el mismo nombre que el nombre de usuario que se usa para conectarse a la base de datos.
Es posible que las transacciones que se reviertan en tu base de datos de origen durante el proceso de migración se vean en el destino de forma temporal (cuando la transacción sea lo suficientemente larga).
Database Migration Service no admite la conectividad directa a bases de datos con la función Single Client Access Name (SCAN) en entornos de Oracle Real Application Clusters (RAC). Para conocer posibles soluciones para usar la conectividad de la lista de entidades permitidas de IP pública con esos entornos, consulta
Soluciona problemas de errores de SCAN de Oracle.
Codificación de datos
Database Migration Service solo admite codificaciones establecidas en UTF8 para la base de datos de destino. No se admiten los nombres de esquemas y tablas que incluyen caracteres que no forman parte del conjunto de codificación UTF8.
Database Migration Service admite las siguientes codificaciones de grupo de caracteres para bases de datos de Oracle:
AL16UTF16
AL32UTF8
IN8ISCII
IW8ISO8859P8
JA16SJIS
JA16SJISTILDE
KO16MSWIN949
US7ASCII
UTF8
WE8ISO8859P1
WE8ISO8859P9
WE8ISO8859P15
WE8MSWIN1252
ZHT16BIG5
Tablas, esquemas y otros objetos
Durante una migración, no se admiten los cambios en el lenguaje de definición de datos (DDL) en los datos, los esquemas ni los metadatos. Si actualizas tu esquema durante la migración,
debes extraer los cambios a tu lugar de trabajo de conversión, convertir el código,
limpiar tu destino y volver a ejecutar el trabajo de migración.
No se admiten nombres de columnas de tablas que incluyan caracteres distintos de caracteres alfanuméricos o un guion bajo (_).
La longitud máxima del nombre para las tablas o columnas es de 30 caracteres.
Database Migration Service no puede replicar tablas que superen este límite ni tablas
que contengan columnas cuyos nombres superen este límite.
No se admiten las tablas organizadas por índices (IOT).
Las tablas temporales globales requieren que la extensión pgtt de PostgreSQL esté instalada y creada en el destino.
En el caso de las columnas de tipo BFILE, solo se replicará la ruta de acceso al archivo. No se replicará el contenido del archivo.
En el caso de Oracle 11g, no se admiten las tablas que tienen columnas de tipos de datos ANYDATA o UDT, y no se replicará la tabla completa.
Se migran las definiciones de las vistas materializadas, pero no sus datos materializados. Después de terminar la migración, actualiza tus vistas materializadas para propagarlas con datos de las tablas migradas.
Se migran los valores de secuencia, pero sus valores en la base de datos de origen
podrían seguir avanzando antes de que se complete la migración. Después de completar la migración, actualiza los valores de secuencia en la instancia de destino para que coincidan con los de la base de datos de origen.
Los trabajos de migración se limitan a 10,000 tablas.
Las filas tienen un límite de tamaño de 100 MB. Las filas que superan el límite de 100 MB no se migran y aparecen como errores en el trabajo de migración.
Las tablas que se creen después de que se inicie la migración no se migrarán automáticamente. Primero, debes extraer su esquema en el espacio de trabajo de conversión,
aplicar las definiciones convertidas al destino y actualizar el trabajo de migración.
Limitaciones del tipo de datos
Los siguientes tipos de datos no son compatibles con las migraciones de Oracle:
ANYDATA (En Oracle 11g, las tablas con ANYDATA no se admiten en absoluto y no se replican).
BFILE
INTERVAL DAY TO SECOND
INTERVAL YEAR TO MONTH
LONG/LONG RAW
SDO_GEOMETRY
UDT
UROWID
XMLTYPE
Fechas cero en TIMESTAMP
Consideraciones sobre las claves primarias
Las tablas sin claves primarias no garantizan una replicación coherente.
Database Migration Service solo migra las tablas que tienen claves primarias.
Si tu base de datos de origen incluye tablas que no tienen claves primarias, los espacios de trabajo de conversión de Database Migration Service crean automáticamente las claves primarias faltantes en las tablas de destino cuando
conviertes tu código fuente y esquema.
Si utilizas espacios de trabajo de conversiones heredados, debes crear manualmente restricciones de clave principal en las tablas convertidas de la base de datos de destino antes de iniciar la migración. Para obtener más información, consulta
Espacios de trabajo de conversión heredados.
Consideraciones sobre las claves externas y los activadores
Las claves externas y los activadores presentes en tu base de datos de origen pueden generar problemas de integridad de los datos o incluso provocar que falle el trabajo de migración.
Puedes evitar estos problemas si omites las claves externas y los activadores
con la opción REPLICATION para el usuario de migración.
Como alternativa, también puedes descartar todas las claves externas y los activadores en la base de datos de destino y volver a crearlos cuando se complete la migración.
Activadores
Los datos replicados por Database Migration Service ya incorporan los cambios realizados por los activadores en la base de datos de origen. Si los activadores están habilitados en el destino, se pueden activar nuevamente y, potencialmente, manipular los datos, lo que genera problemas de integridad o duplicación de datos.
Claves externas
Database Migration Service no replica los datos de forma transaccional, por lo que es posible que las tablas se migren en un orden incorrecto. Si hay claves externas y se migra una tabla secundaria que usa una clave externa antes que su tabla principal, es posible que se produzcan errores de replicación.
Recomendaciones
Cuando
crees tu base de datos de Cloud SQL de destino,
asegúrate de usar suficientes recursos de procesamiento y memoria para cubrir tus
necesidades de migración. Recomendamos un tipo de máquina con al menos una CPU de doble núcleo.
Por ejemplo, si el nombre de tu máquina es db-custom y tiene
2 CPUs y 3, 840 MB de RAM, el formato para el nombre del tipo de máquina
será db-custom-2-3840.
La base de datos de Cloud SQL de destino se puede escribir durante la migración
para permitir que se apliquen los cambios del lenguaje de manipulación de datos (DML) si es necesario.
Ten cuidado de no realizar ningún cambio en la configuración de la base de datos ni en las estructuras de las tablas que puedan interrumpir el proceso de migración o afectar la integridad de los datos.
Cuotas
Pueden existir hasta 2,000 perfiles de conexión y 1,000 trabajos de migración en un momento determinado. Para liberar espacio, se pueden borrar trabajos de migración (incluso los que están completos)
y perfiles de conexión.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (UTC)"],[[["\u003cp\u003eDatabase Migration Service has limitations on supported characters, including only allowing \u003ccode\u003eUTF8\u003c/code\u003e encoding for the destination database, and not supporting table column names with non-alphanumeric characters or anything other than an underscore.\u003c/p\u003e\n"],["\u003cp\u003eThe service restricts migration jobs to a maximum of 10,000 tables, and only supports single pluggable database migration for Oracle multi-tenant architecture.\u003c/p\u003e\n"],["\u003cp\u003eCertain Oracle features, such as Index-organized tables, Oracle Autonomous Database, \u003ccode\u003eBFILE\u003c/code\u003e types, and many other data types are not supported or will be replaced with NULL values, and scheduled jobs or schema changes won't be migrated either.\u003c/p\u003e\n"],["\u003cp\u003eUp to 2,000 connection profiles and 1,000 migration jobs can exist at any given time, but if more is needed then previously completed migration jobs and connection profiles can be deleted.\u003c/p\u003e\n"],["\u003cp\u003eDirect connectivity to databases using Oracle Real Application Clusters (RAC) Single Client Access Name (SCAN) is not supported by Database Migration Service, and there is also a 100 MB row size limitation.\u003c/p\u003e\n"]]],[],null,["# Known limitations and recommendations\n\nThis page describes known limitations (including special considerations for\nhandling entities like\n[primary keys](#primary-keys-considerations) or\n[foreign keys and triggers](#foreign-keys-triggers-considerations)), as well as\n[recommended practices](#) for heterogeneous Oracle migrations with Database Migration Service.\n\nWhat isn't migrated\n-------------------\n\n- Users and permissions aren't migrated.\n- Schema changes that occur during an active migration job aren't automatically migrated. If you change your schema during the migration, you need to first update the conversion workspace with schema changes, and then refresh the relevant migration jobs. For more information, see [Add updated schema or tables to the migration job](/database-migration/docs/oracle-to-alloydb/manage-migration-jobs#edit-non-draft-job).\n- [`SAVEPOINT` statements](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SAVEPOINT.html) aren't supported and can cause data discrepancy in case of a rollback.\n- Database Migration Service replicates user-defined data types, but only stores the base data type from which you derive your user-defined types. For example, if you define a `USERNAME` data type based on the `VARCHAR2` data type, the data is stored in the destination as `VARCHAR`.\n\nDatabase, transactions and data consistency\n-------------------------------------------\n\n- The migration is eventually consistent, as Database Migration Service 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 re-aligns with the source after writes on the source are stopped and the migration buffer is cleared.\n- For heterogeneous Oracle migrations, Database Migration Service can only migrate one database per migration job.\n- Database Migration Service supports Oracle multi-tenant architecture (CDB/PDB), but you can only migrate a single pluggable database per migration job.\n- Oracle Label Security (OLS) isn't replicated.\n- The destination database must have the same name as the username that's used to connect to the database.\n- Any transactions that are rolled back in your source database during the migration process might be visible in the destination temporarily (when the transaction is long enough).\n- Database Migration Service doesn't support direct connectivity to databases using the Single Client Access Name (SCAN) feature in Oracle Real Application Clusters (RAC) environments. For potential solutions to using public IP allowlist connectivity with such environments, see [Troubleshoot Oracle SCAN errors](/database-migration/docs/oracle-to-alloydb/diagnose-issues#troubleshoot-scan).\n\nData encoding\n-------------\n\n- Database Migration Service supports only `UTF8` set encodings for the destination database. Schema and table names that include characters which aren't part of the `UTF8` encoding set are not supported.\n- Database Migration Service supports the following character set encodings for Oracle databases:\n - `AL16UTF16`\n - `AL32UTF8`\n - `IN8ISCII`\n - `IW8ISO8859P8`\n - `JA16SJIS`\n - `JA16SJISTILDE`\n - `KO16MSWIN949`\n - `US7ASCII`\n - `UTF8`\n - `WE8ISO8859P1`\n - `WE8ISO8859P9`\n - `WE8ISO8859P15`\n - `WE8MSWIN1252`\n - `ZHT16BIG5`\n\nTables, schemas, and other objects\n----------------------------------\n\n- During a migration, data definition language (DDL) changes to data, schemas, and metadata aren't supported. If you update your schema during the migration, you need to pull the changes to your conversion workspace, convert the code, clean your destination and run the migration job again.\n- Table column names that include characters other than alphanumeric characters or an underscore (`_`) aren't supported.\n- Maximum name length for tables or columns is 30 characters. Database Migration Service can't replicate tables that exceed this limit, or tables that contain columns whose names exceed this limit.\n- Index-organized tables (IOTs) aren't supported.\n- Global temporary tables require the `pgtt` PostgreSQL extension installed and created on the destination.\n- For columns of type `BFILE`, only the path to the file will be replicated. The contents of the file won't be replicated.\n- For Oracle 11g, tables that have columns of data types `ANYDATA` or `UDT` aren't supported, and the entire table won't be replicated.\n- Jobs that are scheduled by using [`dbms_job`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_JOB.html) or [`dbms_scheduler`](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_SCHEDULER.html) aren't migrated.\n- Materialized views definitions are migrated, but their materialized data isn't. After you finish migrating, refresh your materialized views in order to populate them with data from the migrated tables.\n- Sequence values are migrated, but their values in the source database might keep advancing before the migration is completed. After complete the migration, update the sequence values on the destination instance to match those in the source database.\n- Migration jobs are limited to 10,000 tables.\n- Rows have a size limitation of 100 MB. Rows that exceed the 100 MB limit are not migrated, and show up as errors in the migration job.\n- Any tables that are created after the migration has started aren't be migrated automatically. First, you need to pull their schema in the conversion workspace, apply converted definitions to the destination, and update the migration job.\n\n### Data type limitations\n\nThe following data types are unsupported for Oracle migrations:\n\n- `ANYDATA` (For Oracle 11g, tables with `ANYDATA` are completely unsupported and not replicated.)\n- `BFILE`\n- `INTERVAL DAY TO SECOND`\n- `INTERVAL YEAR TO MONTH`\n- `LONG/LONG RAW`\n- `SDO_GEOMETRY`\n- `UDT`\n- `UROWID`\n- `XMLTYPE`\n- **Zero dates** in `TIMESTAMP`\n\n### Considerations for primary keys\n\nTables without primary keys don't promise consistent replication.\nDatabase Migration Service migrates only tables that have primary keys.\nIf your source database includes tables that don't have primary keys,\nDatabase Migration Service conversion workspaces automatically create any missing\nprimary keys in the destination tables when you\n[convert your source code and schema](/database-migration/docs/oracle-to-alloydb/convert-sql).\n\nIf you use legacy conversion workspaces, you need to manually create primary\nkey constraints in the converted tables in the destination database before\nyou start the migration. For more information, see\n[Legacy conversion workspaces](/database-migration/docs/oracle-to-alloydb/legacy-conversion-workspaces).\n\n### Considerations for foreign keys and triggers\n\nForeign keys and triggers present in your source database might lead to\ndata integrity issues, or even cause the migration job to fail.\nYou can prevent these issues if you skip foreign keys and triggers\n[by using the `REPLICATION` option for the migration user](/database-migration/docs/oracle-to-alloydb/configure-your-destination-postgresql-database).\nAlternatively, you can also drop all foreign keys and triggers in the destination\ndatabase and re-create them when the migration is complete.\n\n#### Triggers\n\nData replicated by Database Migration Service already incorporates any changes made by\ntriggers on the source database. If triggers are enabled on the destination,\nthey can fire again and potentially manipulate data, resulting in data integrity\nor duplication issues.\n\n#### Foreign keys\n\nDatabase Migration Service doesn't replicate data in a transactional\nmanner, so tables might be migrated out of order. If foreign keys are present,\nand a child table that uses a foreign key is migrated before its parent, you might\nencounter replication errors.\n\nRecommendations\n---------------\n\n- When you [create your destination Cloud SQL database](/database-migration/docs/oracle-to-alloydb/configure-your-destination-postgresql-database), make sure that you use enough compute and memory resources to cover your migration needs. We recommend a machine type with at least a dual-core CPU.\n\n For example, if your machine name is `db-custom`, and it has\n 2 CPUs and 3840 MB of RAM, then the format for the machine type name\n is `db-custom-2-3840`.\n- The destination Cloud SQL database is writable during the migration to allow Data Manipulation Language (DML) changes to be applied if needed. Take care not to make any changes to the database configuration or table structures which might break the migration process or impact data integrity.\n\nQuotas\n------\n\n- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted."]]
