Restricciones en SQL Server como origen Permisos de SQL Server Requisitos previos para utilizar CDC de forma continua Métodos de compresión compatibles Trabajo con grupos de disponibilidad AlwaysOn de SQL Server autoadministrados Configuración del punto de conexión Tipos de datos de origen para SQL Server

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.

Para obtener información sobre las versiones del servidor de SQL que AWS DMS admite como origen, consulte Orígenes para 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. Para obtener más información, consulte Permisos para las tareas de SQL Server.

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. 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, desea conocer el número de puerto real de la instancia con nombre de SQL Server al crear el punto de conexión de origen de AWS DMS.

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.

Puede usar CDC para la migración continua desde una base de datos de SQL Server. Para obtener más información sobre cómo configurar la base de datos de SQL Server de origen para CDC, consulte Captura de cambios en los datos para la replicación continua desde SQL Server.

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.

Temas

Restricciones en el uso de SQL Server como origen para AWS DMS
Permisos para las tareas de SQL Server
Requisitos previos para el uso de la replicación continua (CDC) desde un origen de SQL Server
Métodos de compresión admitidos para SQL Server
Trabajo con grupos de disponibilidad AlwaysOn de SQL Server autoadministrados
Configuración de punto de conexión cuando se utiliza SQL Server como origen para AWS DMS
Tipos de datos de origen para SQL Server
Captura de cambios en los datos para la replicación continua desde SQL Server

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 punto de conexión de SQL Server no es compatible con 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.
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.
AWS DMS no admite auditorías en nivel de servidor en SQL Server 2008 o SQL Server 2008 R2 como orígenes. 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 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 vistas vinculadas al esquema y no vinculadas al 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 anular los valores predeterminados de columna (con la cláusula ALTER COLUMN SET DEFAULT con las instrucciones ALTER TABLE).
AWS DMS no admite el procesamiento de cambios para establecer la nulabilidad de las columnas (se usa la cláusula ALTER COLUMN [SET|DROP] NOT NULL con las instrucciones ALTER TABLE).
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 que se utilizan en topologías de replicación combinada, bidireccional o de punto a punto.
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 (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 instrucciones de lenguaje de definición de datos (DDL) y de 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 los datos enmascarados sin enmascaramiento.
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.
Puede perder eventos si SQL Server los archiva del registro de transacciones activo al registro de copia de seguridad o los trunca del registro de transacciones activo.

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 en el nivel de archivo desde carpetas compartidas alternativas.
Para orígenes de SQL Server en la nube distintos de Amazon RDS para Microsoft SQL Server, AWS DMS admite la replicación continua (CDC) solo con el registro de transacciones activo. No puede usar el registro de copia de seguridad con CDC. Puede perder eventos si SQL Server los archiva del registro de transacciones activo al registro de copia de seguridad o los trunca del registro de transacciones activo antes de que DMS pueda leerlo.
En el caso de orígenes de Amazon RDS para Microsoft SQL Server, AWS DMS 3.5.2 y las versiones anteriores admiten la replicación continua (CDC) solo con el registro de transacciones activo, ya que DMS no puede acceder al registro de copias de seguridad con CDC. Puede perder eventos si RDS para SQL Server los archiva del registro de transacciones activo al registro de copia de seguridad o los trunca del registro de transacciones activo antes de que DMS pueda leerlo. Esta limitación no se aplica a AWS DMS versión 3.5.3 y posteriores.

Permisos para las tareas de SQL Server

Temas

Permisos para tareas que son solo de carga completa
Permisos para tareas con replicación continua

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 no crea el inicio de sesión de dms_user. 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;
                GRANT VIEW DEFINITION to dms_user;
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

Permisos para tareas con replicación continua

Las instancias autoadministradas de SQL Server se pueden configurar para la replicación continua mediante DMS con o sin usar el rol sysadmin. En el caso de las instancias de SQL Server, en las que no puede conceder el rol sysadmin, asegúrese de que el usuario de DMS tenga los privilegios que se describen a continuación.

Configuración de permisos para la replicación continua desde una base de datos de SQL Server autoadministrada

Cree una cuenta de SQL Server con autenticación mediante contraseña a través de SQL Server Management Studio (SSMS) o como se describe anteriormente en Permisos para tareas que son solo de carga completa, por ejemplo self_managed_user.

Ejecute los siguientes comandos GRANT:


GRANT VIEW SERVER STATE TO self_managed_user;

USE MSDB;
    GRANT SELECT ON MSDB.DBO.BACKUPSET TO self_managed_user;
    GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO self_managed_user;
    GRANT SELECT ON MSDB.DBO.BACKUPFILE TO self_managed_user;
    
USE db_name;
    CREATE USER self_managed_user FOR LOGIN self_managed_user;
    ALTER ROLE [db_owner] ADD MEMBER self_managed_user;
    GRANT VIEW DEFINITION to self_managed_user;

Además de los permisos anteriores, el usuario debe cumplir uno de los siguientes requisitos:
- El usuario debe ser miembro del rol de servidor fijo sysadmin.
- Deben establecerse las configuraciones y permisos que se describen en Configuración de la replicación continua en un SQL Server en un entorno de grupos de disponibilidad: sin el rol de sysadmin o Configuración de la replicación continua en un SQL Server independiente: sin el rol de sysadmin, en función de la configuración de origen.

Configuración de permisos para la replicación continua desde una base de datos de SQL Server en la nube

Una instancia de SQL Server alojada en la nube es una instancia que se ejecuta en Amazon RDS para Microsoft SQL Server, una instancia administrada por Azure SQL o cualquier otra instancia de SQL Server administrada en la nube compatible con DMS.

Cree una cuenta de SQL Server con autenticación mediante contraseña a través de SQL Server Management Studio (SSMS) o como se describe anteriormente en Permisos para tareas que son solo de carga completa, por ejemplo rds_user.

Ejecute los siguientes comandos Grant.


GRANT VIEW SERVER STATE TO rds_user;

USE MSDB;
    GRANT SELECT ON MSDB.DBO.BACKUPSET TO rds_user;
    GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO rds_user;
    GRANT SELECT ON MSDB.DBO.BACKUPFILE TO rds_user;
    
USE db_name;
    CREATE USER rds_user FOR LOGIN rds_user;
    ALTER ROLE [db_owner] ADD MEMBER rds_user;
    GRANT VIEW DEFINITION to rds_user;

En el caso de los orígenes de Amazon RDS para Microsoft SQL Server, DMS 3.5.3 y las versiones posteriores admiten la lectura de copias de seguridad del registro de transacciones. Para garantizar que DMS pueda acceder a las copias de seguridad de los registros, además de lo anterior, conceda privilegios de usuario master o bien los siguientes privilegios en un origen SQL Server de RDS:


//DMS 3.5.3 version onwards
GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user;
GRANT EXEC ON msdb.dbo.rds_task_status TO rds_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 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.
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 copias de seguridad del registro de transacciones de SQL Server para leer los cambios. AWS DMS no admite copias de seguridad del registro de transacciones de SQL Server creadas mediante el software de copia de seguridad de terceros que no estén 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 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.
La captura de datos de cambios de AWS DMS requiere que se active el registro de transacciones completo 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.
La captura de datos de cambios de AWS DMS requiere una base de datos de distribución de forma predeterminada en Amazon EC2 o en un servidor SQL en las instalaciones como origen. Por lo tanto, asegúrese de haber activado el distribuidor al configurar la replicación de MS para tablas con claves principales.

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 de 2008 y más recientes de SQL Server.
AWS DMS no admite el formato de almacenamiento Vardecimal.
AWS DMS no admite las columnas dispersas ni la compresión de la estructura de las columnas.

Trabajo con grupos de disponibilidad AlwaysOn de SQL Server autoadministrados

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 utilizar el grupo de disponibilidad principal como origen en AWS DMS, haga lo siguiente:

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.
En la consola de AWS DMS, abra la configuración de bases 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 utilizar un grupo de disponibilidad secundario como un origen en AWS DMS, haga lo siguiente:

Utilice las mismas credenciales para conectarse a réplicas individuales que utiliza el usuario del punto de conexión de origen de AWS DMS.
Asegúrese de que la instancia de replicación de AWS DMS 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>';
```
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.

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 de punto de conexión cuando se utiliza SQL Server como origen 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.

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.
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 la protección cuando se utiliza una réplica de un grupo de disponibilidad de solo lectura como origen. Para obtener más información, consulte Configuración de punto de conexión cuando se utiliza SQL Server como origen para AWS DMS.
AWS DMS no es compatible con el atributo de conexión adicional setUpMsCdcForTables cuando se utiliza una réplica de un grupo de disponibilidad de solo lectura como origen. Para obtener más información, consulte Configuración de punto de conexión cuando se utiliza SQL Server como origen para AWS DMS.
AWS DMS puede usar una réplica autoadministrada 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 utiliza versiones anteriores de AWS DMS, asegúrese de usar la réplica del grupo de disponibilidad principal como base de datos de origen para CDC.

Conmutación por error a otros nodos

Si establece el atributo de conexión adicional ApplicationIntent para el punto de conexión en ReadOnly, la tarea de AWS DMS 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 establece ApplicationIntent, la tarea de AWS DMS solo se conecta al nodo principal (lectura/escritura) del grupo de disponibilidad.

Configuración de punto de conexión cuando se utiliza SQL Server como origen 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. Se especifican los ajustes cuando se crea el punto de conexión de origen mediante la consola de AWS DMS o mediante el comando create-endpoint en la AWS CLI, con la sintaxis JSON --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}'.

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 de AWS DMS al migrar desde una base de datos de origen SQL Server alojado como parte de un clúster de grupos de disponibilidad Always On. AWS DMS ha mejorado la asistencia para las bases de datos de origen de SQL Server que están configuradas para ejecutarse en un clúster 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 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}'`
`"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 versión 3.4.7 y superiores de AWS DMS. Para obtener información sobre la configuración de la replicación continua en un SQL Server independiente, consulte Captura de cambios en los datos para la replicación continua desde SQL Server. 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 oyente del grupo de disponibilidad.
`ReadBackupOnly`	El uso de este atributo requiere privilegios de sysadmin. Si este atributo se establece en `Y`, durante la replicación continua AWS DMS solo lee los cambios de las copias de seguridad del registro de transacciones y no lee desde el archivo del 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 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 accede a la copia de seguridad de registro para capturar los cambios que faltan. Para minimizar la necesidad de acceder a la copia de seguridad de registro, AWS DMS evita las operaciones de truncado con uno de los siguientes métodos: `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (Iniciar transacciones en la base de datos): este 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 Microsoft Replication en la base de datos con fines diferentes a los de AWS DMS, debe elegir esta configuración. Al usar esta configuración, AWS DMS minimiza las lecturas de las copias de seguridad de los registros mediante la creación de una tabla llamada `awsdms_truncation_safeguard` y se evita el truncado de TLOG 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`. `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 `ready for truncation` con `sp_repldone`. Con esta configuración, AWS DMS no utiliza una transacción ficticia como ocurre con la configuración de `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (predeterminada). Solo puede usar esta configuración cuando la replicación de MS no se usa para ningún otro propósito que no sea AWS DMS en la base de datos de origen. Además, cuando se utiliza esta configuración, solo una tarea de AWS DMS puede acceder a la base de datos. Si necesita ejecutar tareas de AWS DMS en paralelo en la misma base de datos, utilice `RELY_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 de lectura de registro está en ejecución cuando se inicia la tarea, la tarea de AWS DMS 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 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 de AWS Database Migration Service.

Tipos de datos de SQL Server	Tipos de datos de AWS DMS
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
HORA	HORA
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 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 Configuració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.
BINARIO	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.
MARCA DE TIEMPO	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 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.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Uso de Oracle como origen

CDC para SQL Server como origen