Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

AWS Validación de datos DMS

Modo de enfoque
AWS Validación de datos DMS - AWS Database Migration Service

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.

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.

AWS DMS proporciona soporte para la validación de datos para garantizar que los datos se hayan migrado con precisión del origen al destino. Si está habilitada, la validación comienza inmediatamente después de que se haya realizado la carga completa de una tabla. La validación compara los cambios incrementales de una tarea habilitada para CDC a medida que se producen.

Durante la validación de los datos, AWS DMS compara cada fila del origen con la fila correspondiente del destino, comprueba que las filas contienen los mismos datos e informa de cualquier discrepancia. Para ello, realiza AWS DMS las consultas adecuadas para recuperar los datos. Tenga en cuenta que estas consultas consumirán recursos adicionales en el origen y el destino, así como recursos de red adicionales.

Para una tarea exclusiva de CDC con la validación habilitada, todos los datos preexistentes de una tabla se validan antes de iniciar la validación de los nuevos datos.

La validación de datos funciona con las siguientes bases de datos de origen siempre que las AWS DMS admitan como puntos finales de origen:

  • Oracle

  • Base de datos compatible con PostgreSQL (PostgreSQL, Aurora PostgreSQL o Aurora sin servidor para PostgreSQL)

  • Base de datos compatible con MySQL (MySQL, MariaDB, Aurora MySQL o Aurora sin servidor para MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

La validación de datos funciona con las siguientes bases de datos de destino siempre que las AWS DMS respalde como puntos finales de destino:

  • Oracle

  • Base de datos compatible con PostgreSQL (PostgreSQL, Aurora PostgreSQL o Aurora sin servidor para PostgreSQL)

  • Base de datos compatible con MySQL (MySQL, MariaDB, Aurora MySQL o Aurora sin servidor para MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

  • Amazon Redshift

  • Amazon S3. Para obtener información sobre la validación de los datos de destino de Amazon S3, consulte Validación de datos de destino de Amazon S3.

Para obtener más información acerca de los puntos de enlace admitidos, consulte Trabajar con puntos finales AWS de DMS.

La validación de datos requiere más tiempo, más allá de la cantidad necesaria para la migración en sí. El tiempo extra necesario depende de la cantidad de datos que se ha migrado.

Para obtener más información sobre estas opciones, consulte Configuración de tareas de validación de datos.

Para ver un ejemplo de la configuración de tareas de ValidationSettings en un archivo JSON, consulte Ejemplo de configuración de tarea.

Estadísticas de la tarea de replicación

Cuando la validación de datos está habilitada, AWS DMS proporciona las siguientes estadísticas a nivel de tabla:

  • ValidationState—El estado de validación de la tabla. El parámetro puede tener los siguientes valores:

    • Not enabled: la validación no está habilitada para la tabla en la tarea de migración.

    • Pending records: algunos registros en la tabla están a la espera de validación.

    • Discrepancia en los registros: algunos registros de la tabla no coinciden entre origen y destino. Se puede producir una discrepancia por varios motivos. Para obtener más información, consulte la tabla awsdms_control.awsdms_validation_failures_v1 en el punto de enlace de destino.

    • Suspended records (Registros suspendidos): no se han podido validar algunos registros de la tabla.

    • No primary key (No hay clave principal): no se ha podido validar la tabla porque no tenía clave principal.

    • Table error (Error de tabla): la tabla no se ha validado porque estaba en un estado de error y no se han migrado algunos datos.

    • Validada: se han validado todas las filas de la tabla. Si se actualiza la tabla, el estado puede cambiar de Validated.

    • Error: no se ha podido validar la tabla debido a un error inesperado.

    • Validación pendiente: la tabla está pendiente de validación.

    • Preparación de la tabla: preparación de la tabla habilitada en la tarea de migración para su validación.

    • Revalidación pendiente: todas las filas de la tabla están pendientes de validación tras la actualización de la tabla.

  • ValidationPending—El número de registros que se han migrado al destino, pero que aún no se han validado.

  • ValidationSuspended—La cantidad de registros que no AWS DMS se pueden comparar. Por ejemplo, si un registro del origen se actualiza constantemente, no AWS DMS se puede comparar el origen y el destino.

  • ValidationFailed—El número de registros que no pasaron la fase de validación de datos.

Para ver un ejemplo de la configuración de tareas de ValidationSettings en un archivo JSON, consulte Ejemplo de configuración de tarea.

Puede ver la información de validación de datos mediante la consola AWS CLI, la AWS DMS API o la consola.

  • En la consola, puede elegir validar una tarea cuando crea o modifica la tarea. Para ver el informe de validación de datos mediante la consola, elija la tarea en la página Tasks y seleccione la pestaña Table statistics en la sección de detalles.

  • Con la CLI, establezca el parámetro EnableValidation en true al crear o modificar una tarea para iniciar la validación de datos. En el siguiente ejemplo se crea una tarea y permite la validación de datos.

    create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}'

    Utilice el comando describe-table-statistics para recibir el informe de validación de datos en formato JSON. El siguiente comando muestra el informe de validación de datos.

    aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q

    El informe debería ser similar al siguiente.

    { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } }
  • Con la AWS DMS API, cree una tarea mediante la CreateReplicationTaskacción y establezca el EnableValidation parámetro en true para validar los datos migrados por la tarea. Usa la DescribeTableStatisticsacción para recibir el informe de validación de datos en formato JSON.

