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 tareas no se mueveLa tarea se completó pero no se migró nadaFaltan las claves externas y los índices secundariosAWS DMSno crea CloudWatch registrosSe producen problemas al conectarse a Amazon RDSSe producen problemas de redEl CDC se bloquea después de una carga completaLos errores de violación de la clave principal se producen al reiniciar una tareaSe produce un error en la carga inicial de un esquemaLas tareas fallan por un error desconocidoReiniciar la tarea carga las tablas desde el principioLa cantidad de tablas por tarea causa problemasLas tareas fallan cuando se crea una clave principal en una columna LOBLos registros duplicados se producen en una tabla de destino sin una clave principalLos extremos de origen se encuentran en el rango de IP reservadasLas marcas de tiempo están distorsionadas en las consultas de Amazon AthenaSolución de problemas con OracleSolución de problemas con MySQLSolución de problemas con 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

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, encontrará temas sobre la solución de problemas con elAWS Database Migration Service (AWS DMS). Estos temas pueden ayudarlo a resolver problemas comunes utilizando ambas bases de datos de terminalesAWS DMS y algunas seleccionadas.

Si ha abierto un caso deAWS Support, su ingeniero de soporte podría identificar un posible problema con una de las configuraciones de la base de datos de sus terminales. El ingeniero también puede pedirle que ejecute un script de soporte para devolver 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, consulteTrabajo con scripts de soporte de diagnóstico enAWS DMS.

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 por la que una tarea de migración se ejecuta lentamente es que los recursos asignados a la instancia deAWS DMS replicación son inadecuados. Para asegurarte de que la instancia tiene recursos suficientes para las tareas que estás ejecutando en ella, comprueba el uso de la CPU, la memoria, los archivos de intercambio y las IOPS de la instancia de replicación. Por ejemplo, varias tareas con Amazon Redshift como punto final requieren un uso intensivo 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, consulteElegir el mejor tamaño para una instancia de replicación.

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

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

  • Desactive las copias de seguridad o el registro automáticos en la base de datos de destino durante la carga y vuelva a activar esas funciones una vez finalizada la migración.

  • Si la función está disponible en su destino, utilice las 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 acerca de la optimización para LOB, consulteConfiguración de las tareas de los metadatos de destino.

La barra de estado de tareas 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.

Para una tarea con una sola tabla que no tenga estadísticas de filas estimadas, noAWS DMS se puede proporcionar ningún tipo de estimación porcentual completa. En este caso, utilice el estado de la tarea y la indicación de las filas cargadas para confirmar que la tarea se está ejecutando y progresando.

La tarea se completó pero no se migró nada

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

Faltan las claves externas y los índices secundarios

AWS DMScrea tablas, claves principales y, en algunos casos, índices únicos, pero no crea ningún otro objeto que no sea necesario para migrar los datos de la fuente de manera eficiente. 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 laAWS Schema Conversion Tool (AWS SCT) si va a migrar a un motor de base de datos distinto del de la base de datos origen para migrar objetos secundarios.

AWS DMSno crea CloudWatch registros

Si la tarea de replicación no crea CloudWatch registros, asegúrese de que su cuenta tenga ladms-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. Seleccione la pestaña Funciones. Elija Create role (Crear rol).

  3. En la sección Select type of trusted entity (Seleccionar tipo de entidad de confianza), elija Servicio de AWS.

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

  5. Elija Next: Permissions (Siguiente: permisos).

  6. EntraAmazonDMSCloudWatchLogsRole en el campo de búsqueda y marca la casilla situada junto a AmazonDMSCloudWatchLogsRole. Esto otorgaAWS DMS permisos de acceso CloudWatch.

  7. Elija Next: Tags (Siguiente: etiquetas).

  8. Elija Next: Review (Siguiente: revisar).

  9. Introduzcadms-cloudwatch-logs-role el nombre del rol. Este nombre distingue entre mayúsculas y minúsculas.

  10. Elija Create role (Crear rol).

Se producen problemas al conectarse a Amazon RDS

Puede haber varios motivos por los que no pueda conectarse a una instancia de base de datos de Amazon RDS que haya establecido como origen o destino. A continuación se muestran algunos elementos que debe comprobar:

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

  • Compruebe que el valor del punto de enlace que se muestra en la consola de Amazon RDS para la instancia sea el mismo que el identificador de punto de enlace que utilizó para crear elAWS DMS punto de enlace.

  • Compruebe que el valor del puerto que se muestra en la consola de Amazon RDS para la instancia sea el mismo que el del puerto asignado alAWS DMS punto final.

  • 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 deAWS DMS replicación y la instancia de base de datos de Amazon RDS no están en la misma nube privada virtual (VPC), compruebe que la instancia de base de datos sea de acceso público.

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, usted modifica este grupo de seguridad o usa su propio grupo de seguridad. Si es así, como mínimo, asegúrese de dar la salida a los puntos finales de origen y destino en sus respectivos puertos de bases de datos.

Otros problemas relacionados con la configuración pueden incluir los siguientes:

  • Instancia de replicación y puntos de enlace de origen y destino en la misma VPC: el grupo de seguridad utilizado por los puntos de enlace debe permitir la entrada al puerto de la base de datos desde la instancia de replicación. Asegúrese de que el grupo de seguridad utilizado por la instancia de replicación acceda a los puntos finales. O bien, puede crear una regla en el grupo de seguridad utilizado por los endpoints que permita el acceso a la dirección IP privada de la instancia de replicación.

  • El extremo de origen está fuera de la VPC utilizada por la instancia de replicación (mediante una puerta de enlace de Internet). El grupo de seguridad de la VPC debe incluir reglas de enrutamiento que envíen el tráfico que no es para 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 extremo de origen está fuera de la VPC utilizada por la instancia de replicación (mediante una puerta de enlace NAT). Puede configurar una puerta de enlace de traducción de direcciones de red (NAT) mediante una única dirección IP elástica enlazada a una única elastic network interface. 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 final de la base de datos mediante la dirección IP pública de la puerta de enlace NAT. En este caso, la entrada al extremo de la base de datos fuera de la VPC debe permitir la entrada desde la dirección NAT en lugar de desde la dirección IP pública de la instancia de replicación.

Para obtener más información acerca de su propio servidor de nombres local, consulte Uso de su propio servidor de nombres en las instalaciones.

El CDC se bloquea después de una 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á configurado en No hacer nada o Truncar. En este caso, ha indicado que no se debeAWS DMS realizar ninguna configuración en las tablas de destino, incluida la creación de índices principales y únicos. Si no ha creado claves principales o únicas en las tablas de destino,AWS DMS realiza un análisis completo de la tabla para cada actualización. Este enfoque puede afectar el rendimiento de manera significativa.

Los errores de violación de la clave principal se producen al reiniciar 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 la tabla de destino está configurada en No hacer nada,AWS DMS no realiza ninguna preparación en la tabla de destino, incluida la limpieza de los datos insertados de una tarea anterior.

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

Se produce un error en la carga inicial de un esquema

En algunos casos, la carga inicial de los esquemas puede fallar con un error deOperation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

En esos casos, la cuenta de usuario utilizada porAWS DMS para conectarse al extremo de origen no tiene los permisos necesarios.

Las tareas fallan por un error desconocido

La causa de los tipos de error desconocidos puede variar. Sin embargo, a menudo nos damos cuenta de que el problema implica la asignación de recursos insuficientes a la instancia deAWS DMS replicación.

Para asegurarte de que la instancia de replicación tiene recursos suficientes para realizar la migración, comprueba el uso que hace la instancia de la CPU, la memoria, los archivos de intercambio y las IOPS. 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 DMSreinicia la carga de la tabla desde el principio cuando no ha terminado la carga inicial de una tabla. Cuando se reinicia una tarea, se vuelven aAWS DMS cargar las tablas desde el principio cuando la carga inicial no se completó.

