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 volcado en la instancia de replicación. Puede proporcionar estos archivos a AWS Support en caso de que surja un problema que requiera solución. De manera predeterminada, DMS purga los archivos de seguimiento y volcado que tienen más de treinta días de antigüedad. Para dejar de recopilar archivos de rastreo y volcado, abra un caso con AWS Support.

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:

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.

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 DMS no crea registros de CloudWatch

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

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:

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:

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 AWS Database Migration Service metrics.

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:

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 temporales son confusas en las consultas de Athena, utilice Consola de administración de AWS o la acción ModifyEndpoint para establecer el valor parquetTimestampInMillisecond para el punto de conexión de 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 DMS puede utilizar dos métodos para capturar 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 de LOB. Para capturar cambios en columnas LOB en Oracle 12c, utilice Binary Reader.

Cambio entre Oracle LogMiner y Binary Reader

AWS DMS puede utilizar dos métodos para capturar cambios en una base de datos origen de Oracle: Binary Reader y Oracle LogMiner. Oracle LogMiner es la opción predeterminada. Si desea cambiar y usar Binary Reader para capturar cambios, haga lo siguiente:

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:

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:

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 de punto de conexión cuando se utiliza Oracle como origen para 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:

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

No se han podido obtener los datos de LOB

Los errores en la búsqueda de LOB (objetos grandes) en AWS DMS se producen en circunstancias específicas durante los procesos de migración de datos. Durante la fase de carga completa, AWS DMS emplea el método de búsqueda para la migración de datos de LOB cuando la tarea está configurada en el modo FULL LOB. En particular, durante la fase de CDC (captura de datos de cambio), AWS DMS utiliza de forma coherente el método de búsqueda, independientemente de la configuración de LOB.

AWS DMS primero replica las filas sin la columna LOB, obtiene los datos de LOB con un comando SELECT y ejecuta un comando UPDATE para replicar el campo LOB en el destino. Esta operación secuencial de INSERT y UPDATE caracteriza el comportamiento de la búsqueda. La búsqueda de LOB durante la fase de CDC no es aplicable a todos los motores de bases de datos. Además, según el tamaño de los datos, las tareas pueden replicar filas insertadas junto con datos de columnas.

Un error en el proceso de búsqueda de LOB es un problema frecuente que se puede producir durante la migración. Se muestra el mensaje de error “Failed to get lob data, going to set to null”. Durante este error, los datos de la tabla parcial del destino, en particular las columnas LOB, aparecen como valores NULL. Hay varios factores que pueden generar estos errores:

Para solucionar estos errores de búsqueda de LOB, puede hacer lo siguiente:

Estos pasos para gestionar los errores de búsqueda de LOB garantizan que los datos se migren de forma más fiable y ayudan a mantener la integridad de los datos durante todo el proceso.

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:

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

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.

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 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.

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 NativeError: 7 Message: ERROR: no se ha seleccionado ningún esquema en el que crear”.

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.

Secuencia de bytes no válida para codificar UTF8

La migración de datos de Oracle a PostgreSQL con AWS DMS presenta desafíos únicos debido a las diferencias de codificación de los conjuntos de caracteres entre las dos bases de datos. El juego de caracteres AL32UTF8 de Oracle, que es completamente compatible con los caracteres de 4 bytes, plantea un problema importante, mientras que la implementación del conjunto de caracteres UTF8 de PostgreSQL carece de esta capacidad. Esta disparidad suele provocar errores en la migración, especialmente cuando se trata de tablas o columnas del origen de Oracle que contienen caracteres de 4 bytes.

Durante los intentos de migración, es posible que reciba mensajes de error en los registros de tareas de DMS y en los registros de la base de datos de destino de PostgreSQL que indican que hay problemas con las secuencias de bytes UTF8 no válidas. Aparece un mensaje de error típico: “ERROR: invalid byte sequence for encoding “UTF8”: 0xed 0xb0 0x86”. Para resolver este problema, AWS DMS proporciona una solución a través de la configuración ReplaceChars. Para ello, sustituye o elimina automáticamente los caracteres no válidos durante el proceso de migración. Este enfoque evita de forma eficaz los errores relacionados con la codificación sin necesidad de modificar los datos de origen.

Para obtener más información, consulte el punto Validación y sustitución de conjuntos de caracteres en el tema Configuración de la tarea de sustitución de caracteres.

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.

Error de replicación continua después de que RDS para SQL Server conmute por error en la instancia secundaria

Si una instancia de SQL Server de origen conmuta por error en la instancia secundaria, la replicación continua de AWS DMS sigue intentando conectarse y continúa replicándose una vez que el origen vuelve a estar en línea. Sin embargo, en el caso de las instancias MAZ de RDS para SQL Server, en determinadas circunstancias el propietario de la base de datos secundaria puede establecerse en NT AUTHORITY\SYSTEM. Tras una conmutación por error, se provoca que la tarea de DMS genere el siguiente error:

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

Para solucionarlo, siga los pasos que se indican en Cambio del db_owner a la cuenta de rdsa de la base de datos y, a continuación, reanude la tarea de DMS.

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 origen 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

AWS DMSPara capturar los cambios de forma coherente, 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 origen 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:

Error: la tarea de CDC ha emitido el error Bad Envelope, contexto de datos o código LCX no válidos al procesar una transacción

El error Bad Envelope se produce cuando AWS DMS no puede validar tipos de eventos específicos en la replicación de la fase de CDC durante el proceso de validación. Este error suele producirse al reanudar las tareas a partir de una marca de tiempo específica que se encuentra en mitad de una transacción. En esos casos, la tarea podría leer un evento de confirmación sin encontrar el evento de “inicio de transacción” correspondiente. Eso generaría un contexto de transacción no válido y desencadenaría el error “Bad Envelope”.

Para resolver este problema, debe modificar la configuración de punto de conexión de origen de SQL Server configurando el parámetro ignoreTxnCtxValidityCheck en true en la sección Atributos de conexión adicionales antes de reanudar la tarea. Si el error persiste después de implementar esta solución, envíe un ticket de soporte a AWS.

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:

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.

La tabla ha suspendido una tabla con el error “Failed to build 'where' statement”.

En DMS, cuando se intenta actualizar un registro de una tabla que no tiene ninguna clave principal, el sistema no puede crear una condición WHERE y muestra el siguiente error:

 [TARGET_APPLY ]E: Failed to build 'where' statement

Esto puede ocurrir debido a varios problemas o limitaciones conocidos: