Solución de problemas de tareas de migración en AWS Database Migration Service - AWS Database Migration Service
Las tareas de migración se ejecutan lentamenteLa barra de estado de la tarea no se mueveLa tarea se completa pero no se ha migrado nadaFaltan claves externas e índices secundariosAWS DMSno crea registros CloudWatch Se producen problemas al conectarse a Amazon RDSSe producen problemas de redAtasco de CDC después de la carga completaErrores de vulneración de la clave principal al volver a comenzar una tareaError en la carga inicial de un esquemaTareas que producen un error desconocidoReiniciar la tarea carga las tablas desde el principioEl número de tablas por tarea provoca problemasLas tareas producen un error cuando una clave principal se crea en una columna de LOBDuplicar registros que se producen en la tabla de destino sin una clave principalLos puntos de conexión de origen se incluyen en el rango de IP reservadoLas marcas temporales son confusas en las consultas de Amazon AthenaSolución de problemas con OracleSolución de problemas con MySQLSolución de problemas mediante PostgreSQLSolución de problemas con Microsoft SQL ServerSolución de problemas con Amazon RedshiftSolución de problemas con Amazon Aurora MySQL Solución de problemas con SAP ASESolución de problemas con IBM Db2

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas de tareas de migración en AWS Database Migration Service

A continuación, puede encontrar temas sobre la solución de problemas con AWS Database Migration Service (AWS DMS). Estos temas le pueden ayudar a resolver problemas comunes al utilizar bases de datos de AWS DMS y de puntos de conexión seleccionados.

Si ha abierto un caso de AWS Support, es posible que el ingeniero de soporte identifique un problema potencial con una de las configuraciones de la base de datos de punto de conexión. Es posible que el ingeniero también le pida que ejecute un script de soporte para obtener información de diagnóstico sobre la base de datos. Para obtener más información sobre cómo descargar, ejecutar y cargar la información de diagnóstico de este tipo de script de soporte, consulte Trabajar con scripts de soporte de diagnóstico en AWS DMS.

Para solucionar problemas, AWS DMS recopila los archivos de rastreo y descarga en la instancia de replicación. Puede proporcionar estos archivos a AWS Support en caso de que se produzca un problema que requiera la solución de problemas. De forma predeterminada, el DMS purga los archivos de rastreo y descarga que tienen más de treinta días de antigüedad. Para excluirse de la recopilación de archivos de rastreo y volcado, abra un caso con AWS Support.

Temas

Las tareas de migración se ejecutan lentamente

Existen varios problemas que pueden provocar lentitud en una tarea de migración o hacer que las tareas posteriores se ejecuten a menor velocidad que la tarea inicial.

La razón más común para que una tarea de migración se ejecute con lentitud es que se hayan asignado los recursos inadecuados a la instancia de replicación de AWS DMS. Para asegurarse de que la instancia tiene suficientes recursos para las tareas que está ejecutando en ella, compruebe el uso de la CPU, la memoria, los archivos de intercambio y las IOPS de la instancia de replicación. Por ejemplo, si hay varias tareas con Amazon Redshift como punto de conexión, se generan muchas operaciones de E/S. Puede ampliar el número de IOPS para su instancia de replicación o dividir las tareas entre varias instancias de replicación para lograr una migración más eficaz.

Para obtener más información sobre cómo determinar el tamaño de la instancia de replicación, consulte Selección del mejor tamaño para una instancia de replicación.

Para aumentar la velocidad de una carga de migración inicial, haga lo siguiente:

  • Si el destino es una instancia de base de datos de Amazon RDS, asegúrese de que Multi-AZ no esté habilitada para la instancia de la base de datos de destino.

  • Durante la carga, desactive cualquier copia de seguridad automática o el registro en la base de datos de destino y vuelva a activar estas características en cuanto se complete la migración.

  • Si la característica está disponible en el destino, utilice IOPS aprovisionadas.

  • Si los datos de migración contienen LOB, asegúrese de que la tarea esté optimizada para la migración de LOB. Para obtener más información sobre cómo optimizar LOB, consulte Configuración de las tareas de los metadatos de destino.

La barra de estado de la tarea no se mueve

La barra de estado de la tarea proporciona una estimación del avance de la tarea. La calidad de esta estimación depende de la calidad de las estadísticas de la tabla de la base de datos de origen; cuanto mejores sean las estadísticas de la tabla, más precisa será la estimación.

Si una tarea solo tiene una tabla sin estimación de estadísticas de fila, AWS DMS no puede proporcionar ningún tipo de estimación sobre el porcentaje completado. En este caso, utilice el estado de la tarea y la indicación de las filas cargadas para confirmar que la tarea está en ejecución y avanzando.

La tarea se completa pero no se ha migrado nada

Haga lo siguiente si no se ha migrado nada una vez finalizada la tarea.

  • Compruebe si el usuario que creó el punto de conexión tiene acceso de lectura a la tabla que desea migrar.

  • Compruebe si el objeto que desea migrar es una tabla. Si se trata de una vista, actualice las asignaciones de las tablas y especifique el localizador de objetos como “vista” o “todo”. Para obtener más información, consulte Especificación de selección de tablas y reglas de transformaciones desde la consola.

Faltan claves externas e índices secundarios

AWS DMS crea tablas, claves principales y, en algunos casos, índices únicos, pero no crea ningún otro objeto que no se necesite para migrar eficientemente los datos desde el origen. Por ejemplo, no crea índices secundarios, limitaciones de claves no primarias ni valores predeterminados de datos.

Para migrar objetos secundarios desde la base de datos, utilice las herramientas nativas de la base de datos si está migrando al mismo motor de base de datos que su base de datos de origen. Utilice AWS Schema Conversion Tool (AWS SCT) si migra a otro motor de base de datos distinto del utilizado por la base de datos de origen para migrar objetos secundarios.

AWS DMSno crea registros CloudWatch

