Prácticas recomendadas para AWS Database Migration Service

Para sacar el máximo partido de AWS Database Migration Service (AWS DMS), consulte las recomendaciones de esta sección sobre la manera más provechosa de migrar sus datos.

Planificación de la migración con AWS Database Migration Service

A la hora de planificar la migración de una base de datos con AWS Database Migration Service, tenga en cuenta lo siguiente:

• Para conectar las bases de datos de origen y de destino a una instancia de replicación de AWS DMS, configure una red. Esto puede ser tan sencillo como conectar dos recursos de AWS en la misma nube privada virtual (VPC) que la instancia de replicación. Puede abarcar configuraciones más complejas, como conectar una base de datos en las instalaciones a una instancia de base de datos de Amazon RDS a través de una red privada virtual (VPN). Para obtener más información, consulte Configuraciones de red para migrar bases de datos.

• Puntos de conexión de origen y destino: asegúrese de saber qué información y tablas de la base de datos de origen deben migrarse a la base de datos de destino. AWS DMS admite la migración básica de esquemas, incluida la creación de tablas y claves principales. Sin embargo, AWS DMS no crea automáticamente índices secundarios, claves externas, cuentas de usuario, etc. en la base de datos de destino. En función del motor de base de datos de origen y de destino, es posible que tenga que configurar el registro complementario o modificar otra configuración para una base de datos de destino o de origen. Para obtener más información, consulte Orígenes para la migración de datos y Destinos para la migración de datos.

• Migración de esquemas y códigos: AWS DMS no realiza conversiones de esquemas o códigos. Puede utilizar herramientas como Oracle SQL Developer, MySQL Workbench y pgAdmin III para convertir el esquema. Para convertir un esquema existente en un motor de base de datos diferente, puede utilizar AWS Schema Conversion Tool (AWS SCT). Puede crear un esquema de destino y puede generar y crear un esquema completo: tablas, índices, vistas, etc. También puede utilizar la herramienta para convertir PL/SQL o TSQL en PgSQL y otros formatos. Para obtener más información sobre AWS SCT, consulte la Guía del usuario de AWS SCT.

• Tipos de datos no compatibles: asegúrese de poder convertir los tipos de datos de origen en tipos de datos equivalentes para la base de datos de destino. Para obtener más información sobre los tipos de datos admitidos, consulte la sección de origen o destino para el almacén de datos.

• Resultados de los scripts de soporte de diagnóstico: cuando planifique la migración, le recomendamos que ejecute scripts de soporte de diagnóstico. Con los resultados de estos scripts, puede encontrar información avanzada sobre posibles errores de migración.

  Si hay un script de soporte disponible para la base de datos, descárguelo mediante el enlace que aparece en el tema correspondiente del script en la siguiente sección. Tras comprobar y revisar el script, puede ejecutarlo según el procedimiento descrito en el tema del script en el entorno local. Cuando se complete la ejecución del script, puede revisar los resultados. Recomendamos ejecutar estos scripts como primer paso de cualquier intento de solución de problemas. Los resultados pueden ser útiles cuando se trabaja con un equipo de AWS Support. Para obtener más información, consulte Trabajar con scripts de soporte de diagnóstico en AWS DMS.

• Evaluaciones previas a la migración: una evaluación previa a la migración evalúa los componentes específicos de una tarea de migración de bases de datos para ayudar a identificar cualquier problema que pueda impedir que una tarea de migración se ejecute según lo esperado. Mediante esta evaluación, puede identificar posibles problemas antes de ejecutar una tarea nueva o una tarea modificada. Para obtener más información sobre cómo trabajar con las evaluaciones previas a la migración, consulte Habilitación de las evaluaciones previas a la migración para una tarea y trabajar con ellas.

Convertir esquemas

AWS DMS no convierte ni los esquemas ni el código. Si desea convertir un esquema existente en un motor de base de datos diferente, puede usar AWS SCT. AWS SCT convierte los objetos de origen, la tabla, los índices, las vistas, los desencadenadores y otros objetos del sistema al formato de lenguaje de definición de datos (DDL) de destino. También puede utilizar AWS SCT para convertir la mayor parte del código de aplicación, como PL/SQL o TSQL, en el lenguaje de destino equivalente.

Puede obtener AWS SCT como descarga gratuita de AWS. Para obtener más información sobre AWS SCT, consulte la Guía del usuario de AWS SCT.

Si los puntos finales de origen y destino están en el mismo motor de base de datos, puede utilizar herramientas como Oracle SQL Developer, MySQL Workbench o PgAdmin 4 para mover el esquema.

Revisión de la documentación pública de AWS DMS

Le recomendamos encarecidamente que consulte las páginas de documentación pública de AWS DMS de los puntos de conexión de origen y destino antes de realizar la primera migración. Esta documentación puede ayudarle a identificar los requisitos previos para la migración y a comprender las limitaciones actuales antes de empezar. Para obtener más información, consulte Trabajo con puntos de conexión de AWS DMS.

Durante la migración, la documentación pública puede ayudarle a solucionar cualquier problema que pueda surgir con AWS DMS. Las páginas de solución de problemas de la documentación pueden ayudarle a resolver problemas comunes al utilizar bases de datos de AWS DMS y de puntos de conexión seleccionados. Para obtener más información, consulte Solución de problemas de tareas de migración en AWS Database Migration Service.

