Planifique una migración de Oracle a Amazon RDS para Oracle mediante Oracle Data Pump y AWS DMS

En términos generales, las estrategias de migración de Amazon RDS para Oracle varían según su tolerancia al tiempo de inactividad de la transición. El tamaño de la base de datos, los tamaños de las tablas, los tipos de datos y la generación de archivos “redo log” desempeñan factores clave a la hora de determinar la ruta de migración adecuada. Para migraciones homogéneas de Oracle a Amazon RDS para Oracle, siempre que sea posible, se recomienda utilizar herramientas nativas como Oracle Data Pump y RMAN para obtener la mejor compatibilidad general. Cuando las herramientas nativas no son una opción, puede utilizar AWS Database Migration Service (AWS DMS) para la extracción completa inicial de los datos o para replicar los cambios de datos modificados (CDC) hacia la base de datos de destino.

La siguiente tabla resume los enfoques comúnmente recomendados para migrar Oracle a Amazon RDS para Oracle con un tiempo de afectación mínimo. Todos los enfoques que se enumeran a continuación son compatibles con los dispositivos de almacenamiento de la familia  AWS Snow  para transferir los conjuntos de datos iniciales a AWS. Los dispositivos portátiles AWS Snowcone  o AWS Snowball pueden ser una alternativa adecuada cuando las transferencias de red no son una opción.

Esta publicación analiza las consideraciones de planificación al utilizar Oracle Data Pump y DMS CDC para migrar a Amazon RDS para Oracle. Este método ofrece una estrategia de migración flexible que minimiza el impacto en la base de datos de origen y admite una ventana de migración manejable. Para ver un ejemplo paso a paso de cómo realizar este método de migración, consulte Migrando bases de datos Oracle con tiempo de inactividad casi nulo usando AWS DMS.

El siguiente diagrama ilustra la arquitectura relacionada con las consideraciones de planeación de esta publicación.

Descripción general de la migración

Los siguientes son los pasos de alto nivel para migrar bases de datos de Oracle a Amazon RDS para Oracle:

1. Se realiza una exportación inicial consistente de Oracle Data Pump en la base de datos de origen.
2. Los archivos de la exportación se transfieren al Servicio Simple de Almacenamiento (Amazon S3) a través de la red o mediante un dispositivo de la familia AWS Snow.
3. Los archivos se descargan desde S3 hacia la instancia de RDS para Oracle y se importan en la base de datos destino.
4. Se crea una tarea CDC en el DMS para capturar cambios delta de la base de datos de origen a partir de un flashback_scn o flashback_time inicial.
5. Una vez que la tarea CDC del DMS esté completamente actualizada con poco o ningún retraso de replicación, se puede programar una ventana de migración.

Licencia

Amazon RDS para Oracle admite dos modelos de licencia. Puede usar «Traiga su propia licencia”, por sus siglas en inglés (BYOL) si desea implementar bases de datos Oracle Enterprise o Standard Edición. Como alternativa, puede comprar instancias de Amazon RDS para Oracle con “Licencia incluida (LI)” si implementa Oracle Estándar Edición Uno o Estándar Edición Dos. Los contratos de licencia de Oracle pueden variar de un cliente a otro, por lo que siempre es mejor consultar con Oracle o con un especialista en licencias.

Planificación

El uso de Oracle Data Pump y AWS DMS CDC como estrategia de migración es beneficioso cuando la base de datos de origen está en el rango de tamaño de terabytes y la exportación inicial se puede transferir e importar a la base de datos de destino dentro de la ventana de retención de los “archive logs” de datos de origen. La transferencia de los archivos de exportación iniciales de Oracle Data Pump a AWS se puede realizar a través de una red de alta velocidad o mediante uno de los dispositivos de la familia  AWS Snow que se pueden enviar y conectar a su red en solo unos pocos días.

La cantidad de generación de archivos “redo logs” por hora en la base de datos de origen es otro factor importante que podría afectar el retraso de replicación del DMS CDC y extender la ventana de migración. La generación de archivos “redo log” a una tasa constante en la base de datos origen típicamente generan un retraso de replicación predecible que se puede manejar fácilmente.

Las cargas de procesamiento en “batch” intensas provocan una mayor variabilidad en el retraso de la replicación, lo que requiere más planificación y sincronización de la ventana de migración. Cuando las bases de datos de origen y de destino están indexadas correctamente y las tasas de cambio oscilan entre decenas y cientos de gigabytes por hora, la latencia de replicación de CDC de AWS DMS debería ser manejable y es posible una ventana de migración corta. Las siguientes son algunas áreas clave que se deben revisar para verificar una migración exitosa:

• AWS proporciona el script AWS DMS soporte de Oracle que genera toda la información relevante para una migración de este tipo. La ejecución de este script en las primeras etapas del proceso de evaluación puede ayudarle a generar confianza en su enfoque de migración. Se recomienda ejecutar el script y familiarizarse con todas las áreas importantes, incluidos los tipos de datos de origen en uso, las tablas modificadas con mayor frecuencia y el uso de LOB. Se puede revisar este resultado y compararlo con las limitaciones del uso de Oracle como fuente para AWS DMS.
• La ejecución de una tarea de evaluación de pre-migración en AWS DMS también es de vital importancia porque puede ayudar a revelar problemas potenciales con el enfoque de migración, como se muestra en la siguiente captura de pantalla.

• Se recomienda revisar las opciones de conectividad a Amazon VPC para comprobar que la conectividad de su red sea compatible con su estrategia de migración. Una opción de VPN de sitio a sitio puede ser adecuada para migraciones de bases de datos más pequeñas, pero AWS “Direct Connect” proporcionará velocidades de transferencia más rápidas y será más resistente a las interrupciones de la red. Transferir archivos de exportación de Oracle Data Pump de varios terabytes y replicar gigabytes de cambios de registros por hora puede ser un desafío en redes con poco ancho de banda.

Configuración de la base de datos de origen

Para obtener detalles sobre los permisos y la configuración necesarios para que AWS DMS CDC pueda capturar cambios en la base de datos de origen, consulte Trabajar con una base de datos autoadministrada como origen de AWS DMS.  Las siguientes son algunas áreas clave a las que se debe prestar atención:

• Ajuste la retención de archivos “archive logs” de la base de datos de origen para verificar que los registros de archivo estén disponibles para AWS DMS CDC. Esto significa que, si se necesitan cinco días para transferir y cargar la exportación inicial, la retención de los “archive logs” debe ser de al menos cinco días para que AWS DMS CDC comience a leer el archivo y rehacer los registros desde el momento en que se creó la exportación. Se debe tener en cuenta que el registro suplementario solo aumentará la cantidad de generación de “redo logs”.
• Al exportar datos mediante el uso de la utilidad expdp o la API DBMS_DATAPUMP, use la opción PARALLEL para acelerar la exportación. Si posee la licencia de compresión avanzada de Oracle, utilice la opción COMPRESS para reducir el tamaño de los archivos de volcado y acelerar la transferencia a AWS.
• Cuando utilice la opción PARALLEL, utilice el carácter comodín DUMPFILE (%U o similar) para permitir que Data Pump escriba en varios archivos de volcado simultáneos. Utilice el parámetro FILESIZE para limitar el tamaño de los archivos de exportación, ya que Amazon Simple Storage Service (Amazon S3) tiene un tamaño de archivo máximo de 5 TB y es más fácil administrar archivos pequeños.
• Revise la Configuración del registro suplementario para AWS DMS CDC. Las tablas sin una llave principal o un índice único en la tabla de origen pueden resultar problemáticas. En la base de datos de origen, se pueden agregar registros complementarios a todas las columnas de una tabla para evitar la falta de un identificador único.

Configuración de AWS DMS

En este escenario de migración, la instancia de replicación de AWS DMS y las tareas de AWS DMS solo replicarán los “redo logs” en función de un FLASHBACK_SCN o FLASHBACK_TIME inicial. La instancia de replicación debe tener un tamaño suficiente de CPU y memoria para las tareas que se ejecutan en ella. Las instancias de replicación se pueden aprovisionar basadas en instancias o  DMS sin servidor  cuando Oracle es tanto el motor de origen como el de destino. Las siguientes son algunas áreas claves en las que centrarse:

