Uso de una base de datos de Microsoft SQL Server como origen para AWS DMS - AWS Database Migration Service
Restricciones de SQL ServerPermisos de SQL ServerRequisitos previos para utilizar los CDC actualesCapturar cambios para SQL Server autogestionado de forma local o en EC2Configurar la replicación continua en una instancia de base de datos de SQL Server en la nubeConfiguración opcional de RDS for SQL Server como origenMétodos de compresión compatiblesTrabajar con grupos de AlwaysOn disponibilidad de SQL Server autogestionadosConfiguración de endpointTipos de datos de origen para SQL Server

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.

Uso de una base de datos de Microsoft SQL Server como origen para AWS DMS

Migre los datos desde una o varias bases de datos de Microsoft SQL Server utilizando AWS DMS. Con una base de datos de SQL Server como origen, podrá migrar datos a otra base de datos de SQL Server, o bien a una de las demás bases de datos compatibles con AWS DMS. A continuación se enumeran las ediciones de SQL Server que puede utilizar como fuente con bases de datos locales.

Versión de SQL Server Full load Replicación continua (CDC)

2005, 2008, 2008R2, 2012, 2014, 2016, 2017, 2019

Enterprise

Standard

Grupo de trabajo

Developer

Web

Enterprise Edition

Developer

Edición estándar (versión 2016 SP1 y posteriores)

Cuando se utiliza SQL Server 2005 como fuente, solo se admite la carga completa.

A continuación se enumeran las ediciones de SQL Server que puede utilizar como fuente con las bases de datos de Amazon RDS.

Versión de SQL Server Full load Replicación continua (CDC)

2012, 2014, 2016, 2017 y 2019

Enterprise

Standard

Enterprise Edition

Edición estándar (versión 2016 SP1 y posteriores)
nota

Se ofrece Support para la versión 2019 de Microsoft SQL Server como fuente.

La base de datos de origen de SQL Server se puede instalar en cualquier equipo de la red. También se necesita una cuenta de SQL Server con los privilegios de acceso adecuados a la base de datos de origen para el tipo de tarea elegido, con el fin de utilizarla con AWS DMS. Esta cuenta debe tener losview server state permisosview definition y. Para añadir este permiso, utilice el siguiente comando:

grant view definition to [user]
grant view server state to [user]

AWS DMS admite la migración de datos de instancias nombradas de SQL Server. Puede utilizar las siguientes notaciones en el nombre del servidor al crear el punto de enlace de origen.

IPAddress\InstanceName

Por ejemplo, el siguiente es un nombre de servidor de punto de enlace de origen correcto. Aquí, la primera parte del nombre es la dirección IP del servidor y la segunda parte es el nombre de la instancia de SQL Server (en este ejemplo, SQLTest).

10.0.0.25\SQLTest

Además, obtenga el número de puerto en el que escucha la instancia con nombre de SQL Server y úselo para configurar el punto de enlace de origen de AWS DMS.

nota

El puerto 1433 es el predeterminado para Microsoft SQL Server. Sin embargo, también se suelen utilizar los puertos dinámicos que cambian cada vez que se inicia SQL Server y los números de puerto estáticos específicos que se utilizan para conectarse a SQL Server a través de un firewall. Por lo tanto, querrá saber el número de puerto real de su instancia designada de SQL Server cuando cree el extremo deAWS DMS origen.

Puede utilizar SSL para cifrar las conexiones entre el punto de enlace de SQL Server y la instancia de replicación. Para obtener más información sobre cómo utilizar SSL con un punto de enlace de SQL Server, consulte Uso de SSL con AWS Database Migration Service.

Para obtener más información sobre cómo trabajar con las bases de datos de origen de SQL Server y AWS DMS, consulte lo siguiente.

Restricciones en el uso de SQL Server como origen para AWS DMS

