Limitaciones y recomendaciones conocidas

En esta página, se describen las limitaciones conocidas (incluidas las consideraciones especiales para manejar 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. Si cambias el esquema durante la migración, primero debes actualizar el espacio 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 un esquema o tablas actualizados al trabajo de migración.
  • No se admiten las declaraciones SAVEPOINT y pueden causar discrepancias de datos en caso de una reversión.
  • Database Migration Service replica los tipos de datos definidos por el usuario, pero solo almacena el tipo de datos base del que derivan los tipos definidos por el usuario. Por ejemplo, si defines un tipo de datos USERNAME según 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 operaciones de escritura 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 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.
  • Cualquier transacción que se revierta en la base de datos de origen durante el proceso de migración puede ser visible en el destino de forma temporal (cuando la transacción es lo suficientemente larga).
  • Database Migration Service no admite la conectividad directa a las bases de datos con la función de nombre de acceso de cliente único (SCAN) en entornos de Oracle Real Application Clusters (RAC). Para conocer las posibles soluciones para usar la conectividad de la lista de IPs públicas permitidas con esos entornos, consulta Soluciona problemas de errores de SCAN de Oracle.

Codificación de datos

  • Database Migration Service solo admite codificaciones de conjuntos UTF8 para la base de datos de destino. No se admiten los nombres de esquemas y tablas que incluyan caracteres que no formen parte del conjunto de codificación UTF8.
  • Database Migration Service admite las siguientes codificaciones de grupo de caracteres para las 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 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 en tu espacio 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 incluyan caracteres que no sean alfanuméricos o un guion bajo (_).
  • La longitud máxima del nombre de 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.
  • Para las columnas de tipo BFILE, solo se replicará la ruta de acceso al archivo. No se replicará el contenido del archivo.
  • En Oracle 11g, no se admiten las tablas que tienen columnas de tipos de datos ANYDATA o UDT, y no se replicará toda la tabla.
  • No se migran los trabajos que se programan con dbms_job o dbms_scheduler.
  • Las definiciones de las vistas materializadas se migran, pero sus datos materializados no. Después de finalizar la migración, actualiza las vistas materializadas para completarlas con datos de las tablas migradas.
  • Los valores de secuencia se migran, 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 están limitados 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.
  • Las tablas que se creen después de que se haya iniciado 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.
  • Las columnas virtuales (GENERATED ALWAYS AS (...) VIRTUAL) no se replican durante la migración de datos porque Oracle no escribe valores de columnas virtuales en los registros de rehacer. Si una columna virtual forma parte de una clave primaria compuesta, solo las columnas no virtuales se usan como clave primaria durante la replicación.

Limitaciones del tipo de datos

Los siguientes tipos de datos no son compatibles con las migraciones de Oracle:

  • ANYDATA (Para Oracle 11g, las tablas con ANYDATA no se admiten por completo ni se replican).
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • Fechas cero en TIMESTAMP

Consideraciones para 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 que faltan en las tablas de destino cuando conviertes el código fuente y el esquema. Este proceso automatizado requiere que tus tablas de origen cumplan con las siguientes condiciones:

  • No tienen claves primarias.
  • No tengas una restricción UNIQUE sin columnas que admitan valores nulos.
  • No tengas un índice UNIQUE sin columnas que admitan valores nulos.

Si tus tablas no cumplen con estos requisitos, debes agregar de forma manual las claves primarias faltantes a las tablas en el esquema de PostgreSQL convertido. También puedes inhabilitar la generación automática de clave primaria con la directiva de conversión GENERATE_MISSING_PK.

Si usas espacios de trabajo de conversión heredados, debes crear restricciones de clave primaria de forma manual en las tablas convertidas en 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, hacer 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, pueden volver a activarse y, posiblemente, manipular datos, lo que genera problemas de integridad de los datos o duplicación de datos.

Claves externas

Database Migration Service no replica los datos de forma transaccional, por lo que las tablas se pueden migrar sin orden. Si hay claves externas presentes y se migra una tabla secundaria que usa una clave externa antes que su tabla 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-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 cambios en el 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 las tablas, ya que esto podría interrumpir el proceso de migración o afectar la integridad de los datos.

Cuotas

  • Puede haber hasta 2,000 perfiles de conexión y 1,000 trabajos de migración en cualquier momento. Para crear espacio para más, se pueden borrar los trabajos de migración (incluidos los completados) y los perfiles de conexión.