Si su tarea de replicación no crea CloudWatch registros, asegúrese de que su cuenta tenga la dms-cloudwatch-logs-role función. Si este rol no está presente, haga lo siguiente para crearlo:

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

  2. Elija la pestaña de Roles. Elija Crear rol.

  3. En la sección Seleccionar tipo de entidad de confianza, elija Servicio de AWS.

  4. En la sección Elegir un caso de uso, elija DMS.

  5. Elija Siguiente: permisos.

  6. Ingresa AmazonDMSCloudWatchLogsRole en el campo de búsqueda y marca la casilla situada junto a AmazonDMS CloudWatchLogsRole. Esto otorga AWS DMS permisos de acceso. CloudWatch

  7. Elija Siguiente: Etiquetas.

  8. Elija Siguiente: Revisar.

  9. Ingrese dms-cloudwatch-logs-role para Nombre de rol. Este nombre distingue entre mayúsculas y minúsculas.

  10. Elija Crear rol.

Se producen problemas al conectarse a Amazon RDS

Puede haber varias razones por las que no se pueda conectar a una instancia de base de datos de Amazon RDS establecida como origen o destino. A continuación, se muestran algunos elementos que hay que comprobar:

  • Compruebe que la combinación del nombre y la contraseña del usuario es correcta.

  • Compruebe que el valor del punto de conexión que se muestra en la consola de Amazon RDS para la instancia es el mismo que el identificador del punto de conexión utilizado para crear el punto de conexión de AWS DMS.

  • Compruebe que el valor del puerto mostrado en la consola de Amazon RDS para la instancia es el mismo que el puerto asignado al punto de conexión de AWS DMS.

  • Compruebe que el grupo de seguridad asignado a la instancia de base de datos de Amazon RDS permite conexiones desde la instancia de replicación de AWS DMS.

  • Si la instancia de replicación de AWS DMS y la instancia de base de datos de Amazon RDS no están en la misma nube privada virtual (VPC), compruebe que se puede acceder públicamente a la instancia de la base de datos.

Mensaje de error de cadena de conexión de subproceso incorrecta y valor de subproceso incorrecto 0

Este error puede producirse a menudo al probar el enlace a un punto de enlace. Este error indica que hay un error en la cadena de conexión. Un ejemplo es un espacio después de la dirección IP del host. Otro es un carácter incorrecto copiado en la cadena de conexión.

Se producen problemas de red

El problema de red más habitual tiene que ver con el grupo de seguridad de VPC que utiliza la instancia de replicación de AWS DMS. De forma predeterminada, este grupo de seguridad tiene normas que permiten salidas a 0.0.0.0/0 en todos los puertos. En muchos casos, se modifica este grupo de seguridad o se utiliza el suyo propio. Si es así, como mínimo, asegúrese de dar salida a los puntos de conexión de origen y destino en los respectivos puertos de base de datos.