Ejecución de una prueba de concepto

Para ayudar a detectar problemas con el entorno en las primeras fases de la migración de la base de datos, le recomendamos que ejecute una pequeña migración de prueba. De este modo, también puede ayudarle a establecer un calendario de migración más realista. Además, es posible que necesite realizar una migración de prueba a gran escala para medir si AWS DMS puede gestionar el rendimiento de la base de datos a través de la red. Durante este tiempo, le recomendamos que compare y optimice la carga completa inicial y la replicación continua. Esto puede ayudarle a comprender la latencia de la red y a medir el rendimiento general.

En este punto, también tendrá la oportunidad de comprender el perfil de datos y el tamaño de la base de datos, incluidos los siguientes aspectos:

• Cuántas tablas son grandes, medianas y pequeñas.

• Cómo AWS DMS gestiona las conversiones de tipos de datos y conjuntos de caracteres.

• Cuántas tablas tienen columnas de objetos grandes (LOB).

• Cuánto tiempo se tarda en ejecutar una migración de prueba.

Mejora del rendimiento de una migración de AWS DMS

Hay una serie de factores que afectan al desempeño del proceso de migración con AWS DMS:

• Disponibilidad de recursos en el origen.

• El rendimiento de la red disponible.

• La capacidad de los recursos del servidor de replicación.

• La capacidad del sistema de destino para incorporar cambios.

• El tipo y la distribución de los datos de origen.

• El número de objetos que se van a migrar.

Puede mejorar el desempeño si se siguen algunas o todas las prácticas recomendadas que se mencionan a continuación. Si se puede utilizar una de estas prácticas depende del caso de uso específico. Puede encontrar algunas limitaciones a continuación:

Aprovisionamiento de un servidor de replicación adecuado

AWS DMS es un servicio administrado que se ejecuta en una instancia de Amazon EC2. Este servicio se conecta a la base de datos de origen, lee los datos de origen, los formatea para que la base de datos de destino pueda consumirlos y los carga en la base de datos de destino.

La mayor parte de este procesamiento ocurre en la memoria. No obstante, es posible que en las transacciones de mayor volumen se precise almacenar en la memoria búfer del disco. Las transacciones almacenadas en caché y los archivos de registro también se escriben en el disco. En las siguientes secciones, puede encontrar qué debe tener en cuenta al elegir el servidor de replicación.

CPU

AWS DMS está diseñado para migraciones heterogéneas, pero también admite migraciones homogéneas. Para realizar una migración homogénea, primero convierta cada tipo de datos de origen en su tipo de datos de AWS DMS equivalente. A continuación, convierta cada dato de tipo AWS DMS en el tipo de datos de destino. Puede encontrar referencias sobre estas conversiones para cada motor de base de datos en la Guía del usuario de AWS DMS.

Para AWS DMS para realizar estas conversiones de forma óptima, la CPU debe estar disponible cuando se producen las conversiones. La sobrecarga de la CPU y la falta de recursos de CPU suficientes pueden provocar migraciones lentas, lo que también puede provocar otros efectos secundarios.

Clase de instancia de replicación

Algunas de las clases de instancias más pequeñas son suficientes para probar el servicio o para pequeñas migraciones. Si la migración conlleva muchas tablas o si va a ejecutar varias tareas de replicación simultáneas, considere el uso de una de las instancias más grandes. Una instancia más grande puede ser una buena idea porque el servicio consume una cantidad considerable de memoria y CPU.

Las instancias de tipo T2 se han diseñado para ofrecer un rendimiento de referencia moderado y la capacidad de poder ampliarlo a un nivel considerablemente superior si así lo exige la carga de trabajo. Están pensadas para las cargas de trabajo que no utilizan toda la CPU con frecuencia o de forma continua, pero que de vez en cuando necesitan ampliar sus procesos. Las instancias T2 son adecuadas para cargas de trabajo de uso general, como servidores web, entornos de desarrollo y bases de datos pequeñas. Si soluciona un problema de migración lenta y utiliza un tipo de instancia T2, compruebe la métrica de uso de la CPU del host. Puede mostrarle si está sobrepasando la línea base para ese tipo de instancia.

Las clases de instancia C4 se han diseñado para proporcionar el mayor nivel de desempeño del procesador para cargas de trabajo que hacen uso intensivo del equipo. Logran un rendimiento muy superior en cuanto a paquetes por segundo (PPS), menor inestabilidad de la red y menor latencia de la red. AWS DMS puede requerir un uso intensivo de la CPU, especialmente cuando se realizan migraciones y replicaciones heterogéneas, como la migración de Oracle a PostgreSQL. Las instancias C4 pueden ser una buena opción para estas situaciones.

Las clases de instancia R4 tienen optimizada la memoria para cargas de trabajo que hacen un uso intensivo de la memoria. Las migraciones continuas o las replicaciones de sistemas de transacción de alto rendimiento que utilizan AWS DMS pueden, a veces, consumir gran cantidad de CPU y de memoria. Las instancias R4 incluyen más memoria por vCPU.