Estadísticas de tareas de replicación con Amazon CloudWatch

Cuando Amazon CloudWatch está activado, AWS DMS proporciona las siguientes estadísticas de tareas de replicación:

  • ValidationSucceededRecordCount— Número de filas que se AWS DMS validaron, por minuto.

  • ValidationAttemptedRecordCount— Número de filas en las que se intentó la validación, por minuto.

  • ValidationFailedOverallCount— Número de filas en las que la validación falló.

  • ValidationSuspendedOverallCount— Número de filas en las que se suspendió la validación.

  • ValidationPendingOverallCount— Número de filas en las que la validación aún está pendiente.

  • ValidationBulkQuerySourceLatency— AWS DMS puede realizar la validación de datos de forma masiva, especialmente en determinadas situaciones durante una replicación a plena carga o en curso, cuando hay muchos cambios. Esta métrica indica la latencia necesaria para leer un conjunto masivo de datos desde el punto de enlace de origen.

  • ValidationBulkQueryTargetLatency— AWS DMS puede realizar la validación de datos de forma masiva, especialmente en algunos escenarios durante una replicación a plena carga o en curso, cuando hay muchos cambios. Esta métrica indica la latencia necesaria para leer un conjunto masivo de datos en el punto de enlace de destino.

  • ValidationItemQuerySourceLatency— Durante la replicación en curso, la validación de datos puede identificar los cambios en curso y validarlos. Esta métrica indica la latencia para leer esos cambios desde el origen. La validación puede ejecutar más consultas de las necesarias en función del número de cambios, si hay errores durante la validación.

  • ValidationItemQueryTargetLatency— Durante la replicación continua, la validación de datos puede identificar los cambios en curso y validarlos fila por fila. Esta métrica nos indica la latencia para leer esos cambios desde el destino. La validación puede ejecutar más consultas de las necesarias en función del número de cambios, si hay errores durante la validación.

Para recopilar información de validación de datos a partir de las estadísticas CloudWatch habilitadas, seleccione Habilitar CloudWatch registros al crear o modificar una tarea mediante la consola. A continuación, para ver la información de la validación de datos y garantizar que los datos se han migrado de forma precisa del origen al destino, haga lo siguiente.

  1. Elija la tarea en la página Tareas de migración de base de datos.

  2. Selecciona la pestaña de CloudWatch métricas.

  3. Seleccione Validación en el menú desplegable.

Volver a validar tablas durante una tarea

Mientras se ejecuta una tarea, puede solicitar la validación AWS DMS de datos.

AWS Management Console

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

    Si ha iniciado sesión como usuario AWS Identity and Access Management (IAM), asegúrese de tener los permisos de acceso adecuados AWS DMS. Consulte los permisos necesarios. Permisos de IAM necesarios para utilizar AWS DMS

  2. Elija Tasks en el panel de navegación.

  3. Elija la tarea en ejecución que tiene la tabla que desea volver a validar.

  4. Elija la pestaña Table Statistics (Estadísticas de la tabla).

  5. Elija la tabla que desea revalidar (puede elegir hasta 10 tablas a la vez). Si la tarea ya no está en ejecución, no podrá volver a validar la tabla.

  6. Elija Revalidate (Volver a validar).

Uso del editor JSON para modificar las reglas de validación

Para añadir una regla de validación a una tarea mediante el editor JSON de la AWS DMS consola, haga lo siguiente:

  1. Seleccione las tareas de migración de bases de datos.

  2. Seleccione la tarea de la lista de tareas de migración.

  3. Si la tarea está en ejecución, seleccione Detener en el menú desplegable Acciones.

  4. Una vez detenida la tarea, para modificarla, seleccione Modificar en el menú desplegable Acciones.

  5. En la sección Asignaciones de tablas, seleccione el editor JSON y agregue la regla de validación a las asignaciones de tablas.

Por ejemplo, puede agregar la siguiente regla de validación al origen para ejecutar una función de sustitución. En este caso, si la regla de validación encuentra un byte nulo, lo valida como un espacio.

{ "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" }

Tareas exclusivas de validación

Puede crear tareas exclusivas de validación para obtener una vista previa y validar los datos sin realizar ninguna migración o replicación de datos. Para crear una tarea exclusiva de validación, establezca la configuración de EnableValidation y ValidationOnly en true. Cuando se habilita ValidationOnly, se aplican requisitos adicionales. Para obtener más información, consulte Configuración de tareas de validación de datos.

Para un tipo de migración exclusivo de carga completa, una tarea exclusiva de validación se completa mucho más rápido que su equivalente de CDC cuando se informa de muchos errores. Sin embargo, se informa de los cambios en el punto de conexión de origen o destino como errores en el modo de carga completa, lo que podría ser una desventaja.

Una tarea exclusiva de validación de CDC retrasa la validación en función de la latencia media y vuelve a intentar los errores varias veces antes de informar de ellos. Si la mayoría de las comparaciones de datos dan como resultado errores, una tarea exclusiva de validación para el modo de CDC es muy lenta, lo que podría suponer un inconveniente.

Una tarea solo de validación se debe configurar en la misma dirección que la tarea de replicación, especialmente para CDC. Esto se debe a que una tarea exclusiva de validación de CDC detecta qué filas han cambiado y deben revalidarse en función del registro de cambios del origen. Si el destino se especifica como origen, solo conoce los cambios enviados al destino por el DMS y no se garantiza que detecte errores de replicación.

Validación solo de carga completa

A partir de la AWS DMS versión 3.4.6 y versiones posteriores, una tarea que solo sea de validación a carga completa compara rápidamente todas las filas de las tablas de origen y destino en una sola pasada, informa inmediatamente de cualquier error y, a continuación, se cierra. La validación nunca se suspende debido a errores en este modo, sino que está optimizada para velocidad. Sin embargo, se informa de los cambios en el punto de conexión de origen o destino como errores.

nota

A partir de AWS DMS la versión 3.4.6 y versiones posteriores, este comportamiento de validación también se aplica a las tareas de migración a carga completa con la validación habilitada.

Validación solo de CDC

Una tarea exclusiva de validación de CDC valida todas las filas existentes entre las tablas de origen y destino desde cero. Además, una tarea exclusiva de validación de CDC se ejecuta de forma continua, vuelve a validar los cambios de replicación en curso, limita el número de errores notificados en cada pase y reintenta las filas que no coinciden antes de que produzcan un error. Está optimizada para evitar los falsos positivos.

La validación de una tabla (o de toda la tarea) se suspende si se superan los umbrales FailureMaxCount o TableFailureMaxCount. Esto también se aplica a una tarea de migración de CDC o Full carga completa+CDC con la validación habilitada. Además, una tarea de CDC con la validación habilitada retrasa la revalidación de cada fila modificada en función de la latencia media de origen y destino.

Sin embargo, una tarea exclusiva de validación de CDC no migra los datos y no tiene latencia. De forma predeterminada, ValidationQueryCdcDelaySeconds se establece en 180. Además, puede aumentar la cantidad para tener en cuenta los entornos de alta latencia y ayudar a evitar los falsos positivos.

Casos de uso solo de validación

Los casos de uso para dividir la parte de validación de datos de una tarea de migración o replicación en una tarea exclusiva de validación incluyen, entre otros, los siguientes:

  • Controlar exactamente cuándo se produce la validación: las consultas de validación agregan una carga adicional a los puntos de conexión de origen y destino. Por lo tanto, migrar o replicar primero los datos de una tarea y, después, validar los resultados en otra tarea puede resultar beneficioso.

  • Reducir la carga en la instancia de replicación: dividir la validación de datos para que se ejecute en su propia instancia puede resultar ventajoso.

  • Obtener rápidamente cuántas filas no coinciden en un momento dado en el tiempo: por ejemplo, justo antes o durante una transición de producción de periodo de mantenimiento a un punto de conexión de destino, puede crear una tarea exclusiva de validación de carga completa para obtener una respuesta a la pregunta.

  • Cuando se esperan errores de validación para una tarea de migración con un componente de CDC: por ejemplo, si se migra Oracle varchar2 a PostgreSQL jsonb, la validación de CDC sigue reintentando estas filas erróneas y limita el número de errores notificados cada vez. Sin embargo, puede crear una tarea exclusiva de validación de carga completa y obtener una respuesta más rápida.

  • Ha desarrollado un script o una utilidad de reparación de datos que lee la tabla de errores de validación (consulte también Solución de problemas). Una tarea exclusiva de validación de carga completa informa rápidamente de los errores para que el script de reparación de datos actúe en consecuencia.

Para ver un ejemplo de la configuración de tareas de ValidationSettings en un archivo JSON, consulte Ejemplo de configuración de tarea.

Solución de problemas

Durante la validación, AWS DMS crea una nueva tabla en el punto final de destino:awsdms_control.awsdms_validation_failures_v1. Si algún registro entra en el ValidationSuspendedo el ValidationFailedestado, AWS DMS escribe la información de diagnóstico enawsdms_control.awsdms_validation_failures_v1. Puede consultar esta tabla para ayudar a solucionar errores de validación.

Para obtener información sobre cómo cambiar el esquema predeterminado en el que se crea la tabla en el destino, consulte la configuración de las tareas de la tabla de control.

A continuación se muestra una descripción de la tabla awsdms_control.awsdms_validation_failures_v1:

Nombre de la columna Tipo de datos: Descripción

TASK_NAME

VARCHAR(128) NOT NULL

AWS DMS identificador de tareas.

TABLE_OWNER VARCHAR(128) NOT NULL

Esquema (propietario) de la tabla.

TABLE_NAME

VARCHAR(128) NOT NULL

Nombre de la tabla.

FAILURE_TIME DATETIME(3) NOT NULL

Hora cuando se produjo el error.

KEY_TYPE VARCHAR(128) NOT NULL

Reservado para uso futuro (el valor siempre es “Fila”)

KEY TEXT NOT NULL

Esta es la clave principal para el tipo de registro de fila.

FAILURE_TYPE VARCHAR(128) NOT NULL

Gravedad de error de validación. Puede ser RECORD_DIFF, MISSING_SOURCE o MISSING_TARGET.

DETAILS VARCHAR(8000) NOT NULL

Cadena con formato JSON de todos los valores de las columnas de origen o destino que no coinciden con la clave dada.