Otros problemas relacionados con la configuración pueden ser:

  • La instancia de replicación y los puntos de conexión de origen y de destino están en la misma VPC: el grupo de seguridad que utilizan los puntos de conexión debe permitir recibir datos en el puerto de la base de dato desde la instancia de replicación. Asegúrese de que el grupo de seguridad utilizado por la instancia de replicación llegue a los puntos de conexión. O puede crear una regla en el grupo de seguridad utilizado por los puntos de conexión que permita el acceso a la dirección IP privada de la instancia de replicación.

  • El punto de conexión de origen está fuera de la VPC que utiliza la instancia de replicación (a través de la puerta de enlace de Internet): el grupo de seguridad de la VPC debe incluir normas de enrutamiento que envíen el tráfico no destinado a la VPC a la puerta de enlace de Internet. En esta configuración, la conexión con el punto de enlace parece provenir de la dirección IP pública de la instancia de replicación.

  • El punto de conexión de origen está fuera de la VPC que utiliza la instancia de replicación (con una puerta de enlace NAT): puede configurar una puerta de enlace de traducción de direcciones de red (NAT) con una única dirección IP elástica asociada a una única interfaz de red elástica. Esta puerta de enlace NAT recibe un identificador NAT (nat-#####).

    En algunos casos, la VPC incluye una ruta predeterminada a esa puerta de enlace NAT en lugar de a la puerta de enlace de Internet. En esos casos, la instancia de replicación parece ponerse en contacto con el punto de conexión de la base de datos mediante la dirección IP pública de la puerta de enlace NAT. Aquí, la entrada al punto de conexión de la base de datos fuera de la VPC debe permitir la entrada de la dirección NAT en lugar de la dirección IP pública de la instancia de replicación.

Para obtener información acerca del uso del propio servidor de nombres en las instalaciones, consulte Uso de su propio servidor de nombres en las instalaciones.

Atasco de CDC después de la carga completa

Los cambios de la replicación pueden ser lentos o se pueden producir atascos después de haber realizado una migración de carga completa y si hay varios ajustes de AWS DMSen conflicto unos con otros.

Por ejemplo, supongamos que el parámetro del modo de preparación de la tabla de destino está establecido en No hacer nada o Truncar. En este caso, ha indicado a AWS DMS que no realice ninguna configuración en las tablas de destino, incluida la creación de índices principales y únicos. Si no ha creado claves principales ni únicas en las tablas de destino, AWS DMS analiza por completo la tabla para cada actualización. Este enfoque puede afectar al rendimiento de forma significativa.

Errores de vulneración de la clave principal al volver a comenzar una tarea

Este error se puede producir cuando permanecen en la base de datos de destino datos procedentes de una tarea de migración anterior. Si la opción Modo de preparación de tabla de destino está definida en No hacer nada, AWS DMS no hace ninguna actividad de preparación en la tabla de destino, ni tampoco limpia datos insertados en una tarea anterior.

Para reiniciar la tarea y evitar que se produzcan estos errores, elimine las filas insertadas en las tablas de destino de la ejecución anterior de la tarea.

Error en la carga inicial de un esquema

En algunos casos, es posible que la carga inicial de los esquemas produzca un error Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

En estos casos, la cuenta de usuario utilizada por AWS DMS para conectarse al punto de conexión de origen no tiene los permisos necesarios.

Tareas que producen un error desconocido

La causa de los tipos de error desconocidos puede variar. Sin embargo, a menudo nos damos cuenta de que el problema se debe a que los recursos asignados a la instancia de replicación de AWS DMS son insuficientes.

Para asegurarse de que la instancia de replicación tenga suficientes recursos para realizar la migración, compruebe el uso de la CPU, la memoria, los archivos de intercambio y las IOPS de la instancia. Para obtener más información acerca de la monitorización, consulte Métricas de AWS Database Migration Service.

Reiniciar la tarea carga las tablas desde el principio

AWS DMS reinicia la carga de tablas desde el principio cuando no ha terminado la carga inicial de una tabla. Cuando se reinicia una tarea, AWS DMS vuelve a cargar las tablas desde el principio cuando la carga inicial no se completó.

El número de tablas por tarea provoca problemas

No hay un límite establecido en el número de tablas por tarea de replicación. Sin embargo, como regla general, recomendamos limitar el número de tablas de una tarea a menos de 60 000. El uso de recursos puede provocar atascos si una única tarea utiliza más de 60 000 tablas.

Las tareas producen un error cuando una clave principal se crea en una columna de LOB

En el modo de LOB COMPLETO o LOB LIMITADO, AWS DMS no admite la replicación de claves principales que son tipos de datos de LOB.

DMS migra inicialmente una fila con una columna LOB como nula y, a continuación, actualiza la columna LOB. Por lo tanto, cuando se crea la clave principal en una columna LOB, la inserción inicial falla ya que la clave principal no puede ser nula. Como solución alternativa, agregue otra columna como clave principal y elimine la clave principal de la columna de LOB.

Duplicar registros que se producen en la tabla de destino sin una clave principal

La ejecución de una tarea de carga completa y CDC puede crear registros duplicados en tablas de destino que no tengan una clave principal o un índice único. Para evitar la duplicación de registros en tablas de destino durante las tareas de carga completa y CDC, asegúrese de que las tablas de destino tengan una clave principal o un índice único.

Los puntos de conexión de origen se incluyen en el rango de IP reservado

Si una base de datos de origen de AWS DMS utiliza una dirección IP dentro del intervalo IP reservado de 192.168.0.0/24, se produce un error en la prueba de conexión de punto de conexión de origen. Los pasos siguientes proporcionan una posible solución alternativa:

  1. Busque una instancia de Amazon EC2 que no esté en el rango reservado que pueda comunicarse con la base de datos de origen en 192.168.0.0/24.

  2. Instale un proxy socat y ejecútelo. A continuación se muestra un ejemplo.

    yum install socat
                
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&

Utilice la dirección IP de instancia de Amazon EC2 y el puerto de base de datos indicado anteriormente para el punto de conexión de AWS DMS. Asegúrese de que el punto de conexión tenga el grupo de seguridad que permite a AWS DMS acceder al puerto de la base de datos. Tenga en cuenta que el proxy debe estar funcionando mientras dure la ejecución de la tarea de DMS. En función del caso de uso, es posible que tenga que automatizar la configuración del proxy.

Las marcas temporales son confusas en las consultas de Amazon Athena

Si las marcas de tiempo aparecen confusas en las consultas de Athena, utilice la ModifyEndpointacción AWS Management Console o para establecer el valor de parquetTimestampInMillisecond su punto de conexión Amazon S3 en. true Para obtener más información, consulte S3Settings.

Solución de problemas con Oracle

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de Oracle.

Obtención de datos de consultas

Puede extraer los datos una vez desde una vista; no puede utilizarlos para la replicación continua. Para poder extraer los datos de las vistas, debe agregar el código siguiente a la sección Configuración del punto de conexión de la página del punto de conexión de origen de Oracle. Al extraer los datos de una vista, la vista se muestra como una tabla en el esquema de destino.

"ExposeViews": true

Migración de LOB desde Oracle 12c

AWS DMSpuede utilizar dos métodos para capturar los cambios en una base de datos de Oracle: Binary Reader y Oracle. LogMiner De forma predeterminada, AWS DMS utiliza Oracle LogMiner para capturar los cambios. Sin embargo, en Oracle 12c, Oracle LogMiner no admite columnas LOB. Para capturar cambios en columnas LOB en Oracle 12c, utilice Binary Reader.

Cambiar entre Oracle LogMiner y Binary Reader

AWS DMSpuede utilizar dos métodos para capturar los cambios en una base de datos Oracle de origen: Binary Reader y Oracle LogMiner. Oracle LogMiner es el valor predeterminado. Si desea cambiar y usar Binary Reader para capturar cambios, haga lo siguiente:

Para utilizar Binary Reader para capturar cambios

  1. Inicie sesión en la AWS DMS consola AWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Puntos de conexión.

  3. Elija el punto de conexión de origen de Oracle que desea para utilizar Binary Reader.

  4. Elija Modificar.

  5. Elija Opciones avanzadas y agregue después el código siguiente para Atributos de conexión adicionales.

    
useLogminerReader=N

  6. Utilice una herramienta de desarrollador de Oracle como SQL-Plus para conceder el privilegio adicional siguiente a la cuenta de usuario de AWS DMS empleada para conectar con el punto de conexión de Oracle.

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

Error de CDC de Oracle detenido 122301 y de tope de reintentos de CDC de Oracle superado.

Este error se produce cuando los registros de archivos de Oracle necesarios se han eliminado de su servidor antes de que AWS DMS pudiera utilizarlos para capturar los cambios. Amplíe sus políticas de retención de registros en el servidor de base de datos. Para una base de datos de Amazon RDS, ejecute el procedimiento siguiente para ampliar la retención de registros. El código del ejemplo siguiente amplía la retención de registros en una instancia de base de datos de Amazon RDS a 24 horas.


exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Agregar automáticamente registros suplementarios a un punto de conexión de origen de Oracle

De forma predeterminada, el registro complementario de AWS DMS está desactivado. Para activar automáticamente el registro complementario para un punto de enlace de origen de Oracle, haga lo siguiente:

Para agregar registros suplementarios a un punto de enlace de Oracle de origen

  1. Inicie sesión en la AWS DMS consola AWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Puntos de conexión.

  3. Elija el punto de conexión de origen de Oracle al que desee agregar el registro .

  4. Elija Modificar.

  5. Elija Opciones avanzadas y agregue después el código siguiente en el cuadro de texto Atributos de conexión adicionales:

    
addSupplementalLogging=Y

  6. Elija Modificar.

No se están capturando los cambios de LOB

En la actualidad, una tabla debe tener una clave principal para que AWS DMS pueda capturar los cambios de LOB. Si una tabla que contiene LOB no tiene una clave principal, hay varias medidas que puede aplicar para capturar los cambios de los LOB:

  • Añadir una clave principal a la tabla. Esto puede ser tan sencillo como añadir una columna de ID y rellenarla con una secuencia utilizando un activador.

  • Cree una vista materializada de la tabla que incluya un ID generado por el sistema como clave principal y migrar la vista materializada en lugar de la tabla.

  • Crear una espera lógica, agregar una clave principal a la tabla y migrar desde la espera lógica.

Error: ORA-12899: valor demasiado grande para la columna nombre de columna

El error “ORA-12899: valor demasiado grande para el nombre de la columna” suele deberse a un par de problemas.

En uno de estos problemas, hay una discordancia entre los conjuntos de caracteres utilizados por las bases de datos de origen y destino.

En otro de estos problemas, la configuración del soporte en el idioma nacional (NLS) difiere entre las dos bases de datos. Una causa habitual de este error es que el parámetro NLS_LENGTH_SEMANTICS de la base de datos de origen esté definido en CHAR y el parámetro NLS_LENGTH_SEMANTICS en BYTE.

Malinterpretación del tipo de datos NUMBER

El tipo de datos NUMBER de Oracle se convierte en varios tipos de datos de AWS DMS en función de la precisión y la escala de NUMBER. Estas conversiones pueden consultarse aquí Tipos de datos de origen para Oracle. El modo de conversión del tipo NUMBER también puede verse afectado por el uso de ajustes de punto de conexión para el punto de conexión de origen de Oracle. Estos ajustes de punto de conexión están documentados en Configuración del punto final cuando se utiliza Oracle como fuente de AWS DMS.

Faltan registros durante la carga completa

Al realizar una carga completa, AWS DMS busca transacciones abiertas en el nivel de base de datos y espera a que se confirme la transacción. Por ejemplo, en función de la configuración de la tarea TransactionConsistencyTimeout=600, AWS DMS espera 10 minutos incluso si la transacción abierta se encuentra en una tabla que no está incluida en la asignación de tablas. Sin embargo, si la transacción abierta está en una tabla incluida en la asignación de tablas y la transacción no se confirma a tiempo, el resultado es que faltan registros en la tabla de destino.

Puede modificar la configuración de la tarea TransactionConsistencyTimeout y aumentar el tiempo de espera si sabe que las transacciones abiertas tardarán más en confirmarse.

Además, tenga en cuenta que el valor predeterminado de la configuración de la tarea FailOnTransactionConsistencyBreached es false. Esto significa que AWS DMS sigue aplicando otras transacciones, pero se pierden las transacciones abiertas. Si quiere que la tarea produzca un error cuando las transacciones abiertas no se cierren a tiempo, puede configurar FailOnTransactionConsistencyBreached en true.

Error de tabla

Table Error aparece en las estadísticas de la tabla durante la replicación si una cláusula WHERE no hace referencia a una columna de clave principal y el registro complementario no se utiliza en todas las columnas.

Para solucionar este problema, active el registro complementario en todas las columnas de la tabla a la que se hace referencia. Para obtener más información, consulte Configuración del registro complementario.

Error: no se pueden recuperar los ID de destino de registro REDO archivado por Oracle

Este error se produce cuando el origen de Oracle no tiene ningún registro de archivo generado o V$ARCHIVED_LOG está vacío. Puede resolver el error cambiando los registros manualmente.

Para una base de datos de Amazon RDS, ejecute el procedimiento siguiente para cambiar los archivos de registro. El procedimiento switch_logfile no tiene parámetros.

exec rdsadmin.rdsadmin_util.switch_logfile;

Para una base de datos de origen de Oracle autoadministrada, utilice el siguiente comando para forzar un cambio de registro.

ALTER SYSTEM SWITCH LOGFILE ;

Evaluación del rendimiento de lectura de los registros REDO o archivados de Oracle

Si tiene problemas de rendimiento con el origen de Oracle, puede evaluar el rendimiento de lectura de los registros REDO o archivados de Oracle para encontrar formas de mejorar el rendimiento. Para probar el rendimiento de la lectura de registros REDO o de archivos, utilice la imagen de máquina de Amazon (AMI) de diagnóstico de AWS DMS.

Puede usar la AMI de diagnóstico de AWS DMS para hacer lo siguiente:

  • Utilice el método bFile para evaluar el rendimiento de los archivos de registro REDO.

  • Utilice el LogMiner método para evaluar el rendimiento del archivo redo log.

  • Utilice el método PL/SQL (dbms_lob.read) para evaluar el rendimiento de los archivos de registro REDO.

  • Utilice un solo subproceso para evaluar el rendimiento de lectura en ASMFile.

  • Utilice varios subprocesos para evaluar el rendimiento de lectura en ASMFile.

  • Utilice la función Direct OS Readfile() para Windows o Pread64 para Linux para evaluar el archivo de registro REDO.

A continuación, puede tomar medidas correctivas en función de los resultados.

Prueba del rendimiento de lectura en un archivo de registro REDO o de archivo de Oracle

  1. Cree una instancia de Amazon EC2 de AMI de diagnóstico de AWS DMS y conéctese a ella.

    Para obtener más información, consulte Uso de la AMI de diagnóstico de AWS DMS.

  2. Ejecute el comando awsreplperf.

    $ awsreplperf

    El comando muestra las opciones de la utilidad de rendimiento de lectura de Oracle de AWS DMS.

    0.	Quit
1.	Read using Bfile
2.	Read using LogMiner
3.	Read file PL/SQL (dms_lob.read)
4.	Read ASMFile Single Thread
5.	Read ASMFile Multi Thread
6.	Readfile() function

  3. Seleccione una opción de la lista.

  4. Ingrese la siguiente información de conexión a la base de datos y registro de archivo.

    Oracle user name [system]:
Oracle password:

Oracle connection name [orcllx]:
Connection format hostname:port/instance

Oracle event trace? [N]: 
Default N = No or Y = Yes

Path to redo or archive log file []:

  5. Examine el resultado mostrado para obtener información relevante sobre el rendimiento de lectura. Por ejemplo, a continuación se muestra el resultado que se puede obtener al seleccionar la opción número 2, Leer usando LogMiner.

    resultado de la utilidad de rendimiento de lectura

  6. Para salir de la utilidad, ingrese 0 (cero).

Siguientes pasos

  • Cuando los resultados muestren que la velocidad de lectura está por debajo de un umbral aceptable, ejecute el script de soporte de diagnóstico de Oracle en el punto de conexión y revise las secciones Tiempo de espera, Perfil de carga y Perfil de E/S. A continuación, ajuste cualquier configuración anormal que pueda mejorar el rendimiento de lectura. Por ejemplo, si los archivos de registro REDO ocupan hasta 2 GB, intente aumentar el tamaño de LOG_BUFFER a 200 MB para mejorar el rendimiento.

  • Revise las prácticas recomendadas de AWS DMS para asegurarse de que la instancia, la tarea y los puntos de conexión de replicación de DMS estén configurados de forma óptima.

Solución de problemas con MySQL

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos MySQL.

La tarea de CDC produce un error para el punto de enlace de la instancia de base de datos de Amazon RDS porque se ha desactivado el registro binario

Este problema se produce con las instancias de base de datos de Amazon RDS, porque las copias de seguridad automatizadas están deshabilitadas. Habilite las copias de seguridad automáticas fijando el período de retención de copia de seguridad en un valor diferente de cero.

Las conexiones a una instancia de MySQL de destino se desconectan durante una tarea

Si una tarea con LOB se está desconectando de un destino de MySQL, es posible que vea el siguiente tipo de errores en el registro de la tarea. 

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.
 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

En este caso, es posible que tenga que ajustar alguna de las configuraciones de la tarea.

Para resolver el problema de una tarea que se esté desconectado de un destino MySQL, haga lo siguiente:

  • Compruebe que ha definido la variable max_allowed_packet de su base de datos en un valor suficientemente alto como para almacenar sus LOB más grandes.

  • Compruebe que ha configurado las variables siguientes para disponer de un valor de tiempo de espera amplio. Le sugerimos que utilice un valor mínimo de 5 minutos para cada una de estas variables.

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

Para obtener información sobre cómo configurar las variables del sistema de MySQL, consulte Variables del sistema del servidor en la documentación de MySQL.

Agregar la confirmación automática a un punto de enlace compatible con MySQL

Para añadir autocommit a un punto de enlace de destino compatible con MySQL

  1. Inicie sesión en la AWS DMS consola AWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Puntos de conexión.

  3. Elija el punto de conexión de destino compatible con MySQL al que desee agregar confirmación automática.

  4. Elija Modificar.

  5. Elija Opciones avanzadas y agregue después el código siguiente en el cuadro de texto Atributos de conexión adicionales:

    
Initstmt= SET AUTOCOMMIT=1

  6. Elija Modificar.

Desactivar claves externas en un punto de enlace de destino compatible con MySQL

Puede desactivar las comprobaciones de claves externas en MySQL agregando lo siguiente a Atributos de conexión adicionales, en la sección Opciones avanzadas del punto de conexión de MySQL, Amazon Aurora MySQL-Compatible Edition o MariaDB de destino.

Para desactivar claves externas en un punto de enlace de destino compatible con MySQL

  1. Inicie sesión en la AWS DMS consola AWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Puntos de conexión.

  3. Elija el punto de conexión de destino de MySQL, Aurora MySQL o MariaDB cuyas claves externas desea desactivar.

  4. Elija Modificar.

  5. Elija Opciones avanzadas y agregue después el código siguiente en el cuadro de texto Atributos de conexión adicionales:

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. Elija Modificar.

Caracteres sustituidos por signos de interrogación

La situación que más habitualmente origina este problema es que los caracteres del punto de enlace de origen se hayan codificado mediante un juego de caracteres incompatibles con AWS DMS.

Entradas de registro “evento incorrecto”

Las entradas de “evento incorrecto” en los registros de migración suelen indicar que se ha intentado realizar una operación de lenguaje de definición de datos (DDL) no admitida en el punto de conexión de la base de datos de origen. Las operaciones DDL incompatibles generan un evento que la instancia de replicación no puede omitir, por lo que se registra un evento incorrecto.

Para solucionar este problema, reinicie la tarea desde el principio. De este modo, se vuelven a cargar las tablas y se empiezan a capturar los cambios en un momento en el que se haya ejecutado la operación DDL no admitida.

Captura de datos de cambios con MySQL 5.5

La captura de datos de cambios (CDC) de AWS DMS para bases de datos compatibles con MySQL de Amazon RDS requiere un registro binario de imagen completa basado en filas, incompatible con la versión de MySQL 5.5 o anteriores. Para utilizar la función CDC de AWS DMS debe actualizar su instancia de base de datos de Amazon RDS a MySQL versión 5.6.

Aumento de la retención de registros binarios para instancias de base de datos de Amazon RDS

AWS DMS precisa que se retengan archivos de registros binarios para capturar datos de cambios. Para retener registros durante más tiempo en una instancia de base de datos de Amazon RDS, siga este procedimiento. El ejemplo que sigue amplía el tiempo de retención de registros binarios hasta 24 horas. 


call mysql.rds_set_configuration('binlog retention hours', 24);

Mensaje de registro: algunos cambios desde la base de datos de origen no han surtido efecto al aplicarlos a la base de datos de destino.

Cuando AWS DMS actualiza el valor de una columna de la base de datos de MySQL a su valor existente, MySQL devuelve un mensaje de zero rows affected. Este comportamiento es distinto a lo que ocurre con otros motores de bases de datos, como Oracle y SQL Server. Estos motores actualizan una fila, incluso cuando el valor de sustitución es el mismo que el actual.

Error de identificador demasiado largo

El siguiente error se produce cuando un identificador es demasiado largo:


TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

En algunos casos, se establece AWS DMS para crear las tablas y las claves principales en la base de datos de destino. En estos casos, DMS actualmente no usa los mismos nombres para las claves principales que se usaron en la base de datos de origen. En su lugar, DMS crea el nombre de la clave principal en función del nombre de la tabla. Cuando el nombre de la tabla es largo, el identificador autogenerado puede superar el límite permitido para MySQL.

Para resolver este problema, el enfoque actual consiste en crear previamente las tablas y las claves principales en la base de datos de destino. A continuación, utilice una tarea con la configuración de tareas Modo de preparación de la tabla de destino establecida en No hacer nada o Truncar para rellenar las tablas de destino.

Error: conjunto de caracteres incompatible provoca error en la conversión de datos del campo

El siguiente error se produce cuando un juego de caracteres no compatible genera error en la conversión de datos del campo:


"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)

Compruebe los parámetros de la base de datos relacionados con las conexiones. El siguiente comando se puede usar para establecer estos parámetros.


SHOW VARIABLES LIKE '%char%';

Error: página de códigos 1252 a UTF8 [120112] Se ha producido un error en la conversión de datos del campo

El siguiente error puede producirse durante una migración si existen caracteres que no pertenecen a la página de códigos 1252 en la base de datos MySQL de origen.

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)

