Uso de una base de datos de Microsoft SQL Server como fuente para AWS DMS - AWS Database Migration Service
Restricciones en SQL Server como origenPermisos de SQL ServerRequisitos previos para utilizar CDC de forma continuaCaptura de cambios para SQL Server autoadministrado en las instalaciones o en Amazon EC2Configuración de la replicación continua en una instancia de base de datos de SQL Server de la nubeConfiguración opcional de RDS para SQL Server como origenMétodos de compresión compatiblesTrabaja con grupos de disponibilidad de SQL Server autogestionados AlwaysOnRequisitos de seguridadConfiguración del punto de conexiónTipos 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 fuente para AWS DMS

Migre datos de una o varias bases de datos de Microsoft SQL Server mediante AWS DMS. Con una base de datos de SQL Server como origen, puede migrar los datos a otra base de datos de SQL Server o a una de las otras bases de datos AWS DMS compatibles.

Para obtener información sobre las versiones de SQL Server que se AWS DMS admiten como fuente, consulteFuentes de AWS DMS.

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 permisos view definition y view server state. Agregue este permiso mediante el siguiente comando:

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

AWS DMS admite la migración de datos desde 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 designada de SQL Server y utilícelo para configurar el punto final de AWS DMS origen.

nota

El puerto 1433 es el predeterminado para Microsoft SQL Server. Pero también es habitual usar puertos dinámicos que cambian cada vez que se inicia SQL Server y números de puerto estáticos específicos utilizados para conectarse a SQL Server a través de un firewall. Por lo tanto, querrá saber el número de puerto real de la instancia designada de SQL Server al crear el punto final de AWS 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 AWS DMS, consulte lo siguiente.