Compatibilidad con AWS DMS para clases de instancias R5 y C5

Las clases de instancias de R5 son instancias optimizadas para memoria diseñadas para ofrecer un rendimiento rápido para cargas de trabajo que procesan grandes conjuntos de datos en memoria. Las migraciones continuas o las replicaciones de sistemas de transacción de alto rendimiento que utilizan AWS DMS pueden, a veces, consumir gran cantidad de CPU y de memoria. Las instancias R5 ofrecen un 5 % más de memoria por vCPU que las R4 y las de mayor tamaño proporcionan 768 GiB de memoria. Además, las instancias R5 ofrecen una mejora del 10 % en el precio por GiB y un aumento de aproximadamente un 20 % en el rendimiento de la CPU en comparación con las instancias R4.

Las clases de instancias C5 están optimizadas para cargas de trabajo con uso intensivo de cómputo y ofrecen un alto rendimiento rentable a un precio bajo por cómputo. Logran un rendimiento de red significativamente superior. El Elastic Network Adapter (ENA) proporciona a las instancias C5 hasta 25 Gbps de ancho de banda de la red y hasta 14 Gbps de ancho de banda dedicado a Amazon EBS. AWS DMS puede requerir un uso intensivo de la CPU, especialmente cuando se realizan migraciones y replicaciones heterogéneas, como la migración de Oracle a PostgreSQL. Las instancias C5 pueden ser una buena opción para estas situaciones.

Almacenamiento

En función de la clase de instancia, el servidor de replicación viene con 50 GB o 100 GB de almacenamiento de datos. Este espacio se usa para almacenar los archivos de registro y los cambios almacenados en caché que se recopilan durante la carga. Si el sistema de origen está ocupado o realiza grandes transacciones, es posible que necesite aumentar el almacenamiento. Si ejecuta varias tareas en el servidor de replicación, es posible que también necesite aumentar el almacenamiento. Sin embargo, la cantidad predeterminada suele ser suficiente.

Todos los volúmenes de almacenamiento en AWS DMS son unidades de estado sólido (SSD) GP2 o de uso general. Los volúmenes GP2 ofrecen un rendimiento básico de tres operaciones de E/S por segundo (IOPS), con la capacidad de generar ráfagas de hasta 3000 IOPS en función del crédito. Como regla general, compruebe las métricas ReadIOPS y WriteIOPS para la instancia de replicación. Asegúrese de que la suma de estos valores no supere el rendimiento base de ese volumen.

Multi-AZ

La elección de una instancia Multi-AZ puede proteger la migración de los errores de almacenamiento. La mayoría de las migraciones son transitorias y no están diseñadas para ejecutarse durante largos periodos de tiempo. Si utiliza AWS DMS con fines de replicación continua, la elección de una instancia Multi-AZ puede mejorar su disponibilidad en caso de que se produzca un problema de almacenamiento.

Si se utiliza una instancia de replicación en una sola AZ o en Multi-AZ durante una CARGA COMPLETA y se produce una conmutación por error o un reemplazo del host, se espera que la tarea de carga completa no se realice correctamente. Puede reiniciar la tarea desde el punto en el que se produjo el error para las tablas restantes que no se completaron o que están en un estado de error.

Carga de varias tablas en paralelo

De forma predeterminada, AWS DMS carga ocho tablas a la vez. Podrá observar cierta mejora en el desempeño si aumenta ligeramente este valor cuando utilice un servidor de replicación muy grande, como una instancia dms.c4.xlarge o más grande. No obstante, llegará un momento en que si sigue aumentando este paralelismo, el desempeño será inferior. Si el servidor de replicación es relativamente pequeño, como dms.t2.medium, le recomendamos que reduzca el número de tablas cargadas en paralelo.

Para cambiar este número en la AWS Management Console, abra la consola, elija Tareas, elija crear o modificar una tarea y, a continuación, elija Configuración avanzada. En Tuning Settings (Configuración de ajuste), cambie la opción Maximum number of tables to load in parallel (Número máximo de tablas que se pueden cargar en paralelo).

Para cambiar este número con AWS CLI, cambie el parámetro MaxFullLoadSubTasks en TaskSettings.

Uso de carga completa paralela

Puede utilizar una carga paralela desde orígenes de Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW basados en particiones y subparticiones. De este modo, se puede mejorar la duración total de la carga. Además, al ejecutar una tarea de migración de AWS DMS, puede acelerar la migración de tablas grandes o particionadas. Para ello, divida la tabla en segmentos y cargue los segmentos en paralelo en la misma tarea de migración.

Para utilizar una carga en paralelo, cree una regla de asignación de tablas de tipo table-settings con la opción parallel-load. Dentro de la regla table-settings, especifique los criterios de selección para la tabla o las tablas que desea cargar en paralelo. Para especificar los criterios de selección, establezca el elemento type para parallel-load en una de las siguientes configuraciones:

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Para obtener más información sobre estas configuraciones, consulte Reglas y operaciones de configuración de tablas y recopilaciones.

Trabajo con índices, desencadenadores y restricciones de integridad referencial