Como solución provisional, puede utilizar el atributo de conexión adicional CharsetMapping con el punto de enlace de MySQL de origen para especificar el mapeo del conjunto de caracteres. Es posible que tenga que reiniciar la tarea de migración de AWS DMS desde el principio si agrega esta configuración de punto de conexión.

Por ejemplo, la siguiente configuración de punto de conexión podría usarse para un punto de conexión de origen de MySQL donde el conjunto de caracteres de origen es Utf8 o latin1. 65001 es el identificador de la página de códigos UTF8. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

Los índices, las claves externas o las actualizaciones o eliminaciones en cascada no se migran

AWS DMS no admite la migración de objetos secundarios, como índices y claves externas. Para replicar los cambios realizados en las tablas secundarias a partir de una operación de actualización o eliminación en cascada, es necesario tener activa la restricción de clave externa desencadenante en la tabla de destino. Para evitar esta limitación, cree la clave externa manualmente en la tabla de destino. A continuación, cree una sola tarea para la carga completa y CDC o dos tareas independientes para la carga completa y CDC, tal y como se describe a continuación:

Crear una tarea única que admita la carga completa y CDC

Este procedimiento describe cómo migrar claves e índices externos mediante una sola tarea para carga completa y CDC.

Crear una tarea de carga completa y CDC

  1. Cree manualmente las tablas con claves e índices externos en el destino para que coincidan con las tablas de origen.

  2. Agregue el siguiente ECA al punto de conexión de AWS DMS de destino:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Cree la tarea de AWS DMS con TargetTablePrepMode establecido en DO_NOTHING.

  4. Establezca la opción Stop task after full load completes en StopTaskCachedChangesApplied.

  5. Inicie la tarea. AWS DMS detiene la tarea automáticamente después de completar la carga completa y aplica los cambios en la memoria caché.

  6. Elimine el ECA SET FOREIGN_KEY_CHECKS que agregó anteriormente.

  7. Reanude la tarea. La tarea entra en la fase de CDC y aplica los cambios continuos de la base de datos de origen al destino.

Crear tareas de carga completa y CDC de forma independiente

Estos procedimientos describen cómo migrar claves e índices externos mediante tareas independientes para carga completa y CDC.

Crear una tarea de carga completa

  1. Cree manualmente las tablas con claves e índices externos en el destino para que coincidan con las tablas de origen.

  2. Agregue el siguiente ECA al punto de conexión de AWS DMS de destino:

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Cree la tarea de AWS DMS con el parámetro TargetTablePrepMode establecido en DO_NOTHING y EnableValidation establecido en FALSE.

  4. Inicie la tarea. AWS DMS detiene la tarea automáticamente después de completar la carga completa y aplica los cambios en la memoria caché.

  5. Una vez finalizada la tarea, anote la hora de inicio de la tarea de carga completa en UTC o el nombre y la posición del archivo de registro binario, para iniciar la tarea exclusiva de CDC. Consulte los registros para obtener la marca temporal en UTC a partir de la hora inicial de inicio de la carga completa.

Crear una tarea exclusiva de CDC

  1. Elimine el ECA SET FOREIGN_KEY_CHECKS que estableció anteriormente.

  2. Cree la tarea exclusiva de CDC con la posición de inicio ajustada a la hora de inicio de carga completa indicada en el paso anterior. Como alternativa, puede usar la posición de registro binario registrada en el paso anterior. Establezca la opción TargetTablePrepMode en DO_NOTHING. Habilite la validación de datos mediante el establecimiento de la configuración de EnableValidation en TRUE si es necesario.

  3. Inicie la tarea exclusiva de CDC y monitoree los registros para detectar errores.