Limitaciones del uso de SQL Server como fuente de 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 punto final de SQL Server no admite el uso de tablas con columnas 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.

  • Al utilizar las utilidades WRITETEXT y UPDATETEXT, AWS DMS no captura los eventos aplicados a 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.

  • AWS DMS no 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 se ejecuta el siguiente comando, se produce AWS DMS 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 LOB completo cuando se utiliza SQL Server como origen. En su lugar, utilice el modo de LOB limitado o establezca la opción de la tarea InlineLobMaxSize para que utilice el modo de LOB insertado.

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

  • La migración de datos desde non-schema-bound vistas y vinculadas a un esquema solo se admite 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 DMS no admite el procesamiento de cambios para establecer y desestablecer los valores predeterminados de las columnas (utilizando la ALTER COLUMN SET DEFAULT cláusula con declaraciones). ALTER TABLE

  • AWS DMS no admite el procesamiento de cambios para establecer la nulabilidad de las columnas (se usa la ALTER COLUMN [SET|DROP] NOT NULL cláusula con ALTER TABLE declaraciones).

  • 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 en el caso de las bases de datos de distribución utilizadas en topologías de fusión, bidireccionales o peer-to-peer de replicación.

  • En el caso de 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 (GEOGRAPHY y GEOMETRY), puede omitir 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 de punto de conexión readBackupOnly=Y (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_TRUNCATION no funciona en las instancias de origen 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 DMS no captura los comandos de truncamiento.

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

  • AWS DMS no admite la captura de sentencias del lenguaje de definición de datos (DDL) y del lenguaje de manipulación de datos (DML) en una sola transacción.

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

  • Las instrucciones UPDATE que incluyen claves principales o índices únicos y actualizan varias filas de datos pueden provocar conflictos al aplicar cambios en la base de datos de destino. Esto puede suceder, por ejemplo, cuando la base de datos de destino aplica las actualizaciones como instrucciones INSERT y DELETE en lugar de aplicar una sola instrucción UPDATE. Con el modo de aplicación optimizado por lotes, es posible que se ignore la tabla. Con el modo de aplicación transaccional, es posible que la operación UPDATE provoque infracciones de las restricciones. Para evitar este problema, vuelva a cargar la tabla correspondiente. Como alternativa, localice los registros problemáticos en la tabla de control de aplicación de excepciones (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 DMS no 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 DMS migra datos enmascarados sin enmascararlos.

  • AWS DMS replica hasta 32 767 tablas con claves principales y hasta 1000 columnas para cada tabla. Esto se debe a que AWS 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 Captura de datos de cambios (CDC), debe definir todas las columnas que componen un índice único como NOT NULL. Si no se cumple este requisito, se generará el error 22838 del sistema de 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.

  • AWS DMS no admite el procesamiento directo de las copias de seguridad del registro de transacciones a nivel de archivo desde carpetas compartidas alternativas.

Permisos para tareas que son solo de carga completa

Los siguientes permisos son necesarios para realizar tareas que son solo de carga completa. Tenga en cuenta que AWS DMS esto no crea el dms_user inicio de sesión. Para obtener información acerca de cómo crear un inicio de sesión para SQL Server, consulte Creación de un usuario de base de datos con Microsoft SQL Server.

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 el uso de la replicación continua (CDC) desde un origen de SQL Server

Puede utilizar la replicación continua (captura de datos de cambios o CDC) para una base de datos de SQL Server autoadministrada en las instalaciones o en Amazon EC2, una base de datos de la nube como Amazon RDS o una instancia administrada por 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 grabar la copia de seguridad de la base de datos en varios archivos en discos diferentes, no AWS DMS se pueden leer los datos y la AWS DMS tarea falla.

  • Para orígenes autoadministrados de SQL Server, las definiciones del publicador de replicación de SQL Server para el origen que se utiliza en una tarea de CDC de DMS no se eliminan cuando se elimina 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 debe buscar las copias de seguridad del registro de transacciones de SQL Server para leer los cambios. AWS DMS no admite las copias de seguridad del registro de transacciones de SQL Server creadas con software de copia de seguridad de terceros que no esté en formato nativo. Para admitir las copias de seguridad del registro de transacciones que están en formato nativo y creadas con software de copia de seguridad de terceros, agregue el atributo de conexión use3rdPartyBackupDevice=Y al punto de conexión 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 se agregan tablas a una fuente de SQL Server, AWS DMS gestiona 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 DMS La 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 tlog 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 ingresó por vez primera la característica) y a versiones superiores.

  • AWS DMS la captura de datos de cambios requiere una base de datos de distribución de forma predeterminada en Amazon EC2 o en un servidor SQL local como fuente. Por lo tanto, asegúrese de haber activado el distribuidor al configurar la replicación de MS para tablas con claves principales.

Captura de cambios de datos para SQL Server autoadministrado en las instalaciones o en Amazon EC2

Para capturar los cambios de una base de datos de origen de Microsoft SQL Server, 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 total o en modo de registro masivo.

Para una fuente de SQL Server autogestionada, AWS DMS utiliza lo siguiente:

Replicación de MS

Para capturar cambios para las tablas con las claves principales. Puede configurarlo automáticamente otorgando privilegios de administrador del sistema al usuario de AWS 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 de sistemas para el punto final. AWS DMS

MS-CDC

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

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

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

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

Configurar la replicación continua en un SQL Server autoadministrado

Esta sección contiene información sobre cómo configurar la replicación continua en un SQL Server autoadministrado con o sin el rol sysadmin.

Configuración de la replicación continua en un SQL Server autoadministrado: uso del rol sysadmin

AWS DMS la 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, consulte Requisitos previos para el uso de la replicación continua (CDC) desde un origen de SQL Server.

En el caso de las tablas con claves principales, generalmente se AWS DMS pueden configurar los artefactos necesarios en la fuente. Sin embargo, para las instancias de origen de SQL Server autoadministradas, asegúrese de configurar primero la distribución de SQL Server de forma manual. Una vez hecho esto, los usuarios de AWS DMS origen con permisos 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 es NULL para la distribución de columnas, la distribución no se ha configurado. Puede usar el siguiente procedimiento para configurar la distribución.

Configuración de la distribución

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

  2. Abra el menú contextual (haga clic con el botón derecho) para la carpeta Replicación y elija Configurar distribución. Aparecerá el asistente para configurar la distribución.

  3. Siga el asistente para especificar los valores predeterminados y crear la distribución.

Configuración de CDC

AWS DMS La versión 3.4.7 y las versiones posteriores permiten 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 característica, establezca ECA SetUpMsCdcForTables como verdadero. Para obtener más información sobre ECA, consulte Configuración del punto de conexión.

Para las versiones AWS 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 las tablas sin claves principales, configure MS-CDC para la base de datos. Para ello, utilice una cuenta que tenga asignado el rol sysadmin 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 la que desee configurar 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 claves principales ni claves únicas, ejecute la siguiente consulta para la que desee 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 en un SQL Server independiente: sin el rol de sysadmin

Para obtener información sobre la configuración de la replicación continua en un SQL Server independiente sin el rol de sysadmin, consulte Configuración de la replicación continua en un SQL Server independiente: sin el rol de sysadmin.

Configuración de la replicación continua en una instancia de base de datos de SQL Server de 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 para SQL Server, una instancia administrada por Azure SQL o cualquier otra instancia de SQL Server administrada en la nube. Para obtener información sobre las limitaciones de la replicación continua para cada tipo de base de datos, consulte Limitaciones del uso de SQL Server como fuente de AWS DMS.

Antes de configurar la replicación continua, consulte Requisitos previos para el uso de la replicación continua (CDC) desde un origen de SQL Server.

A diferencia de los orígenes autoadministrados de Microsoft SQL Server, Amazon RDS para SQL Server no es compatible con MS-Replication. Por lo tanto, AWS DMS debe usar MS-CDC para tablas con o sin claves principales.

Amazon RDS no concede privilegios de administrador del sistema para configurar artefactos de replicación que se AWS DMS utilizan para los cambios continuos en una instancia de SQL Server de origen. Asegúrese de activar MS-CDC para la instancia de Amazon RDS (mediante privilegios de usuario principal) como se explica en el procedimiento siguiente.

Activación de MS-CDC para una instancia de base de datos de SQL Server de la nube

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

    Para una instancia de base de datos de RDS para SQL Server, utilice esta consulta.

    exec msdb.dbo.rds_cdc_enable_db 'DB_name'

    Para una instancia de base de datos administrada 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 la que desee activar 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 la que desee activar 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 claves principales ni claves únicas, ejecute la siguiente consulta para la que desee activar 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 retiene 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 de pollinginterval está establecido en más de 3599 segundos, se restablece a los cinco segundos predeterminados. Cuando esto ocurre, las entradas de T-Log se purgan antes de que pueda leerlas. AWS DMS 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 la secundaria 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 de AWS 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 de AWS DMS replicación

  1. Detenga el trabajo truncando los registros de transacciones mediante el uso del siguiente comando. 

    exec sp_cdc_stop_job 'capture'

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

  3. Elija la pestaña Monitoreo y compruebe la métrica CDCLatencySource.

  4. Una vez que la métrica CDCLatencySource sea igual a 0 (cero) y permanezca sin cambios, vuelva a iniciar el trabajo truncando los registros de transacción mediante 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, es posible que el almacenamiento de la instancia de SQL Server se llene.

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

  • AWS DMS admite la replicación continua (CDC) únicamente con el registro de transacciones activo. No puede usar el registro de copia de seguridad con CDC.

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

Configuración recomendada cuando se utiliza Amazon RDS for SQL Server como fuente de AWS DMS

Cuando trabaja con Amazon RDS para SQL Server como origen, el trabajo de captura se basa en los parámetros maxscans y maxtrans. Estos parámetros rigen 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 superior a maxtrans*maxscans, el aumento del valor polling_interval puede provocar una acumulación de registros de transacciones activos. A su vez, esta acumulación puede provocar un aumento del tamaño del registro de transacciones.

Tenga en cuenta que AWS DMS no se basa en el trabajo de captura de MS-CDC. El trabajo de captura de MS-CDC marca las entradas del registro de transacciones como procesadas. Esto permite que el trabajo de copia de seguridad del registro de transacciones elimine las entradas del registro de transacciones.

Le recomendamos que monitoree el tamaño del registro de transacciones y el éxito de los trabajos de MS-CDC. Si las tareas de MS-CDC fallan, el registro de transacciones podría crecer excesivamente y provocar errores de replicación. AWS DMS Puede monitorear los errores de los trabajos de captura de MS-CDC mediante la vista de administración dinámica sys.dm_cdc_errors de la base de datos de origen. Puede monitorear el tamaño del registro de transacciones mediante el comando de gestión DBCC SQLPERF(LOGSPACE).

Solución al aumento del registro de transacciones provocado por MS-CDC

  1. Compruebe la base Log Space Used % de datos desde la AWS DMS que se está replicando y valide que aumente continuamente.

    DBCC SQLPERF(LOGSPACE)

  2. Identifique qué es lo que bloquea 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 el valor log_reuse_wait_desc es igual a REPLICATION, 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 los parámetros maxtrans y maxscans.

    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 de maxscans y de maxtrans forma que sean iguales al número medio de eventos generados en las tablas que maxtrans*maxscans se AWS DMS replican desde la base de datos de origen cada día.

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

Puede resultar difícil identificar los valores adecuados para maxscans y maxtrans, ya que los cambios en la carga de trabajo producen un número variable de eventos. En este caso, le recomendamos que configure el monitoreo de la latencia de MS-CDC. Para obtener más información, consulte Monitorear el proceso en la documentación de SQL Server. A continuación, configure maxtrans y maxscans de forma dinámica en función de los resultados del monitoreo.

Si la AWS DMS tarea no encuentra los números de secuencia de registro (LSN) necesarios para reanudar o continuar la tarea, es posible que se produzca un error en la tarea y que sea necesario volver a cargarla por completo.

nota

Cuando se utiliza AWS DMS para replicar datos desde una fuente de RDS para SQL Server, es posible que se produzcan errores al intentar reanudar la replicación tras un evento de parada e inicio de la instancia de Amazon RDS. Esto se debe a que el proceso del agente de SQL Server reinicia el proceso del trabajo de captura cuando se reinicia después del evento de parada e inicio. Esto evita el intervalo de sondeo de MS-CDC.

Por este motivo, en las bases de datos con volúmenes de transacciones inferiores al procesamiento de los trabajos de captura de MS-CDC, esto puede provocar que los datos se procesen o se marquen como replicados y respaldados antes de que AWS DMS puedan reanudarse desde donde se detuvieron, lo que provoca el siguiente error:

[SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764)

Para mitigar este problema, defina los valores maxtrans y maxscans tal como se recomendó anteriormente.

Métodos de compresión admitidos para SQL Server

Tenga en cuenta lo siguiente acerca de la compatibilidad con los métodos de compresión de SQL Server en AWS DMS:

  • AWS DMS admite la compresión de filas/páginas en la versión 2008 y posteriores de SQL Server.

  • AWS DMS no admite el formato de almacenamiento Vardecimal.

  • AWS DMS no admite la compresión de columnas dispersas ni de estructuras columnares.

Trabaja con grupos de disponibilidad de SQL Server autogestionados AlwaysOn

Los grupos de disponibilidad AlwaysOn de SQL Server proporcionan alta disponibilidad y recuperación de desastres que representa una alternativa a nivel empresarial a la duplicación de bases de datos.

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

Trabajo con la réplica del grupo de disponibilidad principal

Para usar el grupo de disponibilidad principal como fuente de entrada AWS DMS, haga lo siguiente:

  1. Active la opción de distribución para todas las instancias de SQL Server en las réplicas de disponibilidad. Para obtener más información, consulte Configurar la replicación continua en un SQL Server autoadministrado.

  2. En la AWS DMS consola, abra la configuración de la base de datos de origen de SQL Server. Para Nombre de servidor especifique el nombre del servicio de nombres de dominio (DNS) o la dirección IP que se configuró para el oyente del grupo 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 produce porque el servidor de grupos de disponibilidad duplica la creación de los artículos de la tabla.

Trabajo con una réplica del grupo de disponibilidad secundario

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

  1. Use las mismas credenciales para conectarse a réplicas individuales que usa el usuario del punto final AWS DMS de origen.

  2. Asegúrese de que su instancia de AWS DMS replicación pueda resolver los nombres de DNS de todas las réplicas existentes y conéctese a ellas. Puede usar la siguiente consulta SQL para obtener los nombres de DNS de todas las 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 punto de conexión de origen, especifique el nombre de DNS del oyente del grupo de disponibilidad para el nombre del servidor del punto de conexión o para la dirección del servidor secreto del punto de conexión. Para obtener más información sobre los oyentes de grupos de disponibilidad, consulte ¿Qué es un oyente de grupos de disponibilidad? en la documentación de SQL Server.

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

  4. Agregue los siguientes atributos de conexión adicionales al punto de conexión 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 Asistencia de clientes de nativos de SQL Server para alta disponibilidad y recuperación de desastres en la documentación de SQL Server.
    multiSubnetFailover yes Para obtener más información, consulte Asistencia de clientes de nativos de SQL Server para alta disponibilidad y recuperación de desastres en la documentación de SQL Server.
    alwaysOnSharedSynchedBackupIsEnabled false Para obtener más información, consulte Configuración del punto final cuando se utiliza SQL Server como fuente para AWS 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 del grupo de disponibilidad. Agregue todos los nodos a la lista de distribuidores. Para obtener más información, consulte Configuración de la distribución.

  6. Ejecute la siguiente consulta en la réplica de lectura y escritura principal para habilitar la publicación de la base de datos. Se 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 grupo de disponibilidad secundario:

  • AWS DMS no es compatible con Safeguard cuando utiliza una réplica de un grupo de disponibilidad de solo lectura como fuente. Para obtener más información, consulte Configuración del punto final cuando se utiliza SQL Server como fuente para AWS DMS.

  • AWS DMS no admite el atributo de conexión setUpMsCdcForTables 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 del punto final cuando se utiliza SQL Server como fuente para AWS DMS.

  • AWS DMS puede utilizar una réplica autogestionada de un grupo de disponibilidad secundario 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 SQL Server en la nube. Si usa versiones anteriores de AWS DMS, asegúrese de usar 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 establece el atributo de conexión ApplicationIntent adicional para su terminal enReadOnly, la AWS DMS tarea se conecta al nodo de solo lectura con la prioridad de enrutamiento de solo lectura más alta. A continuación, se conmuta por error a otros nodos de solo lectura en el grupo de disponibilidad cuando el nodo de solo lectura de mayor prioridad no está disponible. Si no lo establecesApplicationIntent, la AWS DMS tarea solo se conecta al nodo principal (lectura/escritura) de tu grupo de disponibilidad.

Requisitos de seguridad al utilizar SQL Server como fuente de AWS Database Migration Service

La cuenta AWS DMS de usuario debe tener al menos el rol de db_owner usuario en la base de datos de origen de SQL Server a la que se está conectando.

Configuración del punto final cuando se utiliza SQL Server como fuente para AWS DMS

Puede utilizar la configuración de punto de conexión para configurar la base de datos de origen de SQL Server de forma similar al uso de atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de origen mediante la AWS DMS consola o mediante el create-endpoint comando del AWS CLI, con la sintaxis --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON.

La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con SQL Server como origen.

Nombre Descripción

ActivateSafeguard

Este atributo activa o desactiva la protección. Para obtener más información sobre la protección, consulte SafeguardPolicy a continuación.

Valor predeterminado: true

Valores válidos: {false, true}

Ejemplo: '{"ActivateSafeguard": true}'
AlwaysOnSharedSynchedBackupIsEnabled

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

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

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

Valor predeterminado: true

Valores válidos: true o false

Ejemplo: '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

"ApplicationIntent": "readonly"

Esta configuración de atributos 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 principal de lectura-escritura.

EnableNonSysadminWrapper

Utilice esta configuración de punto de conexión cuando configure la replicación continua en un servidor SQL independiente sin un usuario sysadmin. Este parámetro es compatible con la AWS DMS versión 3.4.7 y versiones posteriores. Para obtener información sobre la configuración de la replicación continua en un SQL Server independiente, consulte Configuración de la replicación continua en un SQL Server independiente: sin el rol de sysadmin.

Valor predeterminado: false

Valores válidos: true, false

Ejemplo: '{"EnableNonSysadminWrapper": true}'

ExecuteTimeout

Utilice este atributo de conexión adicional (ECA) para establecer el tiempo de espera de la instrucción del cliente para la instancia de SQL Server, en segundos. El valor de predeterminado es de 60 segundos.

Ejemplo: '{"ExecuteTimeout": 100}'

FatalOnSimpleModel

Si se establece en true, esta configuración genera un error grave cuando el modelo de recuperación de bases de datos de SQL Server está establecido en simple.

Valor predeterminado: false

Valores válidos: true o false

Ejemplo: '{"FatalOnSimpleModel": true}'

ForceLobLookup

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

Valor predeterminado: false

Valores válidos: true, false

Ejemplo: '{"ForceLobLookup": false}'

"MultiSubnetFailover": "Yes"

Este atributo del controlador ODBC ayuda a DMS a conectarse al nuevo principal 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 listener del grupo de disponibilidad.

ReadBackupOnly

El uso de este atributo requiere privilegios de sysadmin. Cuando este atributo se establece enY, durante la replicación en curso, solo AWS DMS lee los cambios de las copias de seguridad del registro de transacciones y no lee del 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 de origen de SQL Server de Amazon RDS debido a la forma en que RDS realiza las copias de seguridad.

SafeguardPolicy

Para obtener un rendimiento óptimo, AWS DMS intenta capturar todos los cambios no leídos del registro de transacciones activo (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 accede a la copia de seguridad del registro para capturar los cambios que faltan. Para minimizar la necesidad de acceder a la copia de seguridad del registro, AWS DMS evita el truncamiento mediante uno de los siguientes métodos:

  1. RELY_ON_SQL_SERVER_REPLICATION_AGENT(Iniciar transacciones en la base de datos): es el valor predeterminado para. AWS DMS

    Cuando se usa esta configuración, AWS DMS requiere que el agente de lectura de registros de SQL Server esté en ejecución, de modo que AWS DMS pueda mover las transacciones que estén marcadas para la replicación desde TLOG activo. Tenga en cuenta que si el agente de lectura de registros no está en ejecución, TLOG activo puede llenarse y provocar que la base de datos de origen pase al modo de solo lectura hasta que se resuelva el problema. Si necesita habilitar la replicación de Microsoft en su base de datos para un propósito diferente AWS DMS, debe elegir esta configuración.

    Al usar esta configuración, se AWS DMS minimizan las lecturas de las copias de seguridad de los registros mediante la creación de una tabla llamada TLOG awsdms_truncation_safeguard y se evita el truncamiento del registro al imitar una transacción abierta en la base de datos. Esto evita que la base de datos trunque los eventos y los mueva al registro de copias de seguridad durante cinco minutos (de forma predeterminada). Asegúrese de que la tabla no esté incluida en ningún plan de mantenimiento, ya que podría provocar un error en el trabajo de mantenimiento. Puede eliminar la tabla de forma segura si no hay tareas configuradas con la opción de base de datos Start Transactions.

  2. EXCLUSIVE_AUTOMATIC_TRUNCATION(Se usa exclusivamente sp_repldone con una sola tarea): al usar esta configuración, AWS DMS tiene el control total del proceso del agente de replicación que marca las entradas de registro como activas. ready for truncation sp_repldone Con esta configuración, AWS DMS no utiliza una transacción ficticia como ocurre con la configuración RELY_ON_SQL_SERVER_REPLICATION_AGENT (predeterminada). Solo puede usar esta configuración cuando MS Replication no se usa para ningún otro propósito que no sea AWS DMS en la base de datos de origen. Además, al usar esta configuración, solo una AWS DMS tarea puede acceder a la base de datos. Si necesita ejecutar AWS DMS tareas paralelas en la misma base de datos, utiliceRELY_ON_SQL_SERVER_REPLICATION_AGENT.

    • Esta configuración requiere que el agente de lectura de registro esté detenido en la base de datos. Si el agente Log Reader está en ejecución cuando se inicia la AWS DMS tarea, la tarea forzará su detención. Como alternativa, puede detener el agente de lectura de registro manualmente antes de iniciar la tarea.

    • Si utiliza este método con MS-CDC, debe detener y desactivar las tareas de captura de MS-CDC y limpieza de MS-CDC.

    • No puede usar esta configuración cuando el trabajo de migración de Microsoft SQL Server se ejecuta en una máquina distribuidora remota porque AWS DMS no tiene acceso a la máquina remota.

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

    • Si configura SafeguardPolicy en EXCLUSIVE_AUTOMATIC_TRUNCATION sin usar el rol sysadmin, debe conceder permisos sobre los objetos dbo.syscategories y dbo.sysjobs al usuario dmsuser.

Valor predeterminado: RELY_ON_SQL_SERVER_REPLICATION_AGENT

Valores válidos: {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

Ejemplo: '{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'

SetUpMsCdcForTables

Este atributo activa MS-CDC para la base de datos de origen y para las tablas de asignación de tareas que no tienen habilitada la replicación por MS. Al establecer este valor en true se ejecuta el procedimiento almacenado sp_cdc_enable_db en la base de datos de origen y se ejecuta el procedimiento almacenado sp_cdc_enable_table en cada tabla de la tarea que no tenga habilitada la replicación por MS en la base de datos de origen. Para obtener más información acerca de la activación de la distribución, consulte Configurar la replicación continua en un SQL Server autoadministrado.

Valores válidos: {true, false}

Ejemplo: '{"SetUpMsCdcForTables": true}'

TlogAccessMode

Indica el modo utilizado para obtener los datos de CDC.

Valor predeterminado: PreferTlog

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

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

Use3rdPartyBackupDevice

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

Tipos de datos de origen para SQL Server

La migración de datos que utiliza SQL Server como fuente AWS DMS es compatible con 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 utilizan AWS DMS y la asignación predeterminada a partir de AWS DMS los tipos de datos.

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 información adicional sobre AWS DMS los tipos de datos, consulteTipos de datos de AWS Database Migration Service.

Tipos de datos de SQL Server

AWS DMS tipos de datos

BIGINT

INT8

BIT

BOOLEAN

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 superiores)

DATETIME

SMALLDATETIME

DATETIME

FECHA

FECHA

TIME

TIME

DATETIMEOFFSET

WSTRING

CHAR

STRING

VARCHAR

STRING

VARCHAR (máx.)

CLOB

TEXT

Para usar este tipo de datos con AWS DMS, debe habilitar el uso de tipos de datos CLOB para una tarea específica.

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

Durante la CDC, solo AWS DMS admite los tipos de datos CLOB en las tablas que incluyen una clave principal.

NCHAR

WSTRING

NVARCHAR (longitud)

WSTRING

NVARCHAR (máx.)

NCLOB

NTEXT

Para usar este tipo de datos con AWS DMS, debe habilitar el uso de SupportLobs para una tarea específica. Para obtener más información acerca de cómo habilitar la compatibilidad con LOB, consulte Configurar la compatibilidad con LOB para las bases de datos de origen de una tarea AWS DMS.

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

Durante la CDC, solo AWS DMS admite los tipos de datos CLOB en las tablas que incluyen una clave principal.

BINARY

BYTES

VARBINARY

BYTES

VARBINARY (máx.)

BLOB

IMAGE

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

Para usar este tipo de datos con AWS DMS, debe habilitar el uso de tipos de datos BLOB para una tarea específica.

AWS DMS solo admite los 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

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

Para usar este tipo de datos con AWS DMS, debe habilitar el uso de los tipos de datos NCLOB para una tarea específica.

Durante los CDC, solo AWS DMS admite los tipos de datos NCLOB en las tablas que incluyen 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 DMS no 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.