Los índices, los disparadores y los límites de integridad referencial pueden afectar al desempeño de la migración y hacer que la migración provoque un error. La forma en que esto afecta a la migración depende de si la tarea de replicación es una tarea de carga completa o una tarea de replicación continua (captura de datos de cambios o CDC).

Para una tarea de carga completa, le recomendamos que elimine los índices de clave primaria, los índices secundarios, los límites de integridad referencial y los disparadores del lenguaje de manipulación de datos (DML). O puede retrasar su creación hasta que las tareas de carga completa se hayan completado. No necesita índices durante una tarea de carga completa y los índices generan una sobrecarga de mantenimiento si están presentes. Dado que la tarea de carga completa carga grupos de tablas de una vez, se infringen los límites de integridad referencial. Del mismo modo, los desencadenadores INSERT, UPDATE y DELETE pueden producir errores, por ejemplo, si se desencadena una inserción de fila para una tabla que se haya cargado de forma masiva previamente. Otros tipos de disparadores también afectan al desempeño debido al procesamiento añadido.

Si los volúmenes de datos son relativamente pequeños y el tiempo de migración adicional no es un problema, puede crear índices de clave principal y secundarios antes de una tarea de carga completa. Desactive siempre los límites y los desencadenadores de integridad referencial.

Para una tarea de carga completa más CDC, le recomendamos que agregue índices secundarios antes de la fase de CDC. Dado que AWS DMS utiliza la replicación lógica, asegúrese de que los índices secundarios que admiten operaciones de DML están en su lugar para evitar los análisis de tablas completas. Puede detener la tarea de replicación antes de la fase de CDC para crear índices y crear límites de integridad referencial antes de reiniciar la tarea.

Debería habilitar los desencadenadores justo antes de la transición.

Desactivar las copias de seguridad y el registro de transacciones

Al migrar a una base de datos de Amazon RDS, es conveniente desactivar las copias de seguridad y Multi-AZ en el destino hasta que todo esté preparado para realizar el traspaso. Del mismo modo, cuando se migra a sistemas que no son Amazon RDS, es aconsejable desactivar los registros en el destino hasta después del momento de la transición.

Usar varias tareas

En ocasiones, el uso de varias tareas para una sola migración puede mejorar el desempeño. Si tiene conjuntos de tablas que no participan en transacciones comunes, es posible que pueda dividir la migración en varias tareas. La coherencia transaccional se mantiene dentro de una tarea, por lo que es importante que las tablas de tareas independientes no participen en transacciones comunes. Además, cada tarea leerá de manera independiente la secuencia de transacciones, por lo que habrá que tener la precaución de no exigir demasiado a la base de datos de origen.

Puede usar varias tareas para crear flujos de replicación independientes. De este modo, puede paralelizar las lecturas del origen, los procesos de la instancia de replicación y las escrituras en la base de datos de destino.

Optimización del procesamiento de cambios

De forma predeterminada, AWS DMS procesa los cambios en un modo transaccional, para garantizar la integridad transaccional. Si puede permitirse interrupciones temporales en la integridad de las transacciones, active la opción de aplicación optimizada por lotes. Para resultar más eficaz, esta opción agrupa las transacciones y las aplica en lotes. El uso de la opción de aplicación optimizada por lotes casi siempre infringe las restricciones de integridad referencial. Por lo tanto, le recomendamos que desactive estas restricciones durante el proceso de migración y las vuelva a activar como parte del proceso de transición.

Uso de su propio servidor de nombres en las instalaciones

Por lo general, una instancia de replicación de AWS DMS utiliza la resolución del sistema de nombres de dominio (DNS) en una instancia de Amazon EC2 para resolver los puntos de conexión del dominio. Sin embargo, puede utilizar su propio servidor de nombres en las instalaciones para resolver determinados puntos de conexión si utiliza Amazon Route 53 Resolver. Con esta herramienta, puede realizar consultas en las instalaciones y AWS mediante puntos de conexión entrantes y salientes, reglas de reenvío y una conexión privada. Entre las ventajas de utilizar un servidor de nombres en las instalaciones se incluyen la mejora de la seguridad y la facilidad de uso tras un firewall.

Si tiene puntos de conexión entrantes, puede utilizar consultas de DNS que se originen en las instalaciones para resolver los dominios alojados en AWS. Para configurar los puntos de conexión, asigne direcciones IP a cada subred a la que desea proporcionar un solucionador. Para establecer la conectividad entre la infraestructura de DNS en las instalaciones y AWS, utilice AWS Direct Connect o una red privada virtual (VPN).

Los puntos de conexión salientes se conectan al servidor de nombres en las instalaciones. El servidor de nombres solo permite el acceso a las direcciones IP incluidas en una lista de direcciones permitidas y configuradas en un punto de conexión de salida. La dirección IP de su servidor de nombres es la dirección IP de destino. Al elegir un grupo de seguridad para un punto de conexión de salida, elija el mismo grupo de seguridad que utiliza la instancia de replicación.

Para reenviar dominios seleccionados al servidor de nombres, use las reglas de reenvío. Un punto de conexión saliente puede gestionar múltiples reglas de reenvío. El ámbito de la regla de reenvío es la nube privada virtual (VPC). Al usar una regla de reenvío asociada a una VPC, puede aprovisionar una sección de la nube aislada de forma lógica de la nube de AWS. Desde esta sección aislada de forma lógica, puede lanzar recursos de AWS en una red virtual.