nota

Esta solución alternativa solo se aplica a una migración de MySQL a MySQL. No puede usar este método con la característica Aplicación por lotes, ya que la Aplicación por lotes requiere que las tablas de destino no tengan claves externas activas.

Solución de problemas mediante PostgreSQL

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de PostgreSQL.

Tipos de datos JSON truncados

AWS DMS trata el tipo de datos JSON en PostgreSQL como columna del tipo de datos LOB. Esto significa que el límite de tamaño de LOB cuando utilice el modo de LOB limitado se aplica a datos JSON.

Por ejemplo, supongamos que el modo de LOB limitado está establecido en 4096 KB. En este caso, los datos JSON de más de 4096 KB se truncan en el límite de 4096 KB y no pasan la prueba de validación en PostgreSQL.

La siguiente información de registro muestra JSON truncado debido a la configuración de modo de LOB limitado y error de validación.

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

Las columnas de un tipo de datos definido por el usuario no se migran correctamente

Cuando se replica desde un origen de PostgreSQL, AWS DMS crea la tabla de destino con los mismos tipos de datos para todas las columnas, además de las columnas con los tipos de datos definidos por el usuario. En estos casos, el tipo de datos se crea como de "caracteres variables" en el destino.

Error que indica que no se ha seleccionado ningún esquema de creación