A continuación se incluye una consulta de ejemplo de un destino MySQL que le mostrará todos los errores para una tarea mediante la consulta de la tabla awsdms_control.awsdms_validation_failures_v1. Tenga en cuenta que el nombre del esquema y la sintaxis de la consulta variarán en las distintas versiones del motor de destino. El nombre de la tarea debe ser el ID del recurso externo de la tarea. El ID del recurso externo de la tarea es el último valor en el ARN de la tarea. Por ejemplo, para una tarea con un valor de ARN de arn:aws:dms:us-west- 2:5599:task: RYSI, el ID de recurso externo de la tarea sería RYSI. VFPFKH4 FJR3 FTYKK2 VFPFKH4 FJR3 FTYKK2

select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],]

Puede mirar el campo DETAILS para determinar qué columnas no coinciden. Dado que tiene la clave principal del registro con error, puede consultar los puntos de conexión de origen y destino para ver qué parte del registro no coincide.

Rendimiento de validación de Redshift

Amazon Redshift se diferencia de las bases de datos relacionales en varios aspectos, como el almacenamiento en columnas, el MPP, la compresión de datos y otros factores. Estas diferencias dan a Redshift un perfil de rendimiento diferente al de las bases de datos relacionales.

Durante la fase de replicación de carga completa, la validación utiliza consultas de intervalo, y el tamaño de los datos depende de la configuración PartitionSize. Estas consultas basadas en intervalos seleccionan todos los registros de la tabla de origen.

Para una replicación continua, las consultas cambian entre recuperaciones basadas en intervalos y de registros individuales. El tipo de consulta se determina de forma dinámica en función de varios factores, como los siguientes:

  • Volumen de consultas

  • Tipos de consultas DML en la tabla de origen

  • Latencia de la tarea

  • Número total de registros

  • Configuración de la validación, como PartitionSize

Es posible que observe una carga adicional en su clúster de Amazon Redshift debido a las consultas de validación. Como los factores anteriores varían según los casos de uso, debe revisar el rendimiento de las consultas de validación y ajustar el clúster y la tabla en consecuencia. Algunas opciones para mitigar los problemas de rendimiento son las siguientes:

  • Reduzca la configuración PartitionSize y ThreadCount para ayudar a reducir la carga de trabajo durante la validación de carga completa. Tenga en cuenta que esto ralentizará la validación de los datos.

  • Si bien Redshift no aplica las claves principales, AWS DMS se basa en ellas para identificar de forma exclusiva los registros del destino para la validación de los datos. Si es posible, configure la clave principal para que refleje la clave de clasificación, de modo que las consultas de validación de carga completa se ejecuten más rápido.

Validación de datos mejorada para AWS Database Migration Service

La validación de datos mejorada ya está disponible en la versión 3.5.4 del motor de replicación, tanto para tareas de migración a plena carga como a plena carga con los CDC. Actualmente, esta mejora admite las rutas de migración de Oracle a PostgreSQL, SQL Server a PostgreSQL, Oracle a Oracle y SQL Server a SQL Server.

Requisitos previos

  • Oracle: conceda el EXECUTE permiso a la cuenta de usuario que accede SYS.DBMS_CRYPTO al punto final de Oracle:

    GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user;
  • Instale la pgcrypto extensión en la base de datos PostgreSQL:

    nota

    Para Amazon RDS para PostgreSQLinstances, la pgcrypto extensión ya está habilitada.

    Para las instancias de PostgreSQL autogestionadas, debe instalar las bibliotecas de módulos y contrib crear la extensión:

    • Instale las bibliotecas de móduloscontrib. Por ejemplo, en una EC2 instancia de Amazon con Amazon Linux y PostgreSQL 15:

      sudo dnf install postgresql15-contrib
    • Cree la extensión: pgcrypto

      CREATE EXTENSION IF NOT EXISTS pgcrypto;
  • En el caso de las instancias de Amazon RDS for PostgreSQL, configure el modo SSL para el punto de conexión: AWS DMS

    • De forma predeterminada, Amazon RDS fuerza una conexión SSL. Al crear un AWS DMS punto de conexión para una instancia de Amazon RDS for PostgreSQL, utilice la opción «modo SSL» = «obligatorio».

    • Si desea utilizar la opción «modo SSL» = «ninguno», defina el rds.force_ssl parámetro en 0 en el grupo de parámetros de RDS.

  • Para PostgreSQL 12 y 13, cree el agregado: BIT_XOR

    CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit);