Puede configurar dominios alojados en la infraestructura de DNS en las instalaciones como reglas de reenvío condicional que configuran las consultas de DNS salientes. Cuando se realiza una consulta a uno de esos dominios, las reglas desencadenan un intento de reenviar solicitudes DNS a servidores configurados con las reglas. De nuevo, se requiere una conexión privada a través AWS Direct Connect o VPN.

En el siguiente diagrama se muestra la arquitectura de Route 53 Resolver.

Para obtener más información acerca de Route 53 DNS Resolver, consulte Introducción a Route 53 Resolver en la Guía para desarrolladores de Amazon Route 53.

Uso de Amazon Route 53 Resolver con AWS DMS

Puede crear un servidor de nombres en las instalaciones para que AWS DMS resuelva los puntos de conexión con Amazon Route 53 Resolver.

Creación de un servidor de nombres en las instalaciones para AWS DMS basado en Route 53

1. Inicie sesión en AWS Management Console y abra la consola de Route 53 en https://console.aws.amazon.com/route53/.

2. En la consola de Route 53, elija la región de AWS en la que desea configurar Route 53 Resolver. Route 53 Resolver es específico de una región.

3. Elija la dirección de la consulta: de entrada, de salida o ambas.

4. Proporcione la configuración de la consulta entrante:

   1. Escriba un nombre de punto de conexión y elija una VPC.

   2. Asigne una o más subredes desde dentro de la VPC (por ejemplo, elija dos para la disponibilidad).

   3. Asigne direcciones IP específicas para utilizarlas como puntos de conexión o haga que Route 53 Resolver las asigne automáticamente.

5. Cree una regla para su dominio local para que las cargas de trabajo dentro de la VPC puedan enrutar consultas de DNS a su infraestructura de DNS.

6. Ingrese una o más direcciones IP para los servidores DNS en las instalaciones.

7. Envíe la regla.

Cuando todo está creado, la VPC está asociada con las reglas de entrada y salida y puede comenzar a enrutar el tráfico.

Para obtener más información acerca de Route 53 Resolver, consulte Introducción a Route 53 Resolver en la Guía para desarrolladores de Amazon Route 53.

Migración de objetos binarios grandes (LOB)

En general, AWS DMS migra los datos de LOB en dos fases:

1. AWS DMS crea una nueva fila de la tabla de destino y la rellena con todos los datos, excepto el valor de LOB asociado.

2. AWS DMS actualiza la fila en la tabla de destino con los datos de LOB.

Este proceso de migración para los LOB requiere que, durante el proceso, todas las columnas de LOB de la tabla de destino sean NULLABLE. Esto es así aunque las columnas de LOB no sean NULLABLE en la tabla de origen. Si AWS DMS crea las tablas de destino, define las columnas de LOB como NULLABLE de forma predeterminada. En algunos casos, es posible que cree tablas de destino mediante algún otro mecanismo, como la importación o la exportación. En esos casos, asegúrese de que las columnas de LOB pueden contener valores nulos antes de iniciar la tarea de migración.

Este requisito tiene una excepción. Supongamos que realiza una migración homogénea desde un origen de Oracle a un destino de Oracle y elige Limited Lob mode (Modo de LOB limitado). En este caso, la totalidad de la fila se rellena a la vez, incluido cualquier valor de LOB. En tal caso, AWS DMS puede crear las columnas de LOB de la tabla de destino con restricciones NOT NULL, en caso necesario.

Uso del modo LOB limitado

AWS DMS utiliza dos métodos que equilibran el rendimiento y la comodidad cuando la migración contiene valores de LOB:

1. Limited LOB mode (Modo LOB limitado) migra todos los valores LOB hasta un límite de tamaño especificado por el usuario (el valor predeterminado es 32 KB). Los valores LOB que superen el límite de tamaño deben migrarse manualmente. Normalmente, el valor predeterminado de Limited LOB mode (Modo de LOB limitado) para todas las tareas de migración proporciona el mejor desempeño. Sin embargo, asegúrese de que la configuración del parámetro Tamaño máximo de LOB sea correcta. Establezca este parámetro en el tamaño de LOB más grande para todas las tablas.

2. Full LOB mode (Modo de LOB completo) migra todos los datos LOB de las tablas, independientemente de su tamaño. Full LOB mode (Modo de LOB completo) resulta conveniente porque traslada todos los datos LOB de las tablas, si bien el proceso puede tener un impacto significativo en el desempeño.

Para algunos motores de base de datos, como PostgreSQL, AWS DMS trata los tipos de datos JSON como LOB. Asegúrese de que si ha elegido Modo de LOB limitado, la opción Tamaño máximo de LOB esté establecida en un valor que no haga que los datos JSON se trunquen.

AWS DMS es totalmente compatible en cuanto al uso de tipos de datos de objetos grandes (BLOB, CLOB y NCLOB). Los siguientes son puntos de enlace de origen totalmente compatibles con objetos LOB:

• Oracle

• Microsoft SQL Server

• ODBC