La cantidad de tablas por tarea causa problemas

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

Las tareas fallan cuando se crea una clave principal en una columna LOB

En los modos 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, añada otra columna como clave principal y elimine la clave principal de la columna LOB.

Los registros duplicados se producen en una tabla de destino sin una clave principal

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

Los extremos de origen se encuentran en el rango de IP reservadas

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

  1. Busque una instancia de Amazon EC2 que no esté en el rango reservado y 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 la instancia EC2 y el puerto de base de datos indicados anteriormente para elAWS DMS punto final. Asegúrese de que el punto final tenga el grupo de seguridad que permiteAWS DMS comunicarse con él en el puerto de la base de datos.

Las marcas de tiempo están distorsionadas en las consultas de Amazon Athena

Si las marcas de tiempo están distorsionadas en las consultas de Athena, utilice la ModifyEndpointacciónAWS Management Console o para establecer elparquetTimestampInMillisecond valor de su punto de conexión de Amazon S3 entrue. Para obtener más información, consulte S3Settings.

Solución de problemas con Oracle

A continuación, puede obtener más más más más más información acerca de la solución de problemas específicos del usoAWS DMS con las bases de datos.

Obtención de datos de consultas

Puede extraer datos una vez de una vista; no puede usarlos para una replicación continua. Para poder extraer datos de las vistas, debe añadir el siguiente código a la sección de configuración de Endpoint de la página de terminales fuente de Oracle. Al extraer 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 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 la opción predeterminada. 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 laAWS DMS consolaAWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Endpoints.

  3. Elija el punto de enlace origen de Oracle que desea usar Binary Reader.

  4. Elija Modify (Modificar).

  5. Elija Avanzado y, a continuación, añada el siguiente código para los atributos de conexión adicionales.

    
useLogminerReader=N

  6. Utilice una herramienta para desarrolladores de Oracle, como SQL-Plus, para conceder los siguientes privilegios adicionales a la cuenta deAWS DMS usuario utilizada para conectarse al endpoint 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);

Agregue automáticamente un registro complementario a un punto final 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 laAWS DMS consolaAWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Endpoints.

  3. Elija el punto de enlace origen de Oracle al que desea agregar un registro complementario.

  4. Elija Modify (Modificar).

  5. Elija Avanzado y, a continuación, añada el siguiente código al cuadro de texto Atributos de conexión adicionales:

    
addSupplementalLogging=Y

  6. Elija Modify (Modificar).

No se capturan 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 identificador generado por el sistema como clave principal y migre 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 discrepancia en los conjuntos de caracteres utilizados por las bases de datos de origen y destino.

En otro de estos números, la configuración del soporte de idiomas nacionales (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 Oracle NUMBER se convierte en varios tipos deAWS DMS datos, según la precisión y la escala de NUMBER. Estas conversiones pueden consultarse aquí Tipos de datos de origen para Oracle. La forma en que se convierte el tipo NUMBER también puede verse afectada por el uso de la configuración de punto final del Oracle de origen. Estas configuraciones de punto de conexión se documentan enConfiguración de endpoint cuando se utiliza Oracle como fuente paraAWS DMS.

Faltan registros durante la carga completa

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

Puede modificar la configuración de laTransactionConsistencyTimeout tarea 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 laFailOnTransactionConsistencyBreached tarea esfalse. Esto significa que seAWS DMS siguen aplicando otras transacciones, pero se omiten las transacciones abiertas. Si desea que la tarea falle cuando las transacciones abiertas no se cierren a tiempo, puedeFailOnTransactionConsistencyBreached configurarla entrue.

Error de tabla

Table Erroraparece en las estadísticas de la tabla durante la replicación si unaWHERE cláusula no hace referencia a una columna de clave principal y no se utiliza el registro complementario para 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 Activación del modo complementario.

Error: no se pueden recuperar los identificadores de destino archivados de Redo Log de Oracle

Este error se produce cuando su fuente 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 siguiente procedimiento para cambiar los archivos de registro. Elswitch_logfile procedimiento no tiene parámetros.

exec rdsadmin.rdsadmin_util.switch_logfile;

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

ALTER SYSTEM SWITCH LOGFILE ;

Evaluación del rendimiento de lectura de los registros de rehacer o archivar de Oracle

Si tiene problemas de rendimiento con su fuente de Oracle, puede evaluar el rendimiento de lectura de sus registros de rehacer o archivar de Oracle para encontrar formas de mejorar el rendimiento. Para probar el rendimiento de lectura de registros de rehacer o archivar, utilice la imagen de máquina de Amazon (AMI) deAWS DMS diagnóstico.

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

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

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

  • Utilice el método PL/SQL (dbms_lob.read) para evaluar el rendimiento del archivo de redo log.

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

  • Utilice subprocesos múltiples para evaluar el rendimiento de lectura en ASMFile.

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

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

Para probar el rendimiento de lectura en un archivo de registro redo o archivado de Oracle

  1. Cree una AMIAWS DMS, instancia de Amazon EC2, y conéctese a ella.

    Para obtener más información, consulte Trabajar con la AMIAWS DMS de diagnóstico.

  2. Ejecute el comando awsreplperf.

    $ awsreplperf

    El comando muestra las opciones deAWS DMS Oracle Read Performance Utility.

    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 en la lista.

  4. Introduzca la siguiente información de registro de archivos y conexión a la base de datos.

    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 que se muestra para obtener información relevante sobre el rendimiento de lectura. Por ejemplo, a continuación se muestran los resultados que pueden resultar de seleccionar la opción número 2, Leer con LogMiner.

    leer la salida de la utilidad de rendimiento

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

Pasos siguientes

  • 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 final y revise las secciones Tiempo de espera, Perfil de carga y Perfil de IO. A continuación, ajuste cualquier configuración anormal que pueda mejorar el rendimiento de lectura. Por ejemplo, si tus archivos de redo log tienen hasta 2 GB, intenta aumentar LOG_BUFFER a 200 MB para ayudar a mejorar el rendimiento.

  • Revise las prácticasAWS DMS recomendadas para asegurarse de que la instancia, la tarea y los puntos de enlace de replicación de DMS estén configurados de manera óptima.

Solución de problemas con MySQL

A continuación, puede obtener más más más más más más información acerca de la solución de problemas específicos del usoAWS DMS con las 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 tiene una tarea con LOBs que se está desconectando de un destino de MySQL, es posible que vea los siguientes tipos de errores en el registro de tareas. 

[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 tengas que ajustar algunas de las configuraciones de las tareas.

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 de sistema de MySQL, consulte Variables de sistema de 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 laAWS DMS consolaAWS Management Console y ábrala en https://console.aws.amazon.com/dms/v2/.

  2. Elija Endpoints.

  3. Elija el punto de enlace compatible con MySQL al que desea agregar la confirmación automática.

  4. Elija Modify (Modificar).

  5. Elija Avanzado y, a continuación, añada el siguiente código al cuadro de texto Atributos de conexión adicionales:

    
Initstmt= SET AUTOCOMMIT=1

  6. Elija Modify (Modificar).

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

Para deshabilitar las comprobaciones de claves externas en MySQL, añada lo siguiente a los atributos de conexión adicionales de la sección Avanzado del terminal de MySQL, Amazon Aurora MySQL de destino o MariaDB.

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

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

  2. Elija Endpoints.

  3. Elija el punto final de destino de MySQL, Aurora MySQL o MariaDB en el que desee deshabilitar las claves externas.

  4. Elija Modify (Modificar).

  5. Elija Avanzado y, a continuación, añada el siguiente código al cuadro de texto Atributos de conexión adicionales:

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. Elija Modify (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 de «eventos incorrectos»

Las entradas de «eventos incorrectos» 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 compatible en el extremo de la base de datos de origen. Las operaciones de DDL no admitidas provocan 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 comienzan a capturar los cambios en un momento posterior a la ejecución de la operación de DDL no admitida.

Captura de datos de cambios con MySQL 5.5

AWS DMSchange data capture (CDC) para bases de datos compatibles con Amazon RDS MySQL requiere un registro binario completo basado en filas de imágenes, algo que no se admite en la versión 5.5 o inferior de MySQL. 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 diferente al de otros motores de bases de datos, como Oracle y SQL Server. Estos motores actualizan una fila, incluso cuando el valor de reemplazo 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 configuraAWS 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 generado automáticamente que se crea puede superar los límites permitidos 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 configurado 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. Se puede utilizar el siguiente comando para configurar 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. Puede que tengas que reiniciar la tarea deAWS DMS migración desde el principio si agregas esta configuración de punto final.

Por ejemplo, la siguiente configuración de punto final podría usarse para un punto final de origen de MySQL en el que el conjunto de caracteres de origen seaUtf8 olatin1. 65001 es el identificador de la página de códigos UTF8. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

Solución de problemas con PostgreSQL

A continuación, puede obtener más más más más información acerca de la solución de problemas específicos del usoAWS DMS con las 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 la limitación del tamaño del LOB cuando se utiliza el modo LOB limitado se aplica a los datos JSON.

Por ejemplo, supongamos que el modo 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 4.096 KB y no pasan la prueba de validación en PostgreSQL.

La siguiente información de registro muestra el JSON que se truncó debido a la configuración limitada del modo LOB y a una validación fallida.

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 están migrando 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: NativeError 3F000:7 Mensaje: ERROR: no se ha seleccionado ningún esquema para crearlo».

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

Las eliminaciones y actualizaciones de una tabla no se replican mediante los 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 DMSadmite 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, noAWS DMS se puede actualizar la tabla. Para replicar las operaciones de eliminación, cree una clave principal en la tabla de origen.

Las instrucciones truncadas no se propagan

Cuando se utiliza la captura de datos de cambios (CDC), las operaciones de TRUNCATE no son compatibles conAWS DMS.

Impedir que PostgreSQL capture instrucciones DDL

Para evitar que un extremo de destino de PostgreSQL capture sentencias DDL, añada la siguiente sentencia de configuración de Endpoint.


"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. Añada la siguiente sentencia de configuración de Endpoint. El parámetro de configuración del punto final está disponible en la pestaña del extremo de origen.


"DdlArtifactsSchema: "xyzddlschema"

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

En este caso, las tablas y los datos suelen seguir siendo accesibles.

De forma predeterminada, Oracle usa nombres de tablas en mayúsculas y PostgreSQL usa nombres de tablas en minúsculas. Cuando realice una migración de Oracle a PostgreSQL, le sugerimos que proporcione ciertas reglas de transformación en la sección de mapeo de tablas de la tarea. Estas son reglas de transformación para convertir mayúsculas y minúsculas de los nombres de las tablas.

Si migró las tablas sin utilizar reglas de transformación para convertir mayúsculas y minúsculas en 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 las transacciones largas, como las cargas de trabajo de ETL

Cuando la replicación lógica está habilitada, la cantidad máxima 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 yrestart_lsn no avanza hasta que la transacción se complete o anule y finalice la reversión. Dado que es una transacción larga, puede tardar mucho tiempo en revertirla.

Por lo tanto, evite las transacciones de larga ejecución cuando la replicación lógica esté habilitada. En su lugar, intenta 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,table-type definaall oview. Para obtener más información, consulte Especificar las reglas de selección y transformación de tablas desde la consola.

Entre las fuentes que admiten vistas se incluyen las 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 sobre la solución de problemas específicos del usoAWS DMS con las 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) a menudo pueden indicar que no se cumplió 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 enumerados para usar SQL Server como fuente enUso de una base de datos de Microsoft SQL Server como origen para AWS DMS.

Faltan columnas de identidad

AWS DMSno admite 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 es compatible con las 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 DMSactualmente no admite SQL Server Express como origen ni como destino.

Los cambios no aparecen en tu objetivo

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". El modelo «SIMPLE» no es compatible.

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 se pueden sobrescribir las entradas de registro más antiguas. Cuando se sobrescriben las entradas del registro, no se pueden capturar los cambios. Este problema es el motivo por elAWS DMS que no es compatible con el modelo de recuperación de datos SIMPLE. Para obtener información sobre otros requisitos previos necesarios para utilizar SQL Server como fuente, consulteUso de una base de datos de Microsoft SQL Server como origen para AWS DMS.

Tabla no uniforme mapeada en particiones

Durante la captura de datos de cambios (CDC), la migración de una tabla con una estructura especializada se suspende cuando no seAWS DMS puede realizar correctamente el 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 con estructuras especiales no tienen los mismos metadatos en todas sus particiones. En estos casos,AWS DMS puede suspender los CDC en esa tabla para evitar analizar los cambios de forma incorrecta y proporcionar al objetivo datos incorrectos. Las soluciones son las siguientes:

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

  • Si la tabla no tiene un índice agrupado, añada un índice agrupado a la tabla (puede eliminarlo más adelante si lo desea).

Solución de problemas con Amazon Redshift

A continuación, puede obtener más más más más más más información acerca de la solución de problemas específicos del usoAWS DMS con las bases de datos de Amazon Redshift.

Cargar en un clúster de Amazon Redshift en otraAWS región

No puede cargar en un clúster de Amazon Redshift en unaAWS región diferente a la de su instancia deAWS DMS replicación. El DMS requiere 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 tablas con nombres que comienzan por «awsdms_changes» pueden aparecer cuando dos tareas que intentan cargar datos en el mismo clúster de Amazon Redshift se ejecutan simultáneamente. Debido a la forma en que se nombran las tablas temporales, las tareas simultáneas pueden entrar en conflicto al actualizar la misma tabla.

Ver tablas en clústeres con nombres como DMS.AWSDMS_Changes000000000xxxx

AWS DMScrea tablas temporales cuando se cargan datos de archivos almacenados en Amazon S3. Cada uno de los nombres de estas tablas temporales tiene el prefijodms.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

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

  • CRUD (seleccionar, insertar, actualizar, eliminar)

  • Carga a granel

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

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

Solución de problemas con Amazon Aurora MySQL

A continuación, puede obtener más más más más más información acerca de la solución de problemas específicos del usoAWS DMS de las bases de datos 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. Al incluir ANSI_QUOTES como parte del parámetro SQL_MODE, las comillas dobles se manejan como si fueran comillas y puede generar 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 más más más más más información acerca de la solución de problemas específicos del usoAWS DMS con las bases de datos de SAP ASE.

Error: las columnas LOB tienen valores NULOS cuando la fuente tiene un índice único compuesto con valores NULL

Cuando se utiliza SAP ASE como fuente 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 se haya establecido en 1 de forma predeterminada en el cliente de instancias de replicación de DMS.

Para garantizar que los campos LOB migren correctamente, incluya la configuración'AnsiNull=0' de punto final en el punto final deAWS DMS origen de la tarea.

Solución de problemas con IBM

A continuación, puede obtener información sobre la solución de problemas específicos del usoAWS DMS con las bases de datos de IBM Db2.

Error: No se admite reanudar desde la marca de tiempo Tarea

Para la replicación continua (CDC), si planea iniciar la replicación desde una marca de tiempo específica,StartFromContext defina el atributo de conexión en la marca de tiempo requerida. Para obtener más información, consulte Configuración de endpoint cuando se utiliza Db2 LUW. SiStartFromContext se establece la marca de tiempo requerida, se 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.