En algunos casos, es posible que aparezca el error «SQL_ERROR SqlState: 3F000:7 Mensaje NativeError: ERROR: no se ha seleccionado ningún esquema para crearlo».

Este error puede producirse cuando la asignación de tablas JSON contiene un valor comodín para el esquema, pero la base de datos de origen no admite ese valor.

No se están replicando las eliminaciones y las actualizaciones en una tabla mediante CDC

Las operaciones de eliminación y actualización durante la captura de datos de cambios (CDC) se ignoran si la tabla de origen no tiene una clave principal. AWS DMS admite la captura de datos de cambios (CDC) para tablas de PostgreSQL con claves principales.

Si una tabla no tiene una clave principal, los registros de escritura anticipada (WAL) no incluyen una imagen anterior de la fila de la base de datos. En este caso, AWS DMS no puede actualizar la tabla. Para replicar las operaciones de eliminación, cree una clave principal en la tabla de origen.

Las instrucciones TRUNCATE no se están propagando

Cuando se usa la captura de datos de cambios (CDC), AWS DMS no admite operaciones TRUNCATE.

Impedir que PostgreSQL capture instrucciones DDL

Puede impedir que un punto de conexión de destino de PostgreSQL capture instrucciones DDL agregando la siguiente instrucción Configuración de punto de conexión.


"CaptureDDLs": "N"

Selección del esquema donde crear los objetos de base de datos para capturar instrucciones DDL

Puede controlar en qué esquema se crean los objetos de la base de datos relacionados con la captura de instrucciones DDL. Agregue la siguiente instrucción de configuración del punto de conexión. El parámetro Configuración de punto de conexión está disponible en la pestaña del punto de conexión de origen.


"DdlArtifactsSchema: "xyzddlschema"

Ausencia de tablas de Oracle después de migrar a PostgreSQL

En este caso, las tablas y los datos por lo general seguirán siendo accesibles.

Oracle utiliza nombres de tabla en mayúsculas y PostgreSQL utiliza nombres de tabla en minúsculas. Cuando realice una migración de Oracle a PostgreSQL, le sugerimos que proporcione determinadas reglas de transformación en la sección de asignación de tablas de la tarea. Estas son reglas de transformación para convertir los nombres de las tablas en mayúsculas y minúsculas.

Si ha migrado las tablas sin utilizar reglas de transformación para convertir las mayúsculas y minúsculas de los nombres de las tablas, escriba los nombres de las tablas entre comillas cuando haga referencia a ellas.

ReplicationSlotDiskUsage aumenta y restart_lsn deja de avanzar durante transacciones largas, como las cargas de trabajo de ETL

Cuando la replicación lógica está habilitada, el número máximo de cambios guardados en la memoria por transacción es de 4 MB. Después de eso, los cambios se transfieren al disco. Como resultado, ReplicationSlotDiskUsage aumenta y restart_lsn no avanza hasta que la transacción se complete o aborte y finalice la reversión. Como se trata de una transacción larga, puede tardar mucho tiempo en restaurarse.

Por lo tanto, evite las transacciones de larga duración cuando la replicación lógica esté habilitada. En su lugar, intente dividir la transacción en varias transacciones más pequeñas.

La tarea que utiliza la consulta como origen no tiene filas copiadas

Para migrar una vista, establezca table-type en all o view. Para obtener más información, consulte Especificación de selección de tablas y reglas de transformaciones desde la consola.

Entre los orígenes que admiten vistas se incluyen los siguientes.

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise (ASE)

Solución de problemas con Microsoft SQL Server

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de Microsoft SQL Server.

Errores al capturar cambios para una base de datos de SQL Server

Los errores durante la captura de datos de cambios (CDC) pueden indicar con frecuencia que no se estaba cumpliendo uno de los requisitos previos. Por ejemplo, el requisito que más comúnmente no se tiene en cuenta es el requisito previo de hacer una copia de seguridad completa de la base de datos. El registro de tareas refleja esta omisión con el siguiente error:


SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)

Revise los requisitos previos mostrados para usar SQL Server como origen en Uso de una base de datos de Microsoft SQL Server como fuente para AWS DMS.

Faltan columnas de identidad

AWS DMS no es compatible con columnas de identidad al crear un esquema de destino. Debe añadirlas después de la primera vez que se haya completado la carga.

Error: SQL Server no admite publicaciones

El error siguiente se genera cuando se utiliza SQL Server Express como un punto de enlace de origen:


RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.

AWS DMS no es compatible actualmente con SQL Server Express como origen o destino.

Los cambios no aparecen en el destino

Para capturar los cambios de forma coherente, AWS DMS precisa que una base de datos de SQL Server de origen esté en modo de recuperación de datos "FULL" o "BULK LOGGED". No se admite el modelo “SIMPLE”.

El modelo de recuperación de SIMPLE registra la información mínima necesaria para permitir a los usuarios recuperar su base de datos. Todas las entradas de registro inactivas se truncan automáticamente cuando se genera un punto de control.