Los siguientes son puntos de enlace de destino totalmente compatibles con objetos LOB:

• Oracle

• Microsoft SQL Server

El siguiente punto de enlace de destino tiene compatibilidad limitada con objetos LOB. No puede utilizar un tamaño LOB ilimitado para este punto de enlace de destino.

• Amazon Redshift

• Amazon S3

Si los puntos de enlace son totalmente compatibles con objetos LOB, también puede fijar un límite de tamaño para los tipos de datos LOB.

Se ha mejorado el rendimiento de LOB

Al migrar los datos de LOB, puede especificar las siguientes configuraciones diferentes de optimización de LOB.

Configuración de LOB por tabla

Con la configuración de LOB por tabla, puede invalidar la configuración de LOB en el nivel de tarea para algunas o todas las tablas. Para ello, defina lob-settings en la regla de table-settings. A continuación, se muestra una tabla de ejemplo que incluye algunos valores de LOB grandes.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

A continuación, cree una tarea de migración y modifique el manejo de LOB de la tabla con la nueva regla de lob-settings. El valor de bulk-max-siz determina el tamaño máximo del LOB (KB). Se trunca si es mayor que el tamaño especificado.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Aunque esta tarea de AWS DMS se cree con FullLobMode : true, la configuración de LOB por tabla indica a AWS DMS que trunque los datos de LOB de esta tabla en particular a 16 000. Puede comprobar los registros de tareas para confirmar esto.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Configuración de LOB insertadas

Al crear una tarea de AWS DMS, el modo de LOB determina cómo se gestionan los LOB.

Con el modo de LOB completo y el modo de LOB limitado, cada uno tiene sus propias ventajas y desventajas. El modo de LOB insertado combina las ventajas del modo de LOB completo y del modo de LOB limitado.

Puede utilizar el modo de LOB insertado cuando necesite replicar LOB pequeños y grandes y la mayoría de los LOB sean pequeños. Al elegir esta opción, durante la carga completa, la tarea de AWS DMS transfiere los LOB pequeños insertados, lo que resulta más eficiente. La tarea de AWS DMS transfiere los LOB grandes realizando una búsqueda en la tabla de origen.

Durante el procesamiento de cambios, los LOB pequeños y grandes se replican realizando una búsqueda en la tabla de origen.

Cuando se utiliza el modo de LOB insertado, la tarea de AWS DMS comprueba todos los tamaños de los LOB para determinar cuáles transferir en línea. Los LOB con un tamaño superior al especificado se replican mediante el modo de LOB completo. Por lo tanto, si sabe que la mayoría de los LOB son más grandes que la configuración especificada, es mejor no usar esta opción. En su lugar, permita un tamaño de LOB ilimitado.

Se configura esta opción mediante un atributo en la configuración de la tarea, InlineLobMaxSize, que solo está disponible cuando FullLobMode está configurado en true. El valor predeterminado para InlineLobMaxSize es 0 y el rango es 1: 102 400 kilobytes (100 MB).

Por ejemplo, es posible que use la siguiente configuración de tareas de AWS DMS. En este caso, al establecer InlineLobMaxSize en un valor de 5, todos los LOB menores o iguales a 5 KiB (5120 bytes) se transfieren en línea.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Mejora del rendimiento al migrar tablas grandes con filtrado de filas

Para mejorar el rendimiento al migrar una tabla grande, divida la migración en más de una tarea. Para dividir la migración en varias tareas usando el filtrado de filas, utilice una clave o una clave de partición. Por ejemplo, si tiene un ID entero de clave principal de 1 a 8 000 000, puede crear ocho tareas y usar el filtrado de filas para migrar un millón de registros por cada una.

Aplicación del filtrado de filas en la consola:

1. Abra la AWS Management Console.

2. Elija Tareas y cree una nueva tarea.

3. Elija la pestaña Asignaciones de tabla y amplíe Reglas de selección.

4. Elija Agregar nueva regla de selección. Ahora puede agregar un filtro de columna con una condición inferior o igual a, superior o igual a, igual a o de rango entre dos valores. Para obtener más información sobre el filtrado de columnas, consulte Especificación de selección de tablas y reglas de transformaciones desde la consola.

Puede migrar los datos en función de la fecha, si tiene una tabla grande particionada por fecha. Por ejemplo, supongamos que tiene una tabla particionada por mes y solo se actualizan los datos correspondientes al mes actual. En este caso, puede crear una tarea de carga completa para cada partición mensual estática y crear una tarea de carga completa más CDC para la partición actualizada actualmente.

Si la tabla tiene una clave principal de una sola columna o un índice único, puede hacer que la tarea de AWS DMS segmente la tabla mediante una carga paralela del tipo rangos para cargar los datos en paralelo. Para obtener más información, consulte Reglas y operaciones de configuración de tablas y recopilaciones.

La replicación continua

AWS DMS proporciona la replicación continua de los datos, a la vez que mantiene las bases de datos de origen y de destino sincronizadas. Solo se replica una cantidad limitada de instrucciones de lenguaje de definición de datos (DDL). AWS DMS no propaga elementos tales como índices, usuarios, privilegios, procedimientos almacenados y otros cambios de la base de datos no relacionados directamente con los datos de tabla.