Las siguientes restricciones se aplican cuando se utiliza una base de datos de SQL Server como origen para AWS DMS:

  • La propiedad de identidad para una columna no se migra a una columna de la base de datos de destino.

  • El enlace de SQL Server no es compatible con el uso de tablas dispersas.

  • No se admite la autenticación de Windows.

  • Los cambios en los campos calculados en SQL Server no se replican.

  • No se permite usar tablas temporales.

  • No se admite el cambio de particiones de SQL Server.

  • Cuando se utilizan las utilidades WRITETEXT y UPDATETEXT, AWS DMS no captura los eventos aplicados en la base de datos de origen.

  • No se admite el siguiente patrón de lenguaje de manipulación de datos (DML). 

    SELECT * INTO new_table FROM existing_table

  • Cuando se utiliza SQL Server como origen, no se admite el cifrado de nivel de columna.

  • Se admite el cifrado de datos transparente (TDE) habilitado en el nivel de base de datos.

  • AWS DMSno admite auditorías a nivel de servidor en SQL Server 2008 o SQL Server 2008 R2 como fuentes. Esto se debe a un problema conocido con SQL Server 2008 y 2008 R2. Por ejemplo, si ejecuta el siguiente comando, AWS DMS generará un error.

    USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO

  • Las columnas de geometría no se admiten en el modo de registro completo cuando se utiliza SQL Server como fuente. En su lugar, utilice el modo lob limitado o defina la configuración de laInlineLobMaxSize tarea para que utilice el modo lob en línea.

  • Cuando se utiliza una base de datos fuente de Microsoft SQL Server en una tarea de replicación, las definiciones de SQL Server Replication Publisher no se eliminan si se quita la tarea. Estas definiciones de Microsoft SQL Server las debe eliminar un administrador del sistema de Microsoft SQL Server.

  • Se admite la migración de datos desde non-schema-bound vistas y enlazados al esquema solo para tareas de carga completa.

  • No se admite el cambio de nombre de las tablas mediante sp_rename (por ejemplo, sp_rename 'Sales.SalesRegion', 'SalesReg;)

  • No se admite el cambio de nombre de las columnas mediante sp_rename (por ejemplo, sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)

  • AWS DMSno admite el procesamiento de cambios para establecer y anular los valores predeterminados de las columnas (mediante laALTER COLUMN SET DEFAULT cláusula conALTER TABLE sentencias).

  • AWS DMSno admite el procesamiento de cambios para establecer la nulabilidad de las columnas (utilizando laALTER COLUMN [SET|DROP] NOT NULL cláusula conALTER TABLE las sentencias).

  • Con SQL Server 2012 y SQL Server 2014, cuando se utiliza la replicación de DMS con grupos de disponibilidad, la base de datos de distribución no se puede colocar en un grupo de disponibilidad. SQL 2016 permite colocar la base de datos de distribución en un grupo de disponibilidad, excepto las bases de datos de distribución que se utilizan en las topologías de combinación, bidireccionales o de peer-to-peer replicación.

  • Para las tablas particionadas,AWS DMS no admite diferentes configuraciones de compresión de datos para cada partición.

  • Al insertar un valor en los tipos de datos espaciales de SQL Server (GEOGRAFÍA y GEOMETRÍA), puede ignorar la propiedad del identificador del sistema de referencia espacial (SRID) o especificar un número diferente. Al replicar tablas con tipos de datos espaciales, AWS DMS reemplaza el SRID por el SRID predeterminado (0 para GEOMETRY y 4326 para GEOGRAPHY).

  • Si la base de datos no está configurada para MS-REPLICATION o MS-CDC, puede todavía capturar tablas que no tienen una clave principal, pero solo se capturan los eventos INSERT/DELETE DML. Los eventos UPDATE y TRUNCATE TABLE se omiten.

  • No se admiten los índices de Columnstore.

  • Las tablas con optimización de la memoria (usando OLTP en memoria) no son compatibles.

  • Al replicar una tabla con una clave principal que consta de varias columnas, no se admite la actualización de las columnas de clave principal durante la carga completa.

  • No se admite la durabilidad retardada.

  • La configuración dereadBackupOnly=Y punto final (atributo de conexión adicional) no funciona en las instancias de origen de RDS para SQL Server debido a la forma en que RDS realiza las copias de seguridad.

  • EXCLUSIVE_AUTOMATIC_TRUNCATIONno funciona en las instancias fuente de SQL Server de Amazon RDS porque los usuarios de RDS no tienen acceso para ejecutar el procedimiento almacenado de SQL Server,sp_repldone.

  • AWS DMSno captura los comandos truncados.

  • AWS DMSno admite la replicación desde bases de datos con la recuperación acelerada de bases de datos (ADR) activada.

  • AWS DMSno admite la captura de instrucciones de lenguaje de definición de datos (DDL) y de lenguaje de manipulación de datos (DML) en una sola transacción.

  • AWS DMSno admite la replicación de paquetes de aplicaciones de nivel de datos (DACPAC).

  • Las sentencias UPDATE que incluyen claves principales o índices únicos y actualizan varias filas de datos pueden provocar conflictos al aplicar cambios a la base de datos de destino. Esto puede ocurrir, por ejemplo, cuando la base de datos de destino aplica las actualizaciones como sentencias INSERT y DELETE en lugar de una sola sentencia UPDATE. Con el modo de aplicación optimizado por lotes, es posible que se omita la tabla. Con el modo de aplicación transaccional, la operación UPDATE puede provocar infracciones de las restricciones. Para evitar este problema, vuelva a cargar la tabla correspondiente. Como alternativa, busque los registros problemáticos en la tabla de control Apply Exceptions (dmslogs.awsdms_apply_exceptions) y edítelos manualmente en la base de datos de destino. Para obtener más información, consulte Configuración de ajuste del procesamiento de cambios.

  • AWS DMSno admite la replicación de tablas y esquemas, donde el nombre incluye un carácter especial del siguiente conjunto.

    \\ -- \n \" \b \r ' \t ;

  • No se admite el enmascaramiento de datos. AWS DMSmigra datos enmascarados sin enmascararlos.

  • AWS DMSreplica hasta 32.767 tablas con claves principales y hasta 1000 columnas para cada tabla. Esto se debe a queAWS DMS crea un artículo de replicación de SQL Server para cada tabla replicada, y los artículos de replicación de SQL Server tienen estas limitaciones.

  • Al utilizar Change Data Capture (CDC), debe definir todas las columnas que componen un índice único comoNOT NULL. Si no se cumple este requisito, se producirá el error 22838 del sistema SQL Server.

Se aplican las siguientes limitaciones al acceder a los registros de transacciones de copia de seguridad:

  • Las copias de seguridad cifradas no son compatibles.

  • Las copias de seguridad almacenadas en una dirección URL o en Windows Azure no son compatibles.

Se aplican las siguientes limitaciones al acceder a los registros de transacciones de copia de seguridad en el nivel de archivo:

  • Los registros de transacciones de copia de seguridad deben residir en una carpeta compartida con los permisos y derechos de acceso adecuados.

  • Se accede a los registros de transacciones activos a través de la API de Microsoft SQL Server (y no en el nivel de archivo).

  • Las plataformas UNIX no son compatibles.

  • No se admite la lectura de los registros de copia de seguridad de varias franjas.

  • No se admite la copia de seguridad de Microsoft SQL Server en varios discos (por ejemploMIRROR TO DISK).

Permisos para tareas únicamente a carga completa

Los siguientes permisos son necesarios para realizar tareas únicamente a carga completa.

USE db_name;
                
                CREATE USER dms_user FOR LOGIN dms_user; 
                ALTER ROLE [db_datareader] ADD MEMBER dms_user; 
                GRANT VIEW DATABASE STATE to dms_user ; 
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

Requisitos previos para utilizar la replicación continua (CDC) desde una fuente de SQL Server

Puede utilizar la replicación continua (captura de datos de cambios o CDC) para una base de datos de SQL Server autogestionada local o en Amazon EC2, o una base de datos en la nube, como Amazon RDS o una instancia gestionada de Microsoft Azure SQL.

Los requisitos siguientes se aplican específicamente cuando se utiliza la replicación continua con una base de datos de SQL Server como origen para AWS DMS:

  • Es preciso configurar SQL Server para backups completas y debe realizar una backup antes de empezar a replicar los datos.

  • El modelo de recuperación debe establecerse en Bulk logged o Full.

  • No se admite el backup de SQL Server en varios discos. Si la copia de seguridad está definida para escribir la copia de seguridad de la base de datos en varios archivos y en diferentes discos, AWS DMS no podrá leer los datos y la tarea de AWS DMS generará un error.

  • En el caso de las fuentes de SQL Server autogestionadas, las definiciones de SQL Server Replication Publisher para la fuente utilizada en una tarea de DMS CDC no se eliminan al eliminar la tarea. Estas definiciones de SQL Server para orígenes autoadministrados las debe eliminar un administrador del sistema de SQL Server.

  • Durante la CDC,AWS DMS necesita buscar copias de seguridad del registro de transacciones de SQL Server para leer los cambios. AWS DMSno admite copias de seguridad del registro de transacciones de SQL Server creadas con software de respaldo de terceros que no estén en formato nativo. Para admitir las copias de seguridad del registro de transacciones en formato nativo y creadas con un software de respaldo de terceros, añada el atributo deuse3rdPartyBackupDevice=Y conexión al extremo de origen.

  • Para orígenes autoadministrados de SQL Server, tenga en cuenta que SQL Server no captura los cambios en las tablas creadas recientemente hasta que se han publicado. Cuando las tablas se añaden a un origen de SQL Server, AWS DMS administra la creación de la publicación. Sin embargo, este proceso puede prolongarse algunos minutos. Las operaciones efectuadas en tablas de nueva creación durante este intervalo no se capturan ni replican en el destino.

  • AWS DMSla captura de datos de cambios requiere que el registro completo de transacciones esté activado en SQL Server. Para activar el registro completo de transacciones en SQL Server, habilite MS-REPLICATION o CHANGE DATA CAPTURE (CDC).

  • Las entradas del registro de SQL Server no se marcarán para su reutilización hasta que el trabajo de captura de MS CDC procese esos cambios.

  • Las operaciones de CDC no se admiten en las tablas con optimización para memoria. Esta restricción se aplica a SQL Server 2014 (cuando se introdujo por vez primera la característica) y a versiones posteriores.

Capturar cambios de datos para SQL Server autogestionado de forma local o en Amazon EC2

Para capturar los cambios de una base de datos de Microsoft SQL Server de origen, asegúrese de que la base de datos esté configurada para realizar copias de seguridad completas. Configure la base de datos en modo de recuperación completa o en modo de registro masivo.

Para un origen autoadministrado de SQL Server, AWS DMS utiliza lo siguiente:

Replicación de MS

Para capturar los cambios de las tablas con claves principales. Puede configurarlo automáticamente concediendo privilegios de administrador del sistema al usuario delAWS DMS punto final en la instancia de SQL Server de origen. O bien, puede seguir los pasos de esta sección para preparar la fuente y utilizar un usuario que no tenga privilegios de administrador del sistema para elAWS DMS endpoint.

MS-CDC

Para capturar los cambios de las tablas sin claves principales. Habilite el MS-CDC a nivel de base de datos y para todas las tablas de forma individual.

Al configurar una base de datos de SQL Server para la replicación continua (CDC), puede realizar una de las siguientes acciones:

  • Configurar la replicación continua con el rol sysadmin.

  • Configurar la replicación continua para que no se utilice el rol sysadmin.

Configuración de la replicación continua mediante el rol de administrador del sistema con SQL Server autogestionado

AWS DMSla replicación continua para SQL Server utiliza la replicación nativa de SQL Server para las tablas con claves principales y la captura de datos de cambios (CDC) para las tablas sin claves principales.

Antes de configurar la replicación continua, consulteRequisitos previos para utilizar la replicación continua (CDC) desde una fuente de SQL Server.

En el caso de las tablas con claves principales, generalmente seAWS DMS pueden configurar los artefactos necesarios en la fuente. Sin embargo, en el caso de las instancias fuente de SQL Server que se autoadministran, asegúrese de configurar primero la distribución de SQL Server manualmente. Después de hacerlo, los usuarios deAWS DMS origen con permiso de administrador del sistema pueden crear automáticamente la publicación para las tablas con claves principales.

Para comprobar si la distribución ya se ha configurado, ejecute el siguiente comando.

sp_get_distributor

Si el resultado esNULL para la distribución de columnas, la distribución no está configurada. Puede utilizar el siguiente procedimiento para configurar la distribución.

Para configurar la distribución

  1. Connect a la base de datos de origen SQL Server mediante la herramienta SQL Server Management Studio (SSMS).

  2. Abra el menú contextual (haga clic con el botón derecho) de la carpeta de replicación (haga clic con el botón derecho) de la carpeta de replicación y elija Stop ( Aparecerá el asistente de configuración de la distribución.

  3. Siga las instrucciones del asistente para introducir los valores predeterminados y crear la distribución.

Para configurar CDC

AWS DMSla versión 3.4.7 y las posteriores pueden configurar MS CDC para su base de datos y todas sus tablas automáticamente si no utiliza una réplica de solo lectura. Para utilizar esta función, defina laSetUpMsCdcForTables ECA en true. Para obtener información sobre las ECA, consulteConfiguración de endpoint.

Para versionesAWS DMS anteriores a la 3.4.7 o para una réplica de solo lectura como fuente, lleve a cabo los siguientes pasos:

  1. Para tablas sin claves principales, configure MS-CDC para la base de datos. Para ello, utilice una cuenta que tenga asignada la función de administrador de sistemas y ejecute el siguiente comando.

    use [DBname]
EXEC sys.sp_cdc_enable_db

  2. A continuación, configure MS-CDC para cada una de las tablas de origen. Para cada tabla con claves únicas pero sin clave principal, ejecute la siguiente consulta para configurar el MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

  3. Para cada tabla sin clave principal o sin claves únicas, ejecute la siguiente consulta para configurar MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

Para obtener más información sobre cómo configurar MS-CDC para tablas específicas, consulte la documentación de SQL Server.

Configuración de la replicación continua sin la función de administrador del sistema en SQL Server autogestionado

Puede configurar la replicación continua para un origen de base de datos de SQL Server que no requiera que la cuenta de usuario tenga privilegios de sysadmin. Aún necesita un usuario con privilegios de administrador del sistema para configurar la base de datos de SQL Server para una replicación continua.

nota

Puede realizar este procedimiento, mientras que la tarea DMS se está ejecutando. Si la tarea DMS se detiene, puede llevar a cabo este procedimiento únicamente si no hay ningún registro de transacciones o copias de seguridad de bases de datos en curso. Esto se debe a que SQL Server requiere el privilegio SYSADMIN para consultar en las copias de seguridad la posición del número de secuencia de registro (LSN).

Antes de configurar la replicación continua, consulteRequisitos previos para utilizar la replicación continua (CDC) desde una fuente de SQL Server.

Para tablas con claves principales, siga el procedimiento que se indica a continuación.

Para configurar un origen de base de datos de SQL Server para la replicación continua sin utilizar el rol sysadmin

  1. Cree una cuenta de SQL Server con autenticación mediante contraseña utilizando SQL Server Management Studio (SSMS). En este ejemplo, se utiliza una cuenta denominada dmstest.

  2. En la sección Mapeos de usuarios de SSMS, elija las bases de datos MSDB y MASTER (que otorgan permisos públicos) y asigne la función DB_OWNER a la base de datos que desee utilizar para la replicación continua.

    USE [master]
CREATE LOGIN [dmstest] WITH PASSWORD=N'xxxxxxx';
CREATE USER [dmstest] FOR LOGIN [dmstest];

USE [msdb];
CREATE USER [dmstest] FOR LOGIN [dmstest];

USE [DB name used by DMS];
CREATE USER [dmstest] FOR LOGIN [dmstest];
ALTER ROLE [db_owner] ADD MEMBER [dmstest];

  3. Abra el menú contextual (haga clic con el botón derecho) en la cuenta nueva, elija Security (Seguridad) y conceda de forma específica el privilegio Connect SQL.

  4. Ejecute los siguientes comandos Grant. 

    GRANT SELECT ON FN_DBLOG TO dmstest;
GRANT VIEW SERVER STATE TO dmstest;
use msdb;
GRANT EXECUTE ON MSDB.DBO.SP_STOP_JOB TO dmstest;
GRANT EXECUTE ON MSDB.DBO.SP_START_JOB TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPSET TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPFILE TO dmstest;

  5. En SSMS, abra el menú contextual (haga clic con el botón derecho) para la carpeta Replication y, a continuación, elija Configurar distribución. Siga todos los pasos predeterminados y configure esta instancia de SQL Server para su distribución. Se crea una base de datos de distribución en la categoría de bases de datos.

  6. Cree una publicación para la replicación continua de SQL Server de la siguiente manera:

    1. Inicie sesión en SSMS utilizando la cuenta de usuario SYSADMIN.

    2. Amplíe Replication (Replicación).

    3. Abra el menú contextual (con el botón derecho del ratón) de Local Publications (Publicaciones locales).

    4. En el asistente para nuevas publicaciones, seleccione Siguiente.

    5. Elija la base de datos en la que desea crear la publicación.

    6. Elija Transactional publication (Publicación transaccional) y, a continuación, elija Next (Siguiente).

    7. Expanda Tablas y elija las tablas con PK y las tablas que desee publicar. Elija Next (Siguiente).

    8. Elija Siguiente, ya que no es necesario crear un filtro.

    9. En la pantalla Agente de instantáneas, elija la primera opción para Crear una instantánea inmediatamente y mantener la instantánea disponible para inicializar suscripciones. Elija Next (Siguiente).

    10. Seleccione Configuración de seguridad y, a continuación, seleccione Ejecutar en la cuenta de servicio SQL Server Agent. Asegúrese de elegir Suplantando la cuenta del proceso para establecer una conexión con el editor. Seleccione OK (Aceptar).

    11. Elija Next (Siguiente).

    12. Seleccione Create the publication (Crear la publicación).

    13. Proporcione un nombre para la publicación en formato AR_PUBLICATION_000DBID.

      Por ejemplo, siDBID tiene menos de 10, asigne a la publicación el nombreAR_PUBLICATION_0000DBID > (4 ceros). Si suDBID valor es mayor o igual a 10, asigne un nombre a la publicación AR_PUBLICATION_000DBID (3 ceros). También puede utilizar laDB_ID función en SQL Server. Para obtener más información sobre laDB_ID función, consulte la documentación de SQL Server.

  7. Cree una nuevaAWS DMS tarea con SQL Server como punto final de origen mediante la cuenta de usuario que creó.

Para tablas sin claves principales, configure MS-CDC para la base de datos. Para ello, utilice una cuenta que tenga asignada la función de administrador de sistemas y ejecute el siguiente comando.

use [DBname]
EXEC sys.sp_cdc_enable_db

A continuación, configure MS-CDC para cada una de las tablas de origen. Para cada tabla con claves únicas pero sin clave principal, ejecute la siguiente consulta para configurar el MS-CDC.

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

Para cada tabla sin clave principal o sin claves únicas, ejecute la siguiente consulta para configurar MS-CDC.

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

Para obtener más información sobre cómo configurar MS-CDC para tablas específicas, consulte la documentación de SQL Server.

Configurar la replicación continua en una instancia de base de datos de SQL Server en la nube

En esta sección se describe cómo configurar CDC en una instancia de base de datos de SQL Server alojada en la nube. Una instancia de SQL server alojada en la nube es una instancia que se ejecuta en Amazon RDS for SQL Server, una instancia gestionada de Azure SQL o una instancia de Azure SQL.

Antes de configurar la replicación continua, consulteRequisitos previos para utilizar la replicación continua (CDC) desde una fuente de SQL Server.

A diferencia de las fuentes de Microsoft SQL Server autogestionadas, Amazon RDS for SQL Server no admite la replicación de MS. Por lo tanto, AWS DMS necesita utilizar MS-CDC para las tablas con claves principales o sin ellas.

Amazon RDS no otorga privilegios de administrador de sistemas para configurar los artefactos de replicación que seAWS DMS utilizan para los cambios continuos en una instancia de SQL Server de origen. Asegúrese de activar el MS-CDC para la instancia de Amazon RDS (mediante los privilegios de usuario maestro) siguiendo el siguiente procedimiento.

Para activar el MS-CDC para una instancia de base de datos de SQL Server en la nube

  1. Ejecute una de las siguientes consultas en el nivel de base de datos.

    Para instancias de RDS for MySQL, utilice esta consulta.

    exec msdb.dbo.rds_cdc_enable_db 'DB_name'

    Para una instancia de base de datos gestionada por Azure SQL, utilice esta consulta.

    USE DB_name 
GO 
EXEC sys.sp_cdc_enable_db 
GO

  2. Para cada tabla con una clave principal, ejecute la siguiente consulta para activar el MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    Para cada tabla con claves únicas pero sin clave principal, ejecute la siguiente consulta para activar el MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    Para cada tabla sin clave principal ni claves únicas, ejecute la siguiente consulta para activar el MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

  3. Especifique el periodo de retención para que los cambios estén disponibles en el origen utilizando los comandos siguientes.

    use dbname
EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 86399
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

    El parámetro@pollinginterval se mide en segundos con un valor recomendado establecido en 86399. Esto significa que el registro de transacciones conserva los cambios durante 86.399 segundos (un día) cuando@pollinginterval = 86399. El procedimiento exec sp_cdc_start_job 'capture' inicia la configuración.

    nota

    En algunas versiones de SQL Server, si el valor depollinginterval se establece en más de 3599 segundos, el valor se restablece a los cinco segundos predeterminados. Cuando esto sucede, las entradas de T-Log se purgan antes deAWS DMS poder leerlas. Para determinar qué versiones de SQL Server se ven afectadas por este problema conocido, consulte este artículo de Microsoft KB.

    Si utiliza Amazon RDS con Multi-AZ, asegúrese de configurar también el secundario para que tenga los valores correctos en caso de conmutación por error.

    exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , 86399

Si una tarea deAWS DMS replicación que captura los cambios en curso en la fuente de SQL Server se detiene durante más de una hora, utilice el siguiente procedimiento.

Para mantener el período de retención durante una tarea deAWS DMS replicación

  1. Utilice el siguiente comando para truncar los registros de transacciones con el siguiente comando. 

    exec sp_cdc_stop_job 'capture'

  2. Busque la tarea en laAWS DMS consola y reanude la tarea.

  3. Seleccione la pestaña Supervisión y compruebe laCDCLatencySource métrica.

  4. Cuando laCDCLatencySource métrica sea igual a 0 (cero) y permanezca ahí, reinicie el trabajo truncando los registros de transacciones con el siguiente comando.

    exec sp_cdc_start_job 'capture'

Recuerde iniciar el trabajo que trunca los registros de transacciones de SQL Server. De lo contrario, el almacenamiento de la instancia de SQL Server podría agotarse.

Limitaciones para la replicación continua en una instancia de base de datos de SQL Server en la nube

  • AWS DMSadmite la replicación continua (CDC) únicamente con el registro de transacciones activo. No puede usar el registro de respaldo con los CDC.

  • Puede perder eventos si los mueve del registro de transacciones activo al registro de respaldo o los trunca del registro de transacciones activo.

Configuración recomendada al utilizar Amazon RDS for SQL Server como fuente paraAWS DMS

Cuando trabaja con Amazon RDS for SQL Server como fuente, el trabajo de captura se basa en los parámetrosmaxscans ymaxtrans. Estos parámetros regulan el número máximo de escaneos que la captura realiza en el registro de transacciones y el número de transacciones que se procesan para cada escaneo.

En el caso de las bases de datos, en las que el número de transacciones es mayor quemaxtrans*maxscans, aumentar elpolling_interval valor puede provocar una acumulación de registros de transacciones activos. A su vez, esta acumulación puede provocar un aumento en el tamaño del registro de transacciones.

Tenga en cuenta queAWS DMS no depende del trabajo de captura del MS-CDC. El trabajo de captura del MS-CDC marca las entradas del registro de transacciones como procesadas. Esto permite que la tarea de respaldo del registro de transacciones elimine las entradas del registro de transacciones.

Le recomendamos que supervise el tamaño del registro de transacciones y el éxito de los trabajos de MS-CDC. Si los trabajos del MS-CDC fallan, el registro de transacciones podría crecer excesivamente y provocar errores deAWS DMS replicación. Puede supervisar los errores del trabajo de captura del MS-CDC mediante la vista de administraciónsys.dm_cdc_errors dinámica de la base de datos de origen. Puede supervisar el tamaño del registro de transacciones mediante el comandoDBCC SQLPERF(LOGSPACE) de administración.

Para abordar el aumento del registro de transacciones provocado por el MS-CDC

  1. Compruebe desdeLog Space Used % dóndeAWS DMS se está replicando la base de datos y valide que aumenta continuamente.

    DBCC SQLPERF(LOGSPACE)

  2. Identifique qué está bloqueando el proceso de copia de seguridad del registro de transacciones.

    Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();

    Si ellog_reuse_wait_desc valor es igualREPLICATION, la retención de la copia de seguridad del registro se debe a la latencia en MS-CDC.

  3. Aumente el número de eventos procesados por el trabajo de captura aumentando los valores de losmaxscans parámetrosmaxtrans y.

    EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

Para solucionar este problema, defina los valores demaxscans y demaxtrans forma quemaxtrans*maxscans sean iguales al número promedio de eventos generados para las tablas queAWS DMS se replican desde la base de datos de origen para cada día.

Si establece estos parámetros por encima del valor recomendado, los trabajos de captura procesarán todos los eventos de los registros de transacciones. Si establece estos parámetros por debajo del valor recomendado, la latencia del MS-CDC aumenta y el registro de transacciones crece.

Identificar los valores adecuados paramaxscans ymaxtrans puede resultar difícil porque los cambios en la carga de trabajo producen un número variable de eventos. En ese caso, le recomendamos que configure la supervisión de la latencia de MS-CDC. Para obtener más información, consulte Supervisar el proceso en la documentación de SQL Server. A continuación,maxtrans configúrelo y demaxscans forma dinámica en función de los resultados de la monitorización.

Si laAWS DMS tarea no encuentra los números de secuencia de registro (LSN) necesarios para reanudarla o continuar con ella, es posible que la tarea falle y que sea necesario volver a cargarla por completo.

Métodos de compresión compatibles con SQL Server

La siguiente tabla muestra los métodos de compresión que AWS DMS admite para cada versión de SQL Server.

Versión de SQL Server

Compresión de filas y páginas (en la partición)

Formato de almacenamiento vardecimal

2005

No

No

2008

Sí

No

2012

Sí

No

2014

Sí

No
nota

No se admiten las columnas dispersas ni la compresión de la estructura de las columnas.

Trabajar con grupos de AlwaysOn disponibilidad de SQL Server autogestionados

Los grupos de disponibilidad Always On de SQL Server ofrecen alta disponibilidad y recuperación ante desastres como una alternativa de nivel empresarial a la duplicación de bases de datos.

EnAWS DMS, puede migrar los cambios desde una única réplica del grupo de disponibilidad principal o secundario.

Trabajando con la réplica del grupo de disponibilidad principal

Para utilizar el grupo de disponibilidad principal como fuente enAWS DMS, haga lo siguiente:

  1. Active la opción de distribución para todas las instancias de SQL Server en sus réplicas de disponibilidad. Para obtener más información, consulte Configuración de la replicación continua mediante el rol de administrador del sistema con SQL Server autogestionado.

  2. En la consola de AWS DMS, abra la configuración de bases de datos de origen de SQL Server. En Nombre de servidor, especifique el nombre o la dirección IP del servicio de nombres de dominio (DNS) que se configuró para su agente de escucha de grupos de disponibilidad.

Al iniciar una AWS DMS tarea por primera vez, es posible que tarde más de lo habitual en iniciarse. Esta lentitud se debe a que el servidor del grupo de disponibilidad duplica la creación de los artículos de la tabla.

Trabajar con una réplica de un grupo de disponibilidad secundario

Para usar un grupo de disponibilidad secundario como fuente enAWS DMS, haga lo siguiente:

  1. Utilice las mismas credenciales para conectarse a réplicas individuales que las utilizadas por el usuario del punto de conexión deAWS DMS origen.

  2. Asegúrese de que la instancia deAWS DMS replicación pueda resolver los nombres DNS de todas las réplicas existentes y conectarse a ellas. Puede utilizar la siguiente consulta SQL para obtener los nombres DNS de todas sus réplicas.

    select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar
JOIN sys.availability_databases_cluster adc
ON adc.group_id = ar.group_id AND adc.database_name = '<source_database_name>';

  3. Al crear el extremo de origen, especifique el nombre DNS del detector del grupo de disponibilidad para el nombre del servidor del punto final o para la dirección del servidor del secreto del punto de enlace. Para obtener más información sobre los detectores de grupos de disponibilidad, consulte ¿Qué es un detector de grupos de disponibilidad? en la documentación de SQL Server.

    Puede utilizar un servidor DNS público o un servidor DNS local para resolver el detector del grupo de disponibilidad, la réplica principal y las réplicas secundarias. Para usar un servidor DNS local, configure el Amazon Route 53 Resolver. Para obtener más información, consulte Uso de su propio servidor de nombres en las instalaciones.

  4. Añada los siguientes atributos de conexión adicionales al extremo de origen.

    Atributo de conexión adicional Valor Notas
    applicationIntent ReadOnly Sin esta configuración de ODBC, la tarea de replicación se enruta a la réplica del grupo de disponibilidad principal. Para obtener más información, consulte SQL Server Native Client para alta disponibilidad y recuperación ante desastres en la documentación de SQL Server.
    multiSubnetFailover yes Para obtener más información, consulte SQL Server Native Client para alta disponibilidad y recuperación ante desastres en la documentación de SQL Server.
    alwaysOnSharedSynchedBackupIsEnabled false Para obtener más información, consulte Configuración de endpoint cuando se utiliza SQL Server como fuente paraAWS DMS.
    activateSafeguard false Para obtener más información, consulte Limitaciones a continuación.
    setUpMsCdcForTables false Para obtener más información, consulte Limitaciones a continuación.

  5. Habilite la opción de distribución en todas las réplicas de su grupo de disponibilidad. Añada todos los nodos a la lista de distribuidores. Para obtener más información, consulte Para configurar la distribución.

  6. Ejecute la siguiente consulta en la réplica de lectura y escritura principal para permitir la publicación de la base de datos. Ejecuta esta consulta solo una vez para la base de datos. 

    sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';

Limitaciones

A continuación, se indican las limitaciones para trabajar con una réplica de grupos de disponibilidad secundarios:

  • AWS DMSno admite Safeguard cuando se utiliza una réplica de un grupo de disponibilidad de solo lectura como fuente. Para obtener más información, consulte Configuración de endpoint cuando se utiliza SQL Server como fuente paraAWS DMS.

  • AWS DMSno admite el atributo de conexiónsetUpMsCdcForTables adicional cuando se utiliza una réplica de un grupo de disponibilidad de solo lectura como fuente. Para obtener más información, consulte Configuración de endpoint cuando se utiliza SQL Server como fuente paraAWS DMS.

  • AWS DMSpuede utilizar una réplica de un grupo de disponibilidad secundario autogestionado como base de datos de origen para la replicación continua (captura de datos de cambios o CDC) a partir de la versión 3.4.7. No se admiten réplicas de lectura Multi-AZ de Cloud SQL Server. Si utiliza versiones anteriores deAWS DMS, asegúrese de utilizar la réplica del grupo de disponibilidad principal como base de datos de origen para los CDC.

Conmutación por error a otros nodos

Si configuras el atributo de conexiónApplicationIntent adicional para tu terminal enReadOnly, laAWS DMS tarea se conectará al nodo de solo lectura con la prioridad de enrutamiento de solo lectura más alta. A continuación, realiza una conmutación por error a otros nodos de solo lectura de su grupo de disponibilidad cuando el nodo de solo lectura de mayor prioridad no está disponible. Si no la configurasApplicationIntent, laAWS DMS tarea solo se conectará al nodo principal (lectura/escritura) de tu grupo de disponibilidad.

Configuración de endpoint cuando se utiliza SQL Server como fuente paraAWS DMS

Puede utilizar la configuración de punto final para configurar la base de datos de origen de SQL Server de forma similar a usar atributos de conexión adicionales. La configuración se especifica al crear el extremo de origen mediante laAWS DMS consola o mediante elcreate-endpoint comando de AWS CLI, con la sintaxis--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON.

La siguiente tabla muestra la configuración de punto final que puede usar con SQL Server como fuente.

Nombre Descripción
AlwaysOnSharedSynchedBackupIsEnabled

Este atributo ajusta el comportamiento deAWS DMS al migrar desde una base de datos de origen SQL Server alojada como parte de un clúster de grupos de disponibilidad Always On.

AWS DMSha mejorado la compatibilidad con las bases de datos fuente de SQL Server que están configuradas para ejecutarse en un clúster Always On. En este caso,AWS DMS intenta rastrear si las copias de seguridad de las transacciones se realizan desde nodos del clúster Always On distintos del nodo en el que está alojada la instancia de la base de datos de origen. Al iniciar la tarea de migración,AWS DMS intenta conectarse a cada nodo del clúster, pero falla si no puede conectarse a ninguno de los nodos.

Si necesita AWS DMS para sondear todos los nodos del clúster Always On para realizar copias de seguridad de transacciones, establezca este atributo en false.

Valor predeterminado: true

Valores válidos: true o false

Ejemplo: '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

ActivateSafeguard

Este atributo activa o desactiva Safeguard. Para obtener información sobre Safeguard, consulteSafeguardPolicy lo siguiente.

Valor predeterminado: true

Valores válidos: {false, true}

Ejemplo: '{"ActivateSafeguard": true}'

SafeguardPolicy

Para obtener un rendimiento óptimo, AWS DMS intenta capturar todos los cambios que no se leyeron del registro de transacciones activas (TLOG). Sin embargo, en ocasiones, por las operaciones de truncado, es posible que el TLOG activo no contenga todos los cambios sin leer. Cuando esto ocurre, AWS DMS obtiene acceso al registro de copia de seguridad para capturar los cambios que faltan. Con el fin de reducir al mínimo la necesidad de obtener acceso al registro de copia de seguridad, AWS DMS evita las operaciones de truncado con uno de los siguientes métodos:

1. Start transactions in the database (Iniciar transacciones en la base de datos): este es el método predeterminado. Cuando se utiliza este método, AWS DMS evita la operación de truncado de TLOG y, para ello, imita una transacción en la base de datos. Siempre que una transacción esté abierta, los cambios que aparecen después de que la transacción se inicia no se truncan. Si necesita que Microsoft Replication esté habilitado en la base de datos, seleccione este método.

El propósito de laEXCLUSIVE_AUTOMATIC_TRUNCATION configuración es evitar que se trunquen los cambios no leídos del registro de transacciones. Al elegir esta opción,AWS DMS crea una tabla en la base de datos de origen llamadaaws_truncation_safeguard. Esta tabla evita el truncamiento del registro de transacciones al imitar una transacción en la base de datos. Impide que los eventos se trunquen y se muevan al registro de respaldo durante cinco minutos (de forma predeterminada). AWS DMSpuede entonces leer todos los eventos del registro de transacciones sin necesidad de leer los eventos del registro de respaldo. Puede eliminar laaws_truncation_safeguard tabla de forma segura si no hay ninguna tareaSafeguardPolicy configurada como «Iniciar transacciones en la base de datos».

2. Exclusively use sp_repldone within a single task (Usar exclusivamente sp_repldone en una sola tarea): cuando se utiliza este método, AWS DMS lee los cambios y, a continuación, utiliza sp_repldone para marcar las transacciones de TLOG como que ya están listas para las operaciones de truncado. Pese a que este método no incluye actividades transaccionales, solo se puede utilizar cuando Microsoft Replication no se está ejecutando. Además, cuando se utiliza este método, solo una tarea de AWS DMS puede tener acceso a la base de datos en un momento dado. Por lo tanto, si necesita ejecutar tareas de AWS DMS en paralelo en la misma base de datos, utilice el método predeterminado.

Valor predeterminado: RELY_ON_SQL_SERVER_REPLICATION_AGENT

Valores válidos: {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

Ejemplo: '{"SafeguardPolicy": "RELY_ON_SQL_SERVER_REPLICATION_AGENT"}'

Notas:

  • EXCLUSIVE_AUTOMATIC_TRUNCATION no funciona en RDS para instancias de origen de SQL Server porque los usuarios de RDS no tienen acceso para ejecutar el procedimiento almacenado de SQL Server,sp_repldone.

  • Si lo configuraEXCLUSIVE_AUTOMATIC_TRUNCATION sinSafeguardPolicy utilizar la función de administrador del sistema, debe conceder permisos sobre losdbo.sysjobs objetosdbo.syscategories y aldmsuser usuario.

SetUpMsCdcForTables

Este atributo activa el MS-CDC para la base de datos de origen y para las tablas del mapeo de tareas que no tienen habilitada la replicación de MS. Al establecer este valor en, setrue ejecuta el procedimientosp_cdc_enable_db almacenado en la base de datos de origen y se ejecuta el procedimientosp_cdc_enable_table almacenado en cada tabla de la tarea que no tenga habilitada la replicación de MS en la base de datos de origen. Para obtener más información acerca de cómo activar la distribución, consulteConfiguración de la replicación continua mediante el rol de administrador del sistema con SQL Server autogestionado.

Valores válidos: {true, false}

Ejemplo: '{"SetUpMsCdcForTables": true}'

ReadBackupOnly

El uso de este atributo requiere privilegios de administrador del sistema. Cuando este atributo se establece enY, durante la replicación continua, soloAWS DMS lee los cambios de las copias de seguridad del registro de transacciones y no desde el archivo de registro de transacciones activo. Establecer este parámetro en Y le permite controlar el crecimiento del archivo de registro de transacción activo durante la carga completa y las tareas de replicación en curso. Sin embargo, puede añadir latencia de origen a la replicación continua.

Valores válidos: N o Y. El valor predeterminado es N.

Ejemplo: '{"ReadBackupOnly": Y}'

Nota: Este parámetro no funciona en las instancias fuente de SQL Server de Amazon RDS debido a la forma en que RDS realiza las copias de seguridad.

Use3rdPartyBackupDevice

Cuando este atributo se establece enY,AWS DMS procesa las copias de seguridad del registro de transacciones de terceros si se crean en formato nativo.

"MultiSubnetFailover": "Yes"

Este atributo del controlador ODBC ayuda a DMS a conectarse al nuevo primario en caso de una conmutación por error del grupo de disponibilidad. Este atributo está diseñado para situaciones en las que la conexión se interrumpe o la dirección IP del oyente es incorrecta. En estas situaciones,AWS DMS intenta conectarse a todas las direcciones IP asociadas al oyente del grupo de disponibilidad.

"ApplicationIntent": "readonly"

Esta configuración de atributo del controlador ODBC hace que SQL Server dirija la tarea de replicación al nodo de solo lectura de mayor prioridad. Sin esta configuración, SQL Server dirige la tarea de replicación al nodo de lectura y escritura principal.

FatalOnSimpleModel

Cuando se establece entrue, esta configuración genera un error grave cuando el modelo de recuperación de bases de datos de SQL Server está establecido ensimple.

Valor predeterminado: false

Valores válidos: true o false

Ejemplo: '{"FatalOnSimpleModel": true}'

TlogAccessMode

Indica el modo utilizado para obtener los datos de los CDC.

Valor predeterminado: PreferTlog

Valores válidos: BackupOnly, PreferBackup, PreferTlog, TlogOnly

Ejemplo: '{"TlogAccessMode": "PreferTlog"}'

ForceLobLookup

Fuerza la búsqueda de LOB en un LOB en línea.

Valor predeterminado: false

Valores válidos: true, false

Ejemplo: '{"ForceLobLookup": false}'

Tipos de datos de origen para SQL Server

La migración de datos que utiliza SQL Server como origen para AWS DMS admite la mayoría de los tipos de datos de SQL Server. La siguiente tabla muestra los tipos de datos de origen de SQL Server que se admiten cuando se utiliza AWS DMS y el mapeo predeterminado desde los tipos de datos de AWS DMS.

Para obtener más información sobre cómo ver el tipo de datos que se asigna en el destino, consulte la sección del punto de enlace de destino que esté utilizando.

Para obtener más información sobre los tipos de datos de AWS DMS, consulte Tipos de datos para elAWS Database Migration Service.

Tipos de datos de SQL Server

Tipos de datos de AWS DMS

BIGINT

INT8

BIT

BOOLEANO

DECIMAL

NUMERIC

INT

INT4

MONEY

NUMERIC

NUMERIC (p,s)

NUMERIC

SMALLINT

INT2

SMALLMONEY

NUMERIC

TINYINT

UINT1

REAL

REAL4

FLOAT

REAL8

DATETIME

DATETIME

DATETIME2 (SQL Server 2008 y versiones posteriores)

DATETIME

SMALLDATETIME

DATETIME

DATE

DATE

TIME

TIME

DATETIMEOFFSET

WSTRING

CHAR

STRING

VARCHAR

STRING

VARCHAR (máx.)

CLOB

TEXT

Para utilizar este tipo de datos con AWS DMS, será preciso habilitar el uso de los tipos de datos CLOB para una tarea en particular.

Para las tablas de SQL Server, AWS DMS actualiza las columnas de LOB en el destino incluso para las instrucciones UPDATE que no cambian el valor de la columna de LOB en SQL Server.

En la CDC, AWS DMS admite tipos de datos CLOB solo en las tablas que incluyan una clave principal.

NCHAR

WSTRING

NVARCHAR (longitud)

WSTRING

NVARCHAR (máx.)

NCLOB

NTEXT

Para utilizar este tipo de datos conAWS DMS, debe habilitar el uso de SupportLobs para una tarea específica. Para obtener más información sobre cómo activar la compatibilidad con Lob, consulteConfiguración de la compatibilidad de LOB con bases de datos de origen en una tarea de AWS DMS.

Para las tablas de SQL Server, AWS DMS actualiza las columnas de LOB en el destino incluso para las instrucciones UPDATE que no cambian el valor de la columna de LOB en SQL Server.

En la CDC, AWS DMS admite tipos de datos CLOB solo en las tablas que incluyan una clave principal.

BINARY

BYTES

VARBINARY

BYTES

VARBINARY (máx.)

BLOB

IMAGE

Para las tablas de SQL Server, AWS DMS actualiza las columnas de LOB en el destino incluso para las instrucciones UPDATE que no cambian el valor de la columna de LOB en SQL Server.

Para utilizar este tipo de datos con AWS DMS, será preciso habilitar el uso de los tipos de datos BLOB para una tarea en particular.

AWS DMS solo es compatible con tipos de datos BLOB en las tablas que incluyen una clave principal.

TIMESTAMP

BYTES

UNIQUEIDENTIFIER

STRING

HIERARCHYID

Utilice HIERARCHYID cuando realice replicaciones en un punto de enlace de destino de SQL Server.

Utilice WSTRING (250) para realizar replicaciones en el resto de puntos de enlace.

XML

NCLOB

Para las tablas de SQL Server, AWS DMS actualiza las columnas de LOB en el destino incluso para las instrucciones UPDATE que no cambian el valor de la columna de LOB en SQL Server.

Para utilizar este tipo de datos con AWS DMS, será preciso habilitar el uso de los tipos de datos NCLOB para una tarea en particular.

En la CDC, AWS DMS admite tipos de datos NCLOB solo en las tablas que incluyan una clave principal.

GEOMETRY

Utilice GEOMETRY cuando realice replicaciones en puntos de enlace de destino que admitan este tipo de datos.

Utilice CLOB cuando realice replicaciones en puntos de enlace de destino que no admitan este tipo de datos.

GEOGRAPHY

Utilice GEOGRAPHY cuando realice replicaciones en puntos de enlace de destino que admitan este tipo de datos.

Utilice CLOB cuando realice replicaciones en puntos de enlace de destino que no admitan este tipo de datos.

AWS DMSno admite tablas que incluyan campos con los siguientes tipos de datos.

  • CURSOR

  • SQL_VARIANT

  • TABLE

nota

Se admiten tipos de datos definidos por el usuario en función de su tipo base. Por ejemplo, un tipo de datos definido por el usuario basado en DATETIME se gestiona como un tipo de datos DATETIME.