• Considere utilizar AWS DMS sin servidor para simplificar el tamaño de la instancia. Al momento de escribir este artículo, AWS DMS Sin servidor se puede configurar con hasta 16 unidades de capacidad (DCU) DMS, lo que equivale a 32 GB de memoria. Verifique las limitaciones de AWS DMS sin servidor para verificar que ninguna aplique en su escenario.
• Si el modelo basado en instancias de AWS DMS tiene más sentido, consulte Elegir la instancia de replicación de AWS DMS para su migración para obtener orientación sobre cómo elegir el tipo y tamaño de instancia correctos. AWS DMS intenta procesar el flujo de registros de CDC en la memoria cuando es posible, pero puede haber casos en los que los registros se escriban en la instancia de AWS DMS y por tanto, debe tener suficiente espacio en disco configurado.
• La tarea CDC de AWS DMS se puede configurar para leer desde la base de datos de origen mediante LogMiner o una configuración de lector binario. Revise la documentación Uso de Oracle LogMiner o AWS DMS lectura binaria para CDC para determinar la opción más adecuada.
• En términos generales, se puede configurar una única tarea de AWS DMS para procesar el flujo de registros de la base de datos de origen y aplicar los cambios en el destino. Sin embargo, cuando unas pocas tablas clave son responsables de la gran mayoría de los cambios de DML, es posible crear varias tareas de AWS DMS y utilizar reglas de selección de tablas para dividir un grupo de tablas en varias tareas y paralelizar el procesamiento de estos cambios. El script de AWS DMS soporte de Oracle tiene una sección que identifica las tablas con la mayor cantidad de modificaciones y, siempre que las tablas no tengan una dependencia de clave primaria o externa, se pueden configurar en múltiples tareas independientes de AWS DMS.
• En caso de tener instancias de replicación, supervise las métricas AWS DMS de AWS DMS, como CPUUtilization y FreeableMemory, para verificar que AWS DMS tenga suficientes recursos. Para AWS DMS Sin servidor, revise las métricas de replicación sin servidor como CapacidadUtilización.
• Puede producirse una latencia de CDC de AWS DMS superior a la esperada debido a varios motivos. Al investigar la latencia, el objetivo debe ser determinar primero si la latencia se debe a un problema en la base de datos de origen, la instancia o tarea de replicación de DMS o la base de datos de destino. En la base de datos de origen, las causas fundamentales comunes son una conectividad de red lenta o inestable con AWS, actualizaciones intensas de objetos binarios (LOB) de gran tamaño o una generación excesiva de redo logs limitada a unas pocas tablas. Durante la fase CDC de DMS, las actualizaciones de un único registro LOB pueden requerir múltiples viajes de ida y vuelta de la red, lo que afecta la latencia. Consulte Migración de objetos binarios grandes (LOBs) para obtener información adicional sobre cómo manejar LOB con DMS. Si hay tablas específicas que son responsables de la mayoría de los cambios de DML, configurar tareas DMS dedicadas a estas tablas puede ser una opción para mejorar el rendimiento y reducir la latencia. Una instancia de DMS que tenga un tamaño insuficiente o una sola tarea de CDC DMS que no sea adecuada para mantener el volumen, puede aumentar la latencia de replicación. Por último, pero no menos importante, en la base de datos de destino, la falta de índices, una instancia RDS de tamaño insuficiente o una instancia sin suficiente rendimiento de E/S pueden provocar aumentos en el retraso de la replicación. Puede monitorear métricas de las tareas de replicación y las métricas CDCLatencySource y CDCLatencyTarget para determinar qué componente de la migración es responsable del retraso.

Configuración de la base de datos de destino

El reloj de migración generalmente comienza cuando se ejecuta una exportación de Data Pump consistente usando un parámetro FLASHBACK_SCN o FLASHBACK_TIME en la base de datos de origen. En este punto, debe migrar los datos y sincronizar los cambios de CDC lo más rápido posible. Los siguientes son algunos factores importantes para preparar la base de datos de destino para este tipo de migración:

