En esta página, se describen las limitaciones conocidas (incluidas las consideraciones especiales para controlar entidades como claves primarias 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 migran. Si cambias el esquema durante la migración, primero debes actualizar el lugar de trabajo de conversión con los cambios de esquema y, luego, actualizar los trabajos de migración pertinentes. Para obtener más información, consulta Agrega esquemas o tablas actualizados al trabajo de migración.
-
SAVEPOINTsentencias 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
USERNAMEbasado en elVARCHAR2tipo de datos, los datos se almacenan en el destino comoVARCHAR.
Base de datos, transacciones y coherencia de los datos
- La migración es coherente en última instancia, 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 la fuente después de que se detienen las escrituras en la fuente y se borra el búfer de migración.
- Para 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.
- No se replica Oracle Label Security (OLS).
- 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 revierten en tu base de datos de origen durante el proceso de migración sean visibles en el destino de forma temporal (cuando la transacción es 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 obtener posibles soluciones para usar la conectividad de la lista de entidades permitidas de IP públicas con esos entornos, consulta Soluciona problemas de errores de SCAN de Oracle.
Codificación de datos
- Database Migration Service solo admite codificaciones de conjuntos
UTF8para 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ónUTF8. - Database Migration Service admite las siguientes codificaciones de grupo de caracteres para bases de datos de Oracle
:
AL16UTF16AL32UTF8IN8ISCIIIW8ISO8859P8JA16SJISJA16SJISTILDEKO16MSWIN949US7ASCIIUTF8WE8ISO8859P1WE8ISO8859P9WE8ISO8859P15WE8MSWIN1252ZHT16BIG5
Tablas, esquemas y otros objetos
- Durante una migración, no se admiten los cambios del lenguaje de definición de datos (DDL) en los datos, los esquemas, y los metadatos. Si actualizas el esquema durante la migración, debes extraer los cambios al lugar de trabajo de conversión, convertir el código, limpiar el destino y volver a ejecutar el trabajo de migración.
- No se admiten los nombres de columnas de tablas que incluyen caracteres que no sean alfanuméricos
caracteres o un guion bajo (
_). - La longitud máxima del nombre para 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
pgttde PostgreSQL esté instalada y creada en el destino. - Para 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
ANYDATAoUDT, y no se replicará la tabla completa. - No se migran los trabajos programados con
dbms_jobodbms_scheduler. - Se migran las definiciones de vistas materializadas, pero no sus datos materializados isn't. Después de terminar la migración, actualiza las 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 pueden 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 una limitación 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.
- No se migrarán automáticamente las tablas que se creen después de que comience la migración. Primero, debes extraer su esquema en el lugar 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 el caso de Oracle 11g, las tablas conANYDATAno son compatibles y no se replican).BFILEINTERVAL DAY TO SECONDINTERVAL YEAR TO MONTHLONG/LONG RAWSDO_GEOMETRYUDTUROWIDXMLTYPE- Fechas cero en
TIMESTAMP
Consideraciones sobre las claves primarias
Las tablas sin claves primarias no prometen una replicación coherente.
Database Migration Service solo migra tablas que tienen claves primarias.
Si tu base de datos de origen incluye tablas que no tienen claves primarias,
los lugares de trabajo de conversión de Database Migration Service crean automáticamente las claves primarias faltantes en las tablas de destino cuando
conviertes el código fuente y el esquema.
También puedes inhabilitar la generación automática de clave primaria con la
GENERATE_MISSING_PK directiva de conversión.
Si usas lugares de trabajo de conversión heredados, debes crear manualmente restricciones de clave primaria en las tablas convertidas de la base de datos de destino antes de iniciar la migración. Para obtener más información, consulta Lugares 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 la falla del 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, pueden activarse de nuevo y, potencialmente, manipular los datos, lo que genera problemas de integridad de los datos o duplicación.
Claves externas
Database Migration Service no replica los datos de forma transaccional, por lo que las tablas se pueden migrar fuera de orden. Si hay claves externas y se migra una tabla secundaria que usa una clave externa antes que su superior, 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-customy tiene 2 CPUs y 3, 840 MB de RAM, el formato para el nombre del tipo de máquina esdb-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 cambios en la configuración de la base de datos ni en las estructuras de 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.