Si tiene previsto utilizar la replicación continua, establezca la opción Multi-AZ al crear la instancia de replicación. Al elegir la opción Multi-AZ consigue alta disponibilidad y soporte de conmutación por error para la instancia de replicación. Sin embargo, esta opción puede afectar al rendimiento y ralentizar la replicación al aplicar cambios en el sistema de destino.

Antes de actualizar las bases de datos de origen o destino, le recomendamos que detenga las tareas de AWS DMS que se estén ejecutando en estas bases de datos. Reanude las tareas una vez completadas las actualizaciones.

Durante la replicación continua, es fundamental identificar el ancho de banda de la red entre el sistema de base de datos de origen y la instancia de replicación de AWS DMS. Asegúrese de que la red no cause ningún cuello de botella durante la replicación en curso.

También es importante identificar la tasa de cambio y la generación de registros de archivo por hora en el sistema de base de datos de origen. Esto puede ayudarle a comprender el rendimiento que podría obtener durante la replicación continua.

Reducción de la carga en su base de datos de origen

AWS DMS utiliza algunos recursos en la base de datos de origen. Durante una tarea de carga completa, AWS DMS analiza por completo la tabla de origen para cada una de las tablas procesadas en paralelo. Además, cada tarea que se crea como parte de una migración comprueba si existen cambios en el origen como parte del proceso de CDC. Para que AWS DMS realice la CDC para algunos orígenes, como Oracle, puede que tenga que aumentar la cantidad de datos escritos en el registro de cambios de su base de datos.

Si descubre que está sobrecargando la base de datos de origen, reduzca el número de tareas o de tablas por cada tarea de la migración. Cada tarea obtiene los cambios del origen de forma independiente, por lo que la consolidación de las tareas puede reducir la carga de trabajo de la captura de cambios.

Reducir los cuellos de botella en la base de datos de destino

Durante la migración, intente eliminar todos los procesos que compiten por los recursos de escritura en la base de datos de destino:

• Desactive los desencadenadores innecesarios.

• Desactive los índices secundarios durante la carga inicial y vuelva a activarlos más adelante durante la replicación en curso.

• En el caso de las bases de datos de Amazon RDS, es una buena idea desactivar las copias de seguridad y Multi-AZ hasta la transición.

• Al migrar a sistemas que no sean de RDS, es una buena idea desactivar cualquier registro en el destino hasta la transición.

Uso de la validación de datos durante la migración

Para asegurar que los datos se han migrado de forma precisa del origen al destino, le recomendamos encarecidamente que utilice la validación de datos. Si activa la validación de datos para una tarea, AWS DMS empieza a comparar los datos de origen y de destino inmediatamente después de realizar una carga completa para una tabla.

La validación de datos funciona con las siguientes bases de datos siempre que AWS DMS las admita como puntos de enlace de origen y de destino:

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora MySQL-Compatible Edition

• Amazon Aurora PostgreSQL-Compatible Edition

• IBM Db2 LUW

• Amazon Redshift

Para obtener más información, consulte Validación de datos de AWS DMS.

Monitoreo de las tareas de AWS DMS mediante métricas

Tiene varias opciones para monitorear las métricas para las tareas mediante la consola de AWS DMS:

Métricas de host

Puede encontrar las métricas del host en la pestaña de CloudWatch métricas de cada instancia de replicación concreta. Aquí, puede monitorear si la instancia de replicación tiene el tamaño adecuado.

Métricas de tareas de replicación

Las métricas de las tareas de replicación, incluidos los cambios entrantes y confirmados, y la latencia entre el host de replicación y las bases de datos de origen/destino se encuentran en la pestaña de CloudWatch métricas de cada tarea en particular.

Métricas de la tabla

Puede encontrar las métricas individuales de la tabla en la pestaña Estadísticas de la tabla para cada tarea individual. Estas métricas incluyen estos números:

• Filas cargadas durante la carga completa.

• Inserta, actualiza y elimina desde que se inició la tarea.

• Operaciones de DDL desde que se inició la tarea.

Para obtener más información acerca de las métricas de monitoreo, consulte Monitoreo de tareas de AWS DMS.

Eventos y notificaciones

AWS DMS utiliza Amazon SNS para proporcionar notificaciones cuando se produce un evento de AWS DMS, por ejemplo, la creación o eliminación de una instancia de replicación. Puede trabajar con estas notificaciones en cualquier formato compatible con Amazon SNS para una región de AWS. Estas pueden incluir mensajes de correo electrónico, mensajes de texto o llamadas a un punto de conexión HTTP.

Para obtener más información, consulte Trabajo con eventos y notificaciones de Amazon SNS en AWS Database Migration Service.

Uso del registro de tareas para solucionar problemas de migración

En algunos casos, AWS DMS puede encontrar problemas para los que los mensajes de advertencia o de error aparecen solo en el registro de tareas. En concreto, los problemas de truncamiento de datos o de rechazo de filas por infracciones en la clave externa solo están escritos en el log de tareas. Por lo tanto, asegúrese de revisar este registro al migrar una base de datos. Para ver el registro de tareas, configura Amazon CloudWatch como parte de la creación de tareas.

