Limitações de uso do SQL Server como origem Permissões do SQL Server Pré-requisitos para a utilização da CDC em andamento Métodos de compactação compatíveis Como trabalhar com grupos de disponibilidade AlwaysOn do SQL Server autogerenciados Configurações de endpoint Tipos de dados de origem no SQL Server

Utilizar um banco de dados Microsoft SQL Server como origem do AWS DMS

Migre dados de um ou mais bancos de dados Microsoft SQL Server utilizando o AWS DMS. Com um banco de dados SQL Server como origem, é possível migrar dados para outro banco de dados SQL Server ou para outros bancos de dados compatíveis com o AWS DMS.

Para obter informações sobre as versões do SQL Server compatíveis com o AWS DMS como origem, consulte Origens do AWS DMS.

O banco de dados de origem SQL Server pode ser instalado em qualquer computador na rede. É necessário ter uma conta do SQL Server com os privilégios de acesso ao banco de dados de origem adequados ao tipo de tarefa escolhido para utilizar com o AWS DMS. Para ter mais informações, consulte Permissões para tarefas do SQL Server.

O AWS DMS é compatível com a migração de dados de instâncias nomeadas do SQL Server. É possível utilizar a seguinte notação no nome do servidor ao criar o endpoint de origem.


IPAddress\InstanceName

Por exemplo, o seguinte é um nome do servidor do endpoint de origem correto. Aqui, a primeira parte do nome é o endereço IP do servidor, e a segunda parte é o nome da instância do SQL Server (neste exemplo, SQLTest).


10.0.0.25\SQLTest

Além disso, obtenha o número da porta que a instância chamada do SQL Server escuta e use-o para configurar o endpoint de origem do AWS DMS.

nota

A porta 1433 é o padrão para o Microsoft SQL Server. No entanto, as portas dinâmicas que são alteradas a cada vez que o SQL Server é iniciado e os números de portas estáticas específicos utilizados para conexão ao SQL Server por meio de um firewall também são utilizados com frequência. Portanto, saiba o número da porta real da instância nomeada do SQL Server ao criar o endpoint de origem do AWS DMS.

É possível utilizar SSL para criptografar conexões entre o endpoint do SQL Server e a instância de replicação. Para obter mais informações sobre como utilizar o SSL com um endpoint do SQL Server, consulte Usar SSL com o AWS Database Migration Service.

Você pode usar CDC para a migração contínua de um banco de dados do SQL Server. Para ter informações sobre como configurar o banco de dados do SQL Server de origem para CDC, consulte Capturar alterações de dados para replicação contínua no SQL Server.

Para obter mais detalhes sobre a utilização de bancos de dados de origem SQL Server e do AWS DMS, consulte os tópicos a seguir.

Tópicos

Limitações de uso do SQL Server como origem do AWS DMS
Permissões para tarefas do SQL Server
Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server
Métodos de compactação compatíveis com o SQL Server
Como trabalhar com grupos de disponibilidade AlwaysOn do SQL Server autogerenciados
Configurações de endpoint ao utilizar o SQL Server como origem do AWS DMS
Tipos de dados de origem no SQL Server
Capturar alterações de dados para replicação contínua no SQL Server

Limitações de uso do SQL Server como origem do AWS DMS

As seguintes limitações se aplicam ao utilizar um banco de dados SQL como origem do AWS DMS:

A propriedade identity de uma coluna não é migrada para uma coluna de banco de dados de destino.
O endpoint do SQL Server não é compatível com a utilização de tabelas com colunas esparsas.
A Autenticação do Windows não é compatível.
As alterações em campos computados em um SQL Server não são replicadas.
Tabelas temporais não são compatíveis.
A alternância de partições do SQL Server não é compatível.
Ao utilizar os utilitários WRITETEXT e UPDATETEXT, o AWS DMS não captura eventos ocorridos no banco de dados de origem.
O seguinte padrão da linguagem de manipulação de dados (DML) não é compatível:
```
SELECT * INTO new_table FROM existing_table
```
Ao utilizar o SQL Server como uma origem, a criptografia em nível de colunas não é compatível.
O AWS DMS não é compatível com auditorias em nível de servidor no SQL Server 2008 ou no SQL Server 2008 R2 como origens. Isso ocorre devido a um problema conhecido com o SQL Server 2008 e 2008 R2. Por exemplo, a execução do comando a seguir provoca uma falha no AWS DMS.
```
USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO
```
As colunas de geometria não são compatíveis no modo LOB completo ao utilizar o SQL Server como origem. Em vez disso, utilize o modo LOB limitado ou defina a configuração da tarefa InlineLobMaxSize para utilizar o modo LOB em linha.
Ao utilizar um banco de dados de origem Microsoft SQL Server em uma tarefa de replicação, as definições do publicador de replicação do SQL Server não serão removidas se você remover a tarefa. Um administrador de sistema do Microsoft SQL Server deve excluir essas definições do Microsoft SQL Server.
A migração de dados de visualizações vinculadas a esquemas e não vinculadas a esquemas é compatível somente com tarefas de carga máxima.
A renomeação de tabelas não é compatível com a utilização de sp_rename (por exemplo, sp_rename 'Sales.SalesRegion', 'SalesReg;))
A renomeação de colunas não é compatível com a utilização de sp_rename (por exemplo, sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)
O AWS DMS não é compatível com a alteração de processamento para configurar e desconfigurar valores padrão de colunas (utilizando a cláusula ALTER COLUMN SET DEFAULT com instruções ALTER TABLE).
O AWS DMS não é compatível com o processamento de alterações para definir a nulidade da coluna (utilizando a cláusula ALTER COLUMN [SET|DROP] NOT NULL com instruções ALTER TABLE).
Com o SQL Server 2012 e o SQL Server 2014, ao utilizar a replicação do DMS com grupos de disponibilidade, o banco de dados de distribuição não pode ser colocado em um grupo de disponibilidade. O SQL 2016 é compatível com a colocação do banco de dados de distribuição em um grupo de disponibilidade, exceto para bancos de dados de distribuição utilizados em topologias de replicação mesclada, bidirecional ou ponto a ponto.
Para tabelas particionadas, o AWS DMS não é compatível com diferentes configurações de compactação de dados para cada partição.
Ao inserir um valor em tipos de dados espaciais (GEOGRAPHY e GEOMETRY) no SQL Server, é possível ignorar a propriedade de identificador de sistema de referência espacial (SRID) ou especificar outro número. Ao replicar tabelas com tipos de dados espaciais, o AWS DMS substitui o SRID pelo SRID padrão (0 para GEOMETRY e 4326 para GEOGRAPHY).
Se o banco de dados não estiver configurado para MS-REPLICATION ou MS-CDC, ainda será possível capturar tabelas que não tenham uma chave primária, mas somente eventos INSERT/DELETE DML serão capturados. Os eventos UPDATE e TRUNCATE TABLE são ignorados.
Os índices Columnstore não são compatíveis.
Tabelas otimizadas para memória (utilizando OLTP na memória) não são compatíveis.
Ao replicar uma tabela com uma chave primária que consiste em várias colunas, a atualização das colunas de chave primária durante a carga máxima não é compatível.
A durabilidade atrasada não é compatível.
A configuração do endpoint readBackupOnly=Y (atributo de conexão adicional) não funciona em instâncias de origem do RDS para SQL Server devido à forma como o RDS executa backups.
O EXCLUSIVE_AUTOMATIC_TRUNCATION não funciona em instâncias de origem do Amazon RDS SQL Server porque os usuários do RDS não têm acesso para executar o procedimento armazenado do SQL Server, sp_repldone.
O AWS DMS não captura comandos truncados.
O AWS DMS não é compatível com a replicação de bancos de dados com a recuperação acelerada de banco de dados (ADR) ativada.
O AWS DMS não é compatível com a captura de instruções da linguagem de definição de dados (DDL) e da linguagem de manipulação de dados (DML) em uma única transação.
O AWS DMS não é compatível com a replicação de pacotes de aplicações de camada de dados (DACPAC).
As instruções UPDATE que envolvem chaves primárias ou índices exclusivos e atualizam várias linhas de dados podem causar conflitos ao aplicar alterações no banco de dados de destino. Isso pode acontecer, por exemplo, quando o banco de dados de destino aplica atualizações, como instruções INSERT e DELETE, em vez de uma única instrução UPDATE. Com o modo de aplicação otimizado em lote, a tabela pode ser ignorada. Com o modo de aplicação transacional, a operação UPDATE pode resultar em violações de restrições. Para evitar esse problema, recarregue a tabela relevante. Como alternativa, localize os registros problemáticos na tabela de controle Exceções da aplicação (dmslogs.awsdms_apply_exceptions) e edite-os manualmente no banco de dados de destino. Para ter mais informações, consulte Configurações de ajuste de processamento de alterações.
O AWS DMS não é compatível com a replicação de tabelas e esquemas, em que o nome inclui um caractere especial do seguinte conjunto.

\\ -- \n \" \b \r ' \t ;
O mascaramento de dados não é compatível. O AWS DMS migra dados mascarados sem mascará-los.
O AWS DMS replica até 32.767 tabelas com chaves primárias e até 1.000 colunas para cada tabela. Isso ocorre porque o AWS DMS cria um artigo de replicação do SQL Server para cada tabela replicada, e os artigos de replicação do SQL Server têm essas limitações.
Ao utilizar a captura de dados de alteração (CDC), defina todas as colunas que compõem um índice exclusivo como NOT NULL. Se esse requisito não for atendido, ocorrerá o erro 22838 do sistema do SQL Server.
É possível perder eventos se o SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo.

As seguintes limitações se aplicam ao acessar os logs de transação de backup:

Backups criptografados não são compatíveis.
Backups armazenados em um URL ou no Windows Azure não são compatíveis.
O AWS DMS não é compatível com o processamento direto de backups de logs de transações em nível de arquivo em pastas compartilhadas alternativas.
Para origens do Cloud SQL Server que não sejam o Amazon RDS para Microsoft SQL Server, o AWS DMS oferece aceita replicação contínua (CDC) somente com o log de transações ativo. Não é possível utilizar o log de backup com a CDC. É possível perder eventos se o SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo antes que o DMS consiga lê-los.
Para origens do Amazon RDS para Microsoft SQL Server, o AWS DMS versão 3.5.2 e anteriores aceitam replicação contínua (CDC) somente com o log de transações ativo, pois o DMS não pode acessar o log de backup com CDC. É possível perder eventos se o RDS para SQL Server armazená-los do log de transações ativo para o log de backup ou truncá-los no log de transações ativo antes que o DMS consiga lê-los. Essa limitação não se aplica ao AWS DMS na versão 3.5.3 e superiores.

Permissões para tarefas do SQL Server

Tópicos

Permissões para tarefas somente de carga máxima
Permissões para tarefas com replicação contínua

Permissões para tarefas somente de carga máxima

As permissões a seguir são necessárias para realizar tarefas somente de carga máxima. Observe que o AWS DMS não cria o login dms_user. Para obter informações sobre como criar um login para o SQL Server, consulte Criar um usuário de banco de dados com o 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;

Permissões para tarefas com replicação contínua

As instâncias autogerenciadas do SQL Server podem ser configuradas para replicação contínua usando o DMS com ou sem o uso do perfil sysadmin. Para instâncias do SQL Server nas quais você não pode conceder o perfil sysadmin, garanta que o usuário do DMS tenha os privilégios descritos a seguir.

Configurar permissões para replicação contínua a partir de um banco de dados autogerenciado do SQL Server

Crie uma nova conta do SQL Server com autenticação por senha utilizando o SQL Server Management Studio (SSMS) ou conforme descrito anteriormente em Permissões para tarefas somente de carga máxima, por exemplo self_managed_user.

Execute os seguintes 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;

Além das permissões anteriores, o usuário precisa de uma das seguintes:
- O usuário deve ser um membro do perfil sysadmin fixo do servidor
- Configurações e permissões conforme descrito em Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin ou Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin, dependendo da configuração da origem.

Configurar permissões para replicação contínua a partir de um banco de dados do SQL Server na nuvem

Uma instância do SQL Server hospedada na nuvem é uma instância em execução no Amazon RDS para Microsoft SQL Server, uma instância gerenciada do Azure SQL ou qualquer outra instância gerenciada do SQL Server na nuvem compatível com o DMS.

Crie uma nova conta do SQL Server com autenticação por senha utilizando o SQL Server Management Studio (SSMS) ou conforme descrito anteriormente em Permissões para tarefas somente de carga máxima, por exemplo rds_user.

Execute os seguintes comandos de concessão:


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;

Para origens do Amazon RDS para Microsoft SQL Server, a versão 3.5.3 e superiores do DMS são compatíveis com leitura de backups de logs de transações. Para garantir que o DMS possa acessar os backups de log, além do descrito acima, conceda privilégios de usuário master ou os seguintes privilégios em uma origem do RDS para SQL Server:


//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;

Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server

É possível utilizar a replicação contínua (captura de dados de alteração, ou CDC) para um banco de dados SQL Server autogerenciado on-premises ou no Amazon EC2, ou um banco de dados de nuvem, como o Amazon RDS ou uma instância gerenciada pelo Microsoft Azure SQL.

Os seguintes requisitos se aplicam especificamente ao utilizar a replicação contínua com um banco de dados SQL Server como uma origem para o AWS DMS:

O SQL Server deve ser configurado para fazer backups completos e um backup deve ser feito antes do início da replicação dos dados.
O modelo de recuperação deve ser definido como Bulk-logged ou Full.
O backup do SQL Server para múltiplos discos não é compatível. Se o backup for configurado para gravar o backup do banco de dados em vários arquivos e em diferentes discos, o AWS DMS não poderá ler os dados, e a tarefa do AWS DMS falhará.
Para origens do SQL Server autogerenciadas, as definições do SQL Server Replication Publisher para a origem utilizada em uma tarefa de CDC do DMS não são removidas quando você remove a tarefa. Um administrador de sistema do SQL Server deve excluir essas definições do SQL Server para origens autogerenciadas.
Durante a CDC, o AWS DMS precisa pesquisar os backups dos logs de transações do SQL Server para ler as alterações. O AWS DMS não é compatível com backups de logs de transações do SQL Server que foram criados utilizando um software de backup de terceiros que não estão em formato nativo. Para compatibilidade com backups de logs de transações que estão em formato nativo e foram criados utilizando software de backup de terceiros, adicione o atributo de conexão use3rdPartyBackupDevice=Y ao endpoint de origem.
Para origens autogerenciadas do SQL Server, lembre-se de que o SQL Server não captura alterações em tabelas recém-criadas até que elas sejam publicadas. Quando uma tabela é adicionada a uma origem do SQL Server, o AWS DMS gerencia a sua publicação. No entanto, esse processo pode demorar alguns minutos. As operações feitas durante esse intervalo nas tabelas recentemente criadas não são capturadas ou replicadas no destino.
A captura de dados de alteração do AWS DMS exige que o registro em log de transações completo esteja ativado no SQL Server. Para ativar o registro em log de transações completo no SQL Server, ative MS-REPLICATION ou CHANGE DATA CAPTURE (CDC).
As entradas tlog do SQL Server não serão marcadas para reutilização até que o trabalho de captura de MS CDC processe essas alterações.
As operações de CDC não são compatíveis com tabelas com otimização de memória. Essa limitação se aplica ao SQL Server 2014 (quando o recurso foi introduzido pela primeira vez) e posterior.
A captura de dados de alteração do AWS DMS requer, por padrão, um banco de dados de distribuição no Amazon EC2 ou SQL Server on-premises como origem. Portanto, ative o distribuidor ao configurar a replicação de MS para tabelas com chaves primárias.

Métodos de compactação compatíveis com o SQL Server

Observe o seguinte sobre os métodos de compactação compatíveis com o SQL Server no AWS DMS:

O AWS DMS é compatível com a compactação de linha/página no SQL Server versão 2008 e posterior.
O AWS DMS não é compatível com o formato de armazenamento Vardecimal.
O AWS DMS não é compatível com a compactação de colunas esparsas e de estruturas colunares.

Como trabalhar com grupos de disponibilidade AlwaysOn do SQL Server autogerenciados

A disponibilidade dos grupos de disponibilidade AlwaysOn do SQL Server fornece alta disponibilidade e recuperação de desastres como alternativa ao espelhamento do banco de dados no nível empresarial.

No AWS DMS, é possível migrar as alterações de uma única réplica primária ou secundária do grupo de disponibilidade.

Como trabalhar com a réplica primária do grupo de disponibilidade

Para utilizar o grupo de disponibilidade como origem no AWS DMS, faça o seguinte:

Ative a opção de distribuição em todas as instâncias do SQL Server em suas réplicas de disponibilidade. Para ter mais informações, consulte Configurar a replicação contínua em um SQL Server autogerenciado.
No console do AWS DMS, abra as configurações de banco de dados de origem do SQL Server. Em Nome do servidor, especifique o nome do serviço de nomes de domínio (DNS) ou o endereço IP configurado para o receptor do grupo de disponibilidade.

Ao iniciar uma tarefa do AWS DMS pela primeira vez, ela pode levar mais tempo do que o normal para iniciar. Essa lentidão ocorre porque a criação dos artigos da tabela está sendo duplicada pelo servidor de grupos de disponibilidade.

Como trabalhar com uma réplica do grupo de disponibilidade secundário

Para utilizar o grupo de disponibilidade secundário como origem no AWS DMS, faça o seguinte:

Para se conectar às réplicas individuais, utilize as mesmas credenciais utilizadas pelo usuário do endpoint de origem do AWS DMS.
Verifique se a instância de replicação do AWS DMS pode resolver os nomes DNS de todas as réplicas existentes e conectar-se a elas. É possível utilizar a consulta SQL a seguir para obter os nomes DNS de todas as 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>';
```
Ao criar o endpoint de origem, especifique o nome DNS do receptor do grupo de disponibilidade do Nome do servidor do endpoint ou o Endereço do servidor do segredo do endpoint. Para obter mais informações sobre receptores de grupos de disponibilidade, consulte O que é um receptor de grupos de disponibilidade? na documentação do SQL Server.

É possível utilizar um servidor DNS público ou um servidor DNS on-premises para resolver o receptor do grupo de disponibilidade, a réplica primária e as réplicas secundárias. Para utilizar um servidor DNS on-premises, configure o Amazon Route 53 Resolver. Para ter mais informações, consulte Utilização do seu próprio servidor de nomes on-premises.

Adicione os seguintes atributos de conexão adicional ao endpoint de origem.

Atributos de conexão adicional	Valor	Observações
`applicationIntent`	`ReadOnly`	Sem essa configuração de ODBC, a tarefa de replicação é roteada para a réplica primária do grupo de disponibilidade. Para obter mais informações, consulte Compatibilidade do SQL Server Native Client com alta disponibilidade e recuperação de desastres na documentação do SQL Server.
`multiSubnetFailover`	`yes`	Para obter mais informações, consulte Compatibilidade do SQL Server Native Client com alta disponibilidade e recuperação de desastres na documentação do SQL Server.
`alwaysOnSharedSynchedBackupIsEnabled`	`false`	Para ter mais informações, consulte Configurações de endpoint ao utilizar o SQL Server como origem do AWS DMS.
`activateSafeguard`	`false`	Para obter mais informações, consulte Limitações a seguir.
`setUpMsCdcForTables`	`false`	Para obter mais informações, consulte Limitações a seguir.

Ative a opção de distribuição em todas as réplicas no grupo de disponibilidade. Adicione todos os nós à lista de distribuidores. Para ter mais informações, consulte Como configurar a distribuição.
Execute a consulta a seguir na réplica primária de leitura e gravação para ativar a publicação do banco de dados. Você executa essa consulta somente uma vez para o banco de dados.
```
sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';
```

Limitações

Veja a seguir as limitações ao trabalhar com uma réplica secundária do grupo de disponibilidade:

O AWS DMS não é compatível com o Safeguard ao utilizar uma réplica somente leitura do grupo de disponibilidade como origem. Para ter mais informações, consulte Configurações de endpoint ao utilizar o SQL Server como origem do AWS DMS.
O AWS DMS não é compatível com o atributo de conexão adicional setUpMsCdcForTables ao utilizar uma réplica somente leitura do grupo de disponibilidade como origem. Para ter mais informações, consulte Configurações de endpoint ao utilizar o SQL Server como origem do AWS DMS.
O AWS DMS pode utilizar uma réplica secundária autogerenciada do grupo de disponibilidade como origem do banco de dados para replicação contínua (captura de dados de alteração ou CDC) desde a versão 3.4.7. As réplicas de leitura do Cloud SQL Server Multi-AZ não são compatíveis. Se você utilizar versões anteriores do AWS DMS, utilize a réplica primária do grupo de disponibilidade como o banco de dados de origem da CDC.

Failover para outros nós

Se você definir o atributo de conexão adicional ApplicationIntent para o endpoint como ReadOnly, a tarefa do AWS DMS se conectará ao nó somente leitura com a prioridade de roteamento somente leitura mais alta. Ele executa failover para outros nós somente leitura no grupo de disponibilidade quando o nó somente leitura de prioridade mais alta não está disponível. Se você não definir ApplicationIntent, a tarefa do AWS DMS só se conectará ao nó primário (leitura/gravação) no grupo de disponibilidade.

Configurações de endpoint ao utilizar o SQL Server como origem do AWS DMS

É possível utilizar as configurações de endpoint para configurar a origem do SQL Server de forma semelhante à utilização de atributos de conexão adicional. Você especifica as configurações ao criar o endpoint de origem utilizando o console do AWS DMS ou o comando create-endpoint na AWS CLI, com a sintaxe --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' do JSON.

A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o SQL Server como origem.

Nome	Descrição
`ActivateSafeguard`	Esse atributo ativa ou desativa o Safeguard. Para obter mais informações sobre o Safeguard, consulte a `SafeguardPolicy` a seguir: Valor padrão: `true` Valores válidos: {`false`, `true`} Exemplo: `'{"ActivateSafeguard": true}'`
`AlwaysOnSharedSynchedBackupIsEnabled`	Esse atributo ajusta o comportamento do AWS DMS ao migrar de um banco de dados de origem SQL Server hospedado como parte de um cluster de grupo de disponibilidade Always On. O AWS DMS aprimorou a compatibilidade com dados de origem SQL Server configurados para serem executados em um cluster Always On. Nesse caso, AWS DMS tenta rastrear se os backups de transações estão acontecendo em nós no cluster Always On diferentes do nó em que a instância do banco de dados de origem está hospedada. Na inicialização da tarefa de migração, o AWS DMS tenta se conectar a cada nó no cluster, mas falha se não puder se conectar a nenhum dos nós. Se você precisar do AWS DMS para pesquisar todos os nós no cluster Always On para backups de transações, defina esse atributo como `false`. Valor padrão: `true` Valores válidos: `true` ou `false` Exemplo: `'{"AlwaysOnSharedSynchedBackupIsEnabled": false}'`
`"ApplicationIntent": "readonly"`	Essa configuração de atributo de driver ODBC faz com que o SQL Server roteie a tarefa de replicação para o nó somente leitura de prioridade mais alta. Sem essa configuração, o SQL Server roteia a tarefa de replicação para o nó primário de leitura e gravação.
`EnableNonSysadminWrapper`	Utilize essa configuração de endpoint ao configurar a replicação contínua em um servidor SQL autônomo sem um usuário sysadmin. Esse parâmetro é compatível com o AWS DMS versão 3.4.7 e superior. Para obter informações sobre como configurar a replicação contínua em um SQL Server autônomo, consulte Capturar alterações de dados para replicação contínua no SQL Server. Valor padrão: `false` Valores válidos: `true`, `false` Exemplo: `'{"EnableNonSysadminWrapper": true}'`
`ExecuteTimeout`	Utilize esse atributo de conexão adicional (ECA) para definir o tempo limite da instrução do cliente para a instância do SQL Server, em segundos. O valor padrão é de 60 segundos. Exemplo: `'{"ExecuteTimeout": 100}'`
`FatalOnSimpleModel`	Quando definida como `true`, essa configuração gera um erro fatal quando o modelo de recuperação de banco de dados SQL Server está definido como `simple`. Valor padrão: `false` Valores válidos: `true` ou `false` Exemplo: `'{"FatalOnSimpleModel": true}'`
`ForceLobLookup`	Força a pesquisa de LOB em LOB em linha. Valor padrão: `false` Valores válidos: `true`, `false` Exemplo: `'{"ForceLobLookup": false}'`
`"MultiSubnetFailover": "Yes"`	Esse atributo de driver ODBC ajuda o DMS a se conectar ao novo primário no caso de um failover do grupo de disponibilidade. Esse atributo foi criado para situações em que a conexão é interrompida ou o endereço IP do receptor está incorreto. Nessas situações, o AWS DMS tenta se conectar a todos os endereços IP associados ao receptor do Grupo de Disponibilidade.
`ReadBackupOnly`	A utilização desse atributo requer privilégios de sysadmin. Quando esse atributo for definido como `Y` durante uma replicação contínua, o AWS DMS lerá somente as alterações dos backups dos logs de transações e não lerá o arquivo de log de transações ativas durante a replicação contínua. A definição desse parâmetro como `Y` permite controlar o crescimento do log de transações ativas durante tarefas de carga máxima e de replicação contínua. No entanto, ele pode adicionar alguma latência de origem à replicação contínua. Valores válidos: `N` ou `Y`. O padrão é `N`. Exemplo: `'{"ReadBackupOnly": Y}'` Observação: esse parâmetro não funciona nas instâncias de origem do Amazon RDS SQL Server devido à maneira como o RDS executa backups.
`SafeguardPolicy`	Para o melhor desempenho, o AWS DMS tenta capturar todas as alterações do log de transações ativas (TLOG) que não foram lidas. Contudo, às vezes devido a um truncamento, o TLOG ativo talvez não contenha todas as alterações não lidas. Quando isso ocorre, o AWS DMS acessa o backup do log para capturar as alterações ausentes. Para minimizar a necessidade de acessar o log de backup, o AWS DMS evita o truncamento utilizando um dos seguintes métodos: `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (iniciar as transações no banco de dados): este é o padrão do AWS DMS. Ao utilizar essa configuração, o AWS DMS requer que o agente de leitura do SQL Server esteja em execução, para que o AWS DMS possa transferir as transações marcadas para replicação no TLOG ativo. Observe que, se o agente de leitura de log não estiver em execução, o TLOG ativo poderá ficar cheio, fazendo com que o banco de dados de origem mude para o modo somente leitura até que você possa resolver o problema. Se você precisar ativar a Microsoft Replication no banco de dados para outra finalidade além do AWS DMS, escolha essa configuração. Ao utilizar essa configuração, o AWS DMS minimiza as leituras de backup de log criando uma tabela chamada `awsdms_truncation_safeguard` e evita o truncamento do TLOG imitando uma transação aberta no banco de dados. Isso impede que o banco de dados trunque eventos e os transfira para o log de backup por cinco minutos (por padrão). Verifique se a tabela não está incluída em nenhum plano de manutenção, pois isso pode causar falhas no trabalho de manutenção. É possível excluir a tabela com segurança se não houver tarefas configuradas com a opção de banco de dados `Start Transactions`. `EXCLUSIVE_AUTOMATIC_TRUNCATION` (utiliza `sp_repldone` exclusivamente com uma única tarefa): ao utilizar essa configuração, o AWS DMS tem controle total do processo do agente de replicação que marca as entradas do log como `ready for truncation` utilizando `sp_repldone`. Com essa configuração, o AWS DMS não utiliza uma transação fictícia como na configuração `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (padrão). Você só pode utilizar essa configuração quando a MS Replication não é utilizada para nenhuma outra finalidade diferente do AWS DMS no banco de dados de origem. Além disso, ao utilizar essa configuração, apenas uma tarefa do AWS DMS pode acessar o banco de dados. Se for necessário executar tarefas do AWS DMS em paralelo em um mesmo banco de dados, utilize `RELY_ON_SQL_SERVER_REPLICATION_AGENT`. Essa configuração requer que o agente de leitura de log seja interrompido no banco de dados. Se o agente de leitura de log estiver em execução quando a tarefa for iniciada, a tarefa do AWS DMS forçará a sua interrupção. Como alternativa, é possível interromper o agente de leitura de log manualmente antes de iniciar a tarefa. Ao utilizar esse método com a MS-CDC, interrompa e desative os trabalhos de Captura da MS-CDC e de Limpeza da MS-CDC. Não é possível utilizar essa configuração quando o trabalho de Migração do Microsoft SQL Server for executado em uma máquina remota do Distribuidor, porque o AWS DMS não tem acesso à máquina remota. `EXCLUSIVE_AUTOMATIC_TRUNCATION` não funciona nas instâncias de origem do Amazon RDS para SQL Server porque os usuários do Amazon RDS não têm acesso para executar o procedimento armazenado `sp_repldone`. Se você definir `SafeguardPolicy` como `EXCLUSIVE_AUTOMATIC_TRUNCATION` sem utilizar o perfil sysadmin, deverá conceder permissões nos objetos `dbo.syscategories` e `dbo.sysjobs` ao usuário `dmsuser`. Valor padrão: `RELY_ON_SQL_SERVER_REPLICATION_AGENT` Valores válidos: {`EXCLUSIVE_AUTOMATIC_TRUNCATION`, `RELY_ON_SQL_SERVER_REPLICATION_AGENT`} Exemplo: `'{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'`
`SetUpMsCdcForTables`	Esse atributo ativa a MS-CDC para o banco de dados de origem e para tabelas no mapeamento de tarefa que não têm a MS Replication ativada. A definição desse valor como `true` executa o procedimento armazenado `sp_cdc_enable_db` no banco de dados de origem e o procedimento armazenado `sp_cdc_enable_table` em cada tabela na tarefa que não tem a MS Replication ativada no banco de dados de origem. Para obter mais informações sobre como ativar a distribuição, consulte Configurar a replicação contínua em um SQL Server autogerenciado. Valores válidos: {`true`, `false`} Exemplo: `'{"SetUpMsCdcForTables": true}'`
`TlogAccessMode`	Indica o modo utilizado para buscar dados da CDC. Valor padrão: `PreferTlog` Valores válidos: `BackupOnly`, `PreferBackup`, `PreferTlog`, `TlogOnly` Exemplo: `'{"TlogAccessMode": "PreferTlog"}'`
`Use3rdPartyBackupDevice`	Quando esse atributo for definido como `Y`, o AWS DMS processará backups de logs de transações de terceiros se eles forem criados no formato nativo.

Tipos de dados de origem no SQL Server

A funcionalidade de migração de dados que utiliza o SQL Server como origem no AWS DMS é compatível com a maioria dos tipos de dados do SQL Server. A tabela a seguir mostra os tipos de dados de origem SQL Server compatíveis com o AWS DMS e o mapeamento padrão relativo aos tipos de dados do AWS DMS.

Para obter informações sobre como visualizar o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que você está usando.

Para obter mais informações sobre os tipos de dados do AWS DMS, consulte Tipos de dados do AWS Database Migration Service.

Tipos de dados do SQL Server	Tipos de dados do 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 e superior)	DATETIME
SMALLDATETIME	DATETIME
DATA	DATA
TIME	TIME
DATETIMEOFFSET	WSTRING
CHAR	STRING
VARCHAR	STRING
VARCHAR (máximo)	CLOB TEXT Para usar esse tipo de dados no AWS DMS, é necessário habilitar o uso de tipos de dados CLOB em uma tarefa específica. Em tabelas do SQL Server, o AWS DMS atualiza as colunas LOB no destino mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante uma captura de dados de alteração (CDC), o AWS DMS oferece suporte aos tipos de dados CLOB somente em tabelas que possuem uma chave primária.
NCHAR	WSTRING
NVARCHAR (tamanho)	WSTRING
NVARCHAR (máximo)	NCLOB NTEXT Para utilizar esse tipo de dados com o AWS DMS, ative a utilização de SupportLobs em uma tarefa específica. Para obter mais informações sobre como ativar a compatibilidade com o LOB, consulte Definir o suporte a LOB para bancos de dados de origem em uma tarefa do AWS DMS. Em tabelas do SQL Server, o AWS DMS atualiza as colunas LOB no destino mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante uma captura de dados de alteração (CDC), o AWS DMS oferece suporte aos tipos de dados CLOB somente em tabelas que possuem uma chave primária.
BINARY	BYTES
VARBINARY	BYTES
VARBINARY (máximo)	BLOB IMAGE Em tabelas do SQL Server, o AWS DMS atualiza as colunas LOB no destino mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Para utilizar esse tipo de dados com o AWS DMS, ative a utilização de tipos de dados BLOB em uma tarefa específica. O AWS DMS é compatível com os tipos de dados BLOB somente em tabelas que possuem uma chave primária.
TIMESTAMP	BYTES
UNIQUEIDENTIFIER	STRING
HIERARCHYID	Utilize o tipo HIERARCHYID ao replicar para um endpoint de destino do SQL Server. Utilize WSTRING (250) ao replicar para os demais endpoints de destino.
XML	NCLOB Em tabelas do SQL Server, o AWS DMS atualiza as colunas LOB no destino mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Para usar esse tipo de dados no AWS DMS, é necessário habilitar o uso de tipos de dados NCLOB em uma tarefa específica. Durante uma captura de dados de alteração (CDC), o AWS DMS oferece suporte aos tipos de dados NCLOB somente em tabelas que incluem uma chave primária.
GEOMETRY	Utilize o tipo GEOMETRY ao replicar para endpoints de destino compatíveis com esse tipo de dados. Use o tipo CLOB ao replicar para endpoints de destino que não são compatíveis com esse tipo de dados.
GEOGRAPHY	Utilize o tipo GEOGRAPHY ao replicar para endpoints de destino compatíveis com esse tipo de dados. Use o tipo CLOB ao replicar para endpoints de destino que não são compatíveis com esse tipo de dados.

O AWS DMS não é compatível com tabelas que incluem campos com os tipos de dados a seguir.

CURSOR
SQL_VARIANT
TABLE

nota

A existência de suporte para um tipo de dados definido pelo usuário vai depender do tipo base utilizado. Por exemplo, um tipo de dados definido pelo usuário baseado no tipo DATETIME é tratado como o tipo de dados DATETIME.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Usar o Oracle como origem

CDC para SQL Server como origem