Limitaciones

Esta función de validación de datos mejorada tiene las siguientes limitaciones:

  • Requisitos de punto final de base de datos: esta mejora solo está disponible para puntos finales de base de datos que cumplen los siguientes criterios:

    • Se utiliza AWS Secrets Manager para almacenar las credenciales.

    • Para Microsoft SQL Server, también se admite la autenticación Kerberos.

  • Compatibilidad con versiones de bases de datos:

    • PostgreSQL 12 y versiones posteriores

    • Oracle 12.1 y versiones posteriores

    • Para las versiones de Microsoft SQL Server anteriores a 2019, no se admite la validación de los tipos de datos NCHAR y NVARCHAR.

Limitaciones

  • La validación de datos requiere que la tabla tenga una clave principal o índice único.

    • Las columnas de clave principal no pueden ser del tipo CLOB, BLOB o BYTE.

    • Para las columnas de clave principal de tipo VARCHAR o CHAR, la longitud debe ser inferior a 1024. Debe especificar la longitud del tipo de datos. No puede usar tipos de datos ilimitados como clave principal para la validación de datos.

    • Una clave de Oracle creada con la cláusula NOVALIDATE no se considera una clave principal ni un índice único.

    • Para una tabla de Oracle sin clave principal y solo con una clave única, las columnas con la restricción única también deben tener una restricción NOT NULL.

  • No se admite la validación de valores NULL PK/UK.

  • Si la intercalación de la columna de clave principal en la instancia de PostgreSQL de destino no se ha establecido en "C", el orden de clasificación de la clave principal será diferente en comparación con el de Oracle. La validación de datos producirá un error al validar los registros si el orden de clasificación es diferente entre PostgreSQL y Oracle.

  • La validación de datos genera consultas adicionales en las bases de datos de origen y de destino. Debe asegurarse de que ambas bases de datos tengan suficientes recursos para gestionar esta carga adicional. Esto es especialmente importante en el caso de los destinos de Redshift. Para obtener más información, consulte Rendimiento de validación de Redshift a continuación.

  • La validación de datos no se admite si se consolidan varias bases de datos en una.

  • Para un punto final de Oracle de origen o de destino, AWS DMS utiliza DBMS_CRYPTO para la validación. LOBs Si su terminal de Oracle lo utiliza LOBs, debe conceder el permiso de ejecución en dbms_crypto a la cuenta de usuario utilizada para acceder al punto de conexión de Oracle. Puede hacerlo ejecutando la siguiente instrucción:

    grant execute on sys.dbms_crypto to dms_endpoint_user;
  • Si la base de datos de destino se modifica fuera o AWS DMS durante la validación, es posible que las discrepancias no se notifiquen con precisión. Este resultado puede producirse si una de sus aplicaciones escribe datos en la tabla de destino mientras AWS DMS realiza la validación en esa misma tabla.

  • Si una o más filas se modifican continuamente durante la validación, no se AWS DMS pueden validar esas filas.

  • Si AWS DMS detecta más de 10 000 registros fallidos o suspendidos, detiene la validación. Antes de continuar, deberá resolver los problemas subyacentes con los datos.

  • AWS DMS no admite la validación de datos de las vistas.

  • AWS DMS no admite la validación de datos cuando se utilizan los ajustes de las tareas de sustitución de caracteres.

  • AWS DMS no admite la validación del tipo Oracle LONG.

  • AWS DMS no admite la validación del tipo Oracle Spatial durante una migración heterogénea.

  • La validación de datos ignora las columnas de las tablas para las que existen transformaciones de enmascaramiento de datos en el mapeo de tablas.

  • La validación de datos omite una tabla completa si existe una regla de transformación de enmascaramiento de datos para su columna PK/UK. El estado de validación se mostrará como Sin clave principal para dichas tablas.

Para conocer las limitaciones al utilizar la validación de destino de S3, consulte Limitaciones para utilizar la validación de destinos de S3.

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.