Se siguen registrando todas las operaciones. Sin embargo, tan pronto como se produce un punto de control, el registro se trunca automáticamente. Este truncamiento significa que el registro queda disponible para su reutilización y que las entradas de registro más antiguas se pueden sobrescribir. Cuando se sobrescriben las entradas de registro, no se pueden capturar los cambios. Este problema es el motivo por el que AWS DMS no admite el modelo de recuperación de datos SIMPLE. Para obtener información sobre otros requisitos previos necesarios para usar SQL Server como origen, consulte Uso de una base de datos de Microsoft SQL Server como fuente para AWS DMS.

Tabla no uniforme asignada en las particiones

Durante la captura de datos de cambios (CDC), la migración de una tabla con una estructura especializada se suspende cuando AWS DMS no puede realizar correctamente la CDC en la tabla. Se emiten mensajes como estos:


[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

Al ejecutar CDC en tablas de SQL Server, AWS DMS analiza los tlogs de SQL Server. En cada registro tlog, AWS DMS analiza los valores hexadecimales que contienen los datos de las columnas que se han insertado, actualizado o eliminado durante un cambio.

Para analizar el registro hexadecimal, AWS DMS lee los metadatos de las tablas de sistema de SQL Server. Estas tablas de sistema identifican lo que son las columnas de tabla especialmente estructurada y revelan algunas de sus propiedades internas, como "xoffset" y "null bit position".

AWS DMS espera que los metadatos sean los mismos para todas las particiones sin procesar de la tabla. Sin embargo, en algunos casos, las tablas especialmente estructuradas no tienen los mismos metadatos en todas las particiones. En estos casos, AWS DMS puede incluir CDC en esa tabla para evitar analizar los cambios de forma incorrecta y proporcionar al objetivo datos incorrectos. Entre las soluciones provisionales se incluyen las siguientes:

  • Si la tabla tiene un índice agrupado, realice una reconstrucción del índice.

  • Si la tabla no tiene un índice agrupado, agregue uno a la tabla (puede descartarlo más tarde si lo desea).

Solución de problemas con Amazon Redshift

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de Amazon Redshift.

Carga en un clúster de Amazon Redshift en una región de AWS diferente

No puede cargar en un clúster de Amazon Redshift en una región de AWS diferente de la instancia de replicación de AWS DMS. DMS exige que la instancia de replicación y el clúster de Amazon Redshift estén en la misma región.

Error por existir ya la relación "awsdms_apply_exceptions"

El error “la relación ‘awsdms_apply_exceptions’ ya existe” a menudo se produce cuando un punto de enlace de Redshift se especifica como punto de enlace de PostgreSQL. Para solucionar este problema, modifique el punto de enlace y cambie Target engine a "redshift".

Errores con tablas cuyo nombre comienza con "awsdms_changes"

Los mensajes de error de la tabla con nombres que empiezan por “awsdms_changes” pueden producirse cuando dos tareas que intentan cargar datos en el mismo clúster de Amazon Redshift se ejecutan al mismo tiempo. Debido a la forma en que se nombran las tablas temporales, las tareas simultáneas pueden entrar en conflicto al actualizar la misma tabla.

Visualización de tablas en clústeres con nombres como dms.awsdms_changes000000000XXXX

AWS DMS crea tablas temporales cuando los datos se cargan a partir de archivos almacenados en Amazon S3. Los nombres de estas tablas temporales llevan cada una el prefijo dms.awsdms_changes. Estas tablas son necesarias para que AWS DMS pueda almacenar los datos la primera vez que se cargan y antes de colocarlos en la tabla de destino final.

Permisos necesarios para trabajar con Amazon Redshift

Para utilizar AWS DMS con Amazon Redshift, la cuenta de usuario que utilice para acceder a Amazon Redshift debe tener los permisos siguientes:

  • CRUD (elegir, insertar, actualizar, eliminar)

  • Carga masiva

  • Crear, modificar y eliminar (si lo requiere la definición de la tarea)

Para ver los requisitos previos necesarios para utilizar Amazon Redshift como destino, consulte Uso de una base de datos de Amazon Redshift como destino para AWS Database Migration Service.

Solución de problemas con Amazon Aurora MySQL

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de Amazon Aurora MySQL.

Error por campos CHARACTER SET UTF8 terminados por ',' entre líneas '"' terminadas por '\n'

Si utiliza Amazon Aurora MySQL como destino, es posible que vea un error como el siguiente en los registros. Este tipo de error suele indicar que tiene ANSI_QUOTES como parte del parámetro SQL_MODE. Si ANSI_QUOTES forma parte del parámetro SQL_MODE, las comillas dobles se gestionan como comillas sencillas y se pueden crear problemas al ejecutar una tarea.

Para solucionar este error, elimine ANSI_QUOTES del parámetro SQL_MODE.


2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

Solución de problemas con SAP ASE

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de SAP ASE.

Error: las columnas de LOB tienen valores NULL cuando el origen tiene un índice único compuesto con valores NULL

Cuando se utiliza SAP ASE como origen con tablas configuradas con un índice único compuesto que permite valores NULL, es posible que los valores de LOB no migren durante la replicación en curso. Este comportamiento suele ser el resultado de que ANSI_NULL esté establecido en 1 de forma predeterminada en el cliente de la instancia de replicación de DMS.

Para garantizar que los campos de LOB migren correctamente, incluya la configuración de punto de conexión 'AnsiNull=0' al punto de conexión de origen de AWS DMS de la tarea.

Solución de problemas con IBM Db2

A continuación, puede obtener información acerca de la resolución de problemas específicos mediante AWS DMS con bases de datos de IBM Db2.

Error: la tarea no admite la reanudación a partir de la marca temporal

Para la replicación continua (CDC), si planea iniciar la replicación desde una marca temporal específica, establezca el atributo de conexión StartFromContext en la marca temporal requerida. Para obtener más información, consulte Configuración del punto de conexión al utilizar Db2 LUW. El establecimiento de StartFromContext en la marca temporal requerida evita el siguiente problema:

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.