Para obtener más información, consulte Supervisión de las tareas de replicación mediante Amazon CloudWatch.

Solución de problemas de tareas de replicación con Viaje en el tiempo

Para solucionar problemas de migración de AWS DMS, puede trabajar con Viaje en el tiempo. Para obtener más información acerca de Viaje en el tiempo, consulte Configuración de tarea de Viaje en el tiempo.

Cuando trabaje con Viaje en el tiempo, tenga en cuenta las siguientes consideraciones:

• Para evitar la sobrecarga de una instancia de replicación de DMS, active Viaje en el tiempo solo para las tareas que se deban depurar.

• Cuando utilice Viaje en el tiempo para solucionar problemas de tareas de replicación que pueden durar varios días, monitoree las métricas de las instancias de replicación para detectar la sobrecarga de recursos. Este enfoque se aplica especialmente en los casos en los que las cargas de transacciones elevadas se ejecutan en las bases de datos de origen durante periodos prolongados. Para obtener más información, consulte Monitoreo de tareas de AWS DMS.

• Cuando la configuración de la tarea Viaje en el tiempo EnableRawData está establecida en true, el uso de memoria de la tarea durante la replicación de DMS puede ser mayor que cuando Viaje en el tiempo no está activado. Si activa Viaje en el tiempo durante periodos prolongados, monitoree la tarea.

• Actualmente, solo puede activar Viaje en el tiempo en el nivel de tarea. Los cambios en todas las tablas se registran en los registros de Viaje en el tiempo. Si está solucionando problemas relacionados con tablas específicas de una base de datos con un alto volumen de transacciones, cree una tarea independiente.

Cambio del usuario y esquema para un destino de Oracle

Cuando utilice Oracle como destino, AWS DMS migra los datos al esquema propiedad del usuario del punto de conexión de destino.

Por ejemplo, supongamos que va a migrar un esquema denominado PERFDATA a un punto de conexión de destino de Oracle y que el nombre de usuario del punto de conexión de destino es MASTER. AWS DMS se conecta al destino de Oracle como MASTER y rellena el esquema MASTER con objetos de base de datos de PERFDATA.

Para invalidar este comportamiento, proporcione una transformación de esquema. Por ejemplo, para migrar los objetos del esquema PERFDATA a un esquema PERFDATA en el punto de conexión de destino, utilice la siguiente transformación.

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Para obtener más información sobre transformaciones, consulte Especificación de reglas de selección de tablas y transformaciones mediante JSON.

Cambio de espacios de tabla de tabla e índice para un destino de Oracle

Cuando se utiliza Oracle como destino, AWS DMS migra todas las tablas e índices al espacio de tabla predeterminado en el destino. Por ejemplo, suponga que su origen es un motor de base de datos distinto de Oracle. Todas las tablas de destino e índices se migran a los mismos espacios de tabla predeterminados.

Para invalidar este comportamiento, proporcione las transformaciones de espacio de tabla correspondientes. Por ejemplo, suponga que desea migrar tablas e índices a espacios de tabla de tabla e índice en el destino de Oracle que se nombran según el esquema del origen. En este caso, puede utilizar transformaciones similares a las siguientes. Aquí, el esquema en el origen se denomina INVENTORY y los espacios de tabla de tabla e índice correspondientes en el destino se llaman INVENTORYTBL e INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Para obtener más información sobre transformaciones, consulte Especificación de reglas de selección de tablas y transformaciones mediante JSON.

Cuando Oracle es origen y destino, puede conservar las asignaciones de espacio de tabla de índice o de tabla existentes estableciendo el atributo de conexión adicional de origen de Oracle, enableHomogenousTablespace=true. Para obtener más información, consulte Configuración del punto final cuando se utiliza Oracle como fuente de AWS DMS.

Actualización de una versión de la instancia de replicación

AWS lanza periódicamente nuevas versiones del software del motor de replicación de AWS DMS, con nuevas características y mejoras de rendimiento. Cada versión del software del motor de replicación tiene su propio número de versión. Es fundamental probar la versión existente de la instancia de replicación de AWS DMS que ejecuta una carga de trabajo de producción antes de actualizar la instancia de replicación a una versión posterior. Para obtener más información acerca de las actualizaciones de versiones disponibles, consulte AWS Notas de la versión de DMS.

Descripción del costo de la migración

AWS Database Migration Service le ayuda a migrar bases de datos a AWS de manera sencilla y segura a un costo bajo. Solo paga por las instancias de replicación y por el almacenamiento de registros adicional. Cada instancia de migración de base de datos incluye almacenamiento suficiente para espacio de intercambio, registros de replicación y caché de datos para la mayoría de las replicaciones y la transferencia de datos entrantes es gratuita.

Es posible que necesite más recursos durante la carga inicial o durante las horas pico de carga. Puede monitorear de cerca la utilización de los recursos de las instancias de replicación con las métricas de Cloud Watch. A continuación, puede escalar verticalmente y reducir verticalmente el tamaño de la instancia de replicación en función del uso.

Para obtener más información sobre la estimación de los costos de migración, consulte:

• Precios de AWS Database Migration Service

• Calculadora de precios de AWS