• Cree un nuevo grupo de parámetros de bases de datos   y un grupo de opciones   no predeterminados antes de crear la base de datos RDS de destino para Oracle. Al crear la base de datos de destino, utilice estos grupos no predeterminados para que más adelante se puedan realizar cambios de parámetros y opciones más fácilmente.
• Mejore el rendimiento de la importación inicial configurando la base de datos de destino en modo NOARCHIVELOG. Esto se logrará estableciendo la retención de la copia de seguridad en 0 días.
• Durante la importación inicial, configure la base de datos en Single-AZ. Multi-AZ permite una confirmación de dos fases a nivel de almacenamiento y podría ralentizar la importación de datos inicial.
• Cada base de datos de RDS para Oracle está configurada de forma predeterminada con cuatro archivos “redo log” de 128 MB. Si intenta importar bases de datos de varios terabytes, estos valores son demasiado pequeños y provocarán lentitud debido al cambio excesivo de registros y puntos de control. Puede utilizarlos procedimientos rdsadmin_util.add_logfile  y drop_logfile para agregar archivos “redo log” más grandes y eliminar los archivos más pequeños predeterminados.
• El parámetro redo log_buffer se puede configurar con un máximo de 256 MB. Durante el proceso de migración inicial, aumentar este valor puede ayudar a mejorar el rendimiento. Por ejemplo, en una instancia db.r5.2xlarge (64 GB de RAM), el log_buffer está preconfigurado en aproximadamente 111 MB y en el caso de una db.r5.xlarge (32 GB de RAM) está configurado en 50Mb. Estos valores pueden estar bien para cargas de trabajo diarias normales, pero para la carga inicial y CDC, valores más altos puede ser conveniente para obtener un mejor rendimiento.
• Considere la posibilidad de aprovisionar en exceso su entorno Oracle para la importación completa inicial y CDC. AWS ofrece una amplia gama de clases de instancias RDS para Oracle con diferentes velocidades de reloj de CPU y diferentes proporciones de CPU a memoria. Su instancia de RDS se puede reducir cuando el entorno se encuentra en un estado de replicación estable o después de la transición.
• Es importante probar y revisar las métricas CPUUtilization, ReadIOPS y WriteIOPS de la base de datos durante la importación inicial, una vez que el CDC haya estado en curso y en la fase de prueba de la aplicación antes de la transición. Si la utilización de la CPU supera el 80 % y la suma de las IOPS de lectura y escritura está cerca de lo que se aprovisionó, puede considerarse explorar un tipo de instancia más grande o una configuración de IOPS mayor.
• Las opciones de almacenamiento más comunes para entornos RDS Oracle son SSD de uso general (gp3) y SSD de IOPS provisionadas (io1). El almacenamiento GP3 es común para entornos inferiores, mientras que el almacenamiento io1 es más adecuado para entornos de producción. Consulte la documentación de almacenamiento en instancias de bases de datos RDS para obtener detalles adicionales sobre el rendimiento y la publicación del blog  Prueba de amazon RDS para Oracle: trazado de latencia e IOPS para patrón de E/S OLTP para obtener detalles específicos sobre cómo probar el almacenamiento RDS. En el contexto de las migraciones de Oracle, si la «sincronización del archivo de log» es un evento de espera superior en la base de datos de origen, entonces se deben realizar pruebas de E/S cuidadosas en la base de datos de destino para determinar la latencia de la confirmación.
• También se deben completar pruebas de rendimiento para actividades operativas comunes, como copias de seguridad, restauraciones y creación de réplicas de lectura, debido a la forma en que los volúmenes de EBS se hidratan a partir de instantáneas de S3.
• Al realizar la importación inicial de Data Pump en la base de datos de destino, considere configurar los siguientes parámetros de importación de Data Pump para mejorar el rendimiento y la visibilidad:
  • Configure SET_PARALLEL(hdnl, 8) para aumentar el número de trabajadores paralelos para mejorar el rendimiento de la importación. Es importante verificar que la instancia de RDS tenga suficiente CPU para admitir la configuración de paralelismo.
  • Configure el parámetro SET_PARAMETER(hdnl, ‘METRICS’, 1) para brindarle más visibilidad de los tiempos de creación de objetos en el registro de importación de Data Pump.
  • Configure el parámetro SET_PARAMETER(hdnl, ‘LOGTIME’, ‘ALL’) para que todas las entradas del registro tengan una marca de tiempo en el registro de importación de Data Pump.
  • No es raro que la creación del índice de Data Pump demore tanto o más que la importación de los datos de la tabla. Aunque agregar la configuración PARALLEL permite crear tablas e índices en paralelo, no hay paralelismo dentro del objeto de forma predeterminada. Esto significa que incluso para un índice grande, solo se asigna un trabajador para crearlo. Por este motivo, puede optar por generar los índices por separado de la importación, donde puede controlar el paralelismo dentro del índice con la sintaxis PARALLEL (DEGREE, N) de la instrucción CREATE INDEX. En cualquier caso, las configuraciones mencionadas anteriormente lo ayudarán a determinar el mejor enfoque:

Por ejemplo, en la siguiente captura de pantalla, vemos ocho trabajadores de Data Pump (W-N). Los datos de la tabla se importaron en aproximadamente 73 segundos (22:17:32–22:18:45) y la creación del índice tomó más tiempo, 113 segundos (22:18:45–22:20:38). Con este nivel de detalle, puede tomar una decisión informada sobre ir a una instancia RDS más grande, aumentar la configuración del parámetro PARALLEL o crear los índices fuera del proceso de importación de Data Pump.

Conclusión

Esta publicación cubrió los temas más comunes que se pasan por alto al migrar a Amazon RDS para Oracle mediante una combinación de la utilidad Data Pump nativa de Oracle y AWS DMS para CDC. Comprender las estructuras de tablas, índices y tipos de datos de la base de datos de origen, así como las tasas de generación de “redo log”, son clave para determinar si este método de migración híbrida se ajusta a sus expectativas de migración y transición.

Le recomendamos que explore la documentación sobre la migración de bases de datos de Oracle con AWS DMS y la ejecución de los scripts de evaluación y soporte mencionados en la sección Planificación de esta publicación. Para obtener más información y detalles de configuración sobre el uso de DMS y Oracle Data Pump, consulte Usando una base de datos de Oracle como fuente para AWS DMS   y   Buenas prácticas de Data Pump.

Acerca de lo autor

Peter Santos es arquitecto senior especialista en datos de Amazon Web Services. Antes de unirse a Amazon en 2020, trabajó en varios puestos de ingeniería de bases de datos y nube ayudando a las empresas a obtener valor de las soluciones de datos.