As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS
<a name="CHAP_Source.SQLServer"></a>

Migre dados de um ou vários bancos de dados do Microsoft SQL Server usando o. AWS DMS Com um banco de dados do SQL Server como fonte, você pode migrar dados para outro banco de dados do SQL Server ou para um dos outros bancos de dados AWS DMS compatíveis. 

Para obter informações sobre as versões do SQL Server que oferecem AWS DMS suporte como fonte, consulte[Fontes para AWS DMS](CHAP_Introduction.Sources.md).

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 obter mais informações, consulte [Permissões para tarefas do SQL Server](#CHAP_Source.SQLServer.Permissions).

AWS DMS oferece suporte à 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 sua instância nomeada do SQL Server escuta e use-o para configurar seu endpoint de AWS DMS origem. 

**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. Então, você quer saber o número real da porta da sua instância nomeada do SQL Server ao criar o endpoint de AWS DMS origem.

É 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 [Usando SSL com AWS Database Migration Service](CHAP_Security.SSL.md).

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](CHAP_Source.SQLServer.CDC.md).

Para obter detalhes adicionais sobre como trabalhar com bancos de dados de origem do SQL Server e AWS DMS, consulte o seguinte.

**Topics**
+ [Limitações no uso do SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.Limitations)
+ [Permissões para tarefas do SQL Server](#CHAP_Source.SQLServer.Permissions)
+ [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](#CHAP_Source.SQLServer.Prerequisites)
+ [Métodos de compactação compatíveis com o SQL Server](#CHAP_Source.SQLServer.Compression)
+ [Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server](#CHAP_Source.SQLServer.AlwaysOn)
+ [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib)
+ [Tipos de dados de origem no SQL Server](#CHAP_Source.SQLServer.DataTypes)
+ [Capturar alterações de dados para replicação contínua no SQL Server](CHAP_Source.SQLServer.CDC.md)

## Limitações no uso do SQL Server como fonte para AWS DMS
<a name="CHAP_Source.SQLServer.Limitations"></a>

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 usar os utilitários WRITETEXT e UPDATETEXT, AWS DMS não captura eventos aplicados 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.
+ AWS DMS não oferece suporte a auditorias em nível de servidor no SQL Server 2008 ou no SQL Server 2008 R2 como fontes. Isso ocorre devido a um problema conhecido com o SQL Server 2008 e 2008 R2. Por exemplo, a execução do comando a seguir causa AWS DMS a falha.

  ```
  USE [master]
  GO 
  ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
  GO
  ```
+ Não é possível usar geometria e colunas de geometria 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 non-schema-bound visualizações e vinculados a esquemas é suportada somente para tarefas de carga total. 
+ A renomeação de tabelas não é compatível com a utilização de sp\$1rename (por exemplo, `sp_rename 'Sales.SalesRegion', 'SalesReg;)`)
+ A renomeação de colunas não é compatível com a utilização de sp\$1rename (por exemplo, `sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';`)
+ AWS DMS não oferece suporte ao processamento de alterações para definir e desdefinir valores padrão da coluna (usando a `ALTER COLUMN SET DEFAULT` cláusula com `ALTER TABLE` instruções).
+ AWS DMS não oferece suporte ao processamento de alterações para definir a nulidade da coluna (usando a `ALTER COLUMN [SET|DROP] NOT NULL` cláusula 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 oferece suporte à colocação do banco de dados de distribuição em um grupo de disponibilidade, exceto para bancos de dados de distribuição usados em topologias de mesclagem, bidirecional ou peer-to-peer replicação.
+ Para tabelas particionadas, AWS DMS não oferece suporte a 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, AWS DMS substitui o SRID pelo SRID padrão (0 para GEOMETRIA e 4326 para GEOGRAFIA).
+ Se seu banco de dados não estiver configurado para MS-REPLICATION ou MS-CDC, você ainda poderá capturar tabelas que não tenham uma chave primária, mas somente eventos DML serão capturados. INSERT/DELETE 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=true` (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`.
+ AWS DMS não captura comandos truncados.
+ AWS DMS não oferece suporte à replicação de bancos de dados com a recuperação acelerada de banco de dados (ADR) ativada.
+ AWS DMS não suporta a captura de instruções de linguagem de definição de dados (DDL) e linguagem de manipulação de dados (DML) em uma única transação.
+ AWS DMS não oferece suporte à replicação de pacotes de aplicativos 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 obter mais informações, consulte [Configurações de ajuste de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ AWS DMS não suporta a replicação de tabelas e esquemas, em que o nome inclui um caractere especial do conjunto a seguir.

  `\\ -- \n \" \b \r ' \t ;` 
+ O mascaramento de dados não é suportado. AWS DMS migra dados mascarados sem mascarar.
+ AWS DMS replica até 32.767 tabelas com chaves primárias e até 1.000 colunas para cada tabela. Isso ocorre porque 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.
+ AWS DMS não suporta o processamento direto de backups de registros de transações no nível do arquivo a partir de pastas compartilhadas alternativas.
+ Para fontes do Cloud SQL Server que não sejam Amazon RDS para Microsoft SQL Server AWS DMS , o Amazon RDS for Microsoft SQL Server oferece suporte à 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 fontes do Amazon RDS for Microsoft SQL Server AWS DMS , a versão 3.5.2 e versões anteriores oferecem suporte à replicação contínua (CDC) somente com o log de transações ativo, porque o DMS não pode acessar o log de backup com o 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 à AWS DMS versão 3.5.3 e superior.
+ AWS DMS não oferece suporte ao CDC para Amazon RDS Proxy for SQL Server como fonte.
+ Se a origem do SQL Server ficar indisponível durante uma tarefa de carga máxima, o AWS DMS poderá marcar a tarefa como concluída após várias tentativas de reconexão, mesmo que a migração de dados permaneça incompleta. Nesse cenário, as tabelas de destino contêm somente os registros migrados antes da perda da conexão, possivelmente criando inconsistências de dados entre os sistemas de origem e de destino. Para garantir a integridade dos dados, você deve reiniciar totalmente a tarefa de carga máxima ou recarregar as tabelas específicas afetadas pela interrupção da conexão.

## Permissões para tarefas do SQL Server
<a name="CHAP_Source.SQLServer.Permissions"></a>

**Topics**
+ [Permissões para tarefas somente de carga máxima](#CHAP_Source.SQLServer.Permissions.FullLoad)
+ [Permissões para tarefas com replicação contínua](#CHAP_Source.SQLServer.Permissions.Ongoing)

### Permissões para tarefas somente de carga máxima
<a name="CHAP_Source.SQLServer.Permissions.FullLoad"></a>

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 ter informações sobre como criar um login para o SQL Server, consulte o tópico [Create a database user](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-user?view=sql-server-ver16) na *documentação da Microsoft*.

```
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
<a name="CHAP_Source.SQLServer.Permissions.Ongoing"></a>

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**

1. 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](#CHAP_Source.SQLServer.Permissions.FullLoad), por exemplo `self_managed_user`.

1. 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;
   ```

1. 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](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.ag) ou [Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin](CHAP_Source.SQLServer.CDC.md#CHAP_SupportScripts.SQLServer.standalone), 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
<a name="CHAP_Source.SQLServer.Permissions.Cloud"></a>

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](#CHAP_Source.SQLServer.Permissions.FullLoad), por exemplo `rds_user`.

Execute os seguintes comandos de concessão:

```
GRANT VIEW SERVER STATE 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:

```
USE msdb;
    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;
    
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 as instâncias gerenciadas de SQL do Amazon Azure, conceda os seguintes privilégios:

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

## Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server
<a name="CHAP_Source.SQLServer.Prerequisites"></a>

É 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 estiver definido para gravar o backup do banco de dados em vários arquivos em discos diferentes, não será AWS DMS possível ler os dados e a AWS DMS tarefa 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 o CDC, é AWS DMS necessário consultar os backups do log de transações do SQL Server para ler as alterações. AWS DMS não oferece suporte a backups de log de transações do SQL Server criados usando software de backup de terceiros que *não estejam* 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 as tabelas são adicionadas a uma fonte do SQL Server, AWS DMS gerencia a criação da 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. 
+ AWS DMS a captura de dados de alteração exige que o registro completo de transações seja 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.
+ AWS DMS a captura de dados de alteração requer, por padrão, um banco de dados de distribuição no Amazon EC2 ou no servidor SQL On-Prem como fonte. 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
<a name="CHAP_Source.SQLServer.Compression"></a>

Observe o seguinte sobre os métodos de compactação compatíveis com o SQL Server no AWS DMS:
+ AWS DMS oferece suporte à Row/Page compactação no SQL Server versão 2008 e posterior.
+ AWS DMS não suporta o formato de armazenamento Vardecimal.
+ AWS DMS não suporta colunas esparsas e compressão de estrutura colunar.

## Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server
<a name="CHAP_Source.SQLServer.AlwaysOn"></a>

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. 

Em AWS DMS, você pode 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Primary"></a>

 

**Para usar o grupo de disponibilidade principal como fonte em AWS DMS, faça o seguinte:**

1. Ative a opção de distribuição em todas as instâncias do SQL Server em suas réplicas de disponibilidade. Para obter mais informações, consulte [Configurar a replicação contínua em um SQL Server autogerenciado](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC).

1. No AWS DMS console, abra as configurações do 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. 

Quando você inicia uma AWS DMS tarefa pela primeira vez, ela pode levar mais tempo do que o normal para ser iniciada. 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary"></a>

**Para usar um grupo de disponibilidade secundário como origem em AWS DMS, faça o seguinte:**

1. Use as mesmas credenciais usadas pelo usuário do endpoint de AWS DMS origem para se conectar a réplicas individuais.

1. Certifique-se de que sua instância de AWS DMS replicação possa resolver os nomes DNS de todas as réplicas existentes e se conectar 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>';
   ```

1. 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?](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15) 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 obter mais informações, consulte [Utilização do seu próprio servidor de nomes on-premises](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver).

1. Adicione os seguintes atributos de conexão adicional ao endpoint de origem.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.SQLServer.html)

1. 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 obter mais informações, consulte [Como configurar a distribuição](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.CDC.MSCDC.Setup).

1. 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
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.limitations"></a>

Veja a seguir as limitações ao trabalhar com uma réplica secundária do grupo de disponibilidade:
+ AWS DMS não oferece suporte ao Safeguard ao usar uma réplica de grupo de disponibilidade somente para leitura como fonte. Para obter mais informações, consulte [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS não oferece suporte ao atributo de conexão `setUpMsCdcForTables` extra ao usar uma réplica de grupo de disponibilidade somente para leitura como fonte. Para obter mais informações, consulte [Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS](#CHAP_Source.SQLServer.ConnectionAttrib).
+ AWS DMS pode usar uma réplica autogerenciada do grupo de disponibilidade secundário como banco de dados de origem para replicação contínua (captura de dados de alteração ou CDC) a partir da versão 3.4.7. As réplicas de leitura do Cloud SQL Server Multi-AZ não são compatíveis. Se você usa versões anteriores do AWS DMS, certifique-se de usar a réplica principal do grupo de disponibilidade como banco de dados de origem para o CDC.

#### Failover para outros nós
<a name="CHAP_Source.SQLServer.AlwaysOn.Secondary.failover"></a>

Se você definir o atributo de conexão `ApplicationIntent` extra para seu endpoint`ReadOnly`, sua AWS DMS tarefa se conectará ao nó somente leitura com a maior prioridade de roteamento somente para leitura. 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`, sua AWS DMS tarefa se conectará somente ao nó primário (leitura/gravação) em seu grupo de disponibilidade.

## Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS
<a name="CHAP_Source.SQLServer.ConnectionAttrib"></a>

É 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 usando o AWS DMS console ou usando o `create-endpoint` comando no [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), com a sintaxe `--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}'` JSON.

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

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_Source.SQLServer.html)

## Tipos de dados de origem no SQL Server
<a name="CHAP_Source.SQLServer.DataTypes"></a>

A migração de dados que usa o SQL Server como fonte de AWS DMS suporte à maioria dos tipos de dados do SQL Server. A tabela a seguir mostra os tipos de dados de origem do SQL Server que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados.

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 informações adicionais sobre AWS DMS os tipos de dados, consulte[Tipos de dados do AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  Tipos de dados do SQL Server  |  AWS DMS tipos de dados  | 
| --- | --- | 
|  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 versões posteriores)  |  DATETIME  | 
|  SMALLDATETIME  |  DATETIME  | 
|  DATE  |  DATE  | 
|  TIME  |  TIME  | 
|  DATETIMEOFFSET  |  WSTRING  | 
|  CHAR  |  STRING  | 
|  VARCHAR  |  STRING  | 
|  VARCHAR (máximo)  |  CLOB TEXT Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de tipos de dados CLOB para uma tarefa específica. Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante o CDC, AWS DMS suporta tipos de dados CLOB somente em tabelas que incluem uma chave primária.  | 
|  NCHAR  |  WSTRING  | 
|  NVARCHAR (tamanho)  |  WSTRING  | 
|  NVARCHAR (máximo)  |  NCLOB NTEXT Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de SupportLobs para uma tarefa específica. Para obter mais informações sobre como ativar a compatibilidade com o LOB, consulte [Configurando o suporte LOB para bancos de dados de origem em uma tarefa AWS DMS](CHAP_Tasks.LOBSupport.md).  Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Durante o CDC, AWS DMS suporta tipos de dados CLOB somente em tabelas que incluem uma chave primária.  | 
|  BINARY  |  BYTES  | 
|  VARBINARY  |  BYTES  | 
|  VARBINARY (máximo)  |  BLOB IMAGE Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso de tipos de dados BLOB para uma tarefa específica. AWS DMS suporta tipos de dados BLOB somente em tabelas que incluem 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 Para tabelas do SQL Server, AWS DMS atualiza as colunas LOB no destino até mesmo para instruções UPDATE que não alteram o valor da coluna LOB no SQL Server. Para usar esse tipo de dados com AWS DMS, você deve habilitar o uso dos tipos de dados NCLOB para uma tarefa específica. Durante o CDC, AWS DMS suporta 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.  | 

AWS DMS não oferece suporte a tabelas que incluam campos com os seguintes tipos de dados. 
+ CURSOR
+ SQL\$1VARIANT
+ 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.

# Capturar alterações de dados para replicação contínua no SQL Server
<a name="CHAP_Source.SQLServer.CDC"></a>

Este tópico descreve como configurar a replicação de CDC em uma origem do SQL Server.

**Topics**
+ [Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2](#CHAP_Source.SQLServer.CDC.Selfmanaged)
+ [Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem](#CHAP_Source.SQLServer.Configuration)

## Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2
<a name="CHAP_Source.SQLServer.CDC.Selfmanaged"></a>

Para capturar as alterações de um banco de dados de origem do Microsoft SQL Server, verifique se o banco de dados está configurado para backups completos. Configure o banco de dados no modo de recuperação total ou no modo de registro em log em massa.

Para uma fonte autogerenciada do SQL Server, AWS DMS use o seguinte:

**Replicação de MS**  
Para capturar alterações em tabelas com chaves primárias. Você pode configurar isso automaticamente concedendo privilégios de administrador de sistema ao usuário do AWS DMS endpoint na instância de origem do SQL Server. Ou você pode seguir as etapas desta seção para preparar a fonte e usar um usuário que não tenha privilégios de administrador de sistema para o endpoint. AWS DMS 

**MS-CDC**  
Para capturar alterações em tabelas sem chaves primárias. Ative a MS-CDC no nível do banco de dados e em todas as tabelas individualmente.

Ao configurar um banco de dados SQL Server para replicação contínua (CDC), é possível seguir um destes procedimentos:
+ Configurar a replicação contínua utilizando o perfil sysadmin.
+ Configurar a replicação contínua para não utilizar o perfil sysadmin.

**nota**  
Você pode usar o seguinte script para encontrar todas as tabelas sem uma chave primária ou exclusiva:  

```
USE [DBname]
SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name
FROM sys.tables
WHERE OBJECTPROPERTY(object_id, 'TableHasPrimaryKey') = 0
        AND  OBJECTPROPERTY(object_id, 'TableHasUniqueCnst') = 0
ORDER BY schema_name, table_name;
```

### Configurar a replicação contínua em um SQL Server autogerenciado
<a name="CHAP_Source.SQLServer.CDC.MSCDC"></a>

Esta seção contém informações sobre como configurar a replicação contínua em um servidor SQL autogerenciado com ou sem a utilização do perfil sysadmin.

**Topics**
+ [Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin](#CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin)
+ [Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin](#CHAP_SupportScripts.SQLServer.standalone)
+ [Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin](#CHAP_SupportScripts.SQLServer.ag)

#### Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin
<a name="CHAP_Source.SQLServer.CDC.MSCDC.Sysadmin"></a>

AWS DMS a replicação contínua para o SQL Server usa a replicação nativa do SQL Server para tabelas com chaves primárias e a captura de dados alterados (CDC) para tabelas sem chaves primárias.

Antes de configurar a replicação contínua, consulte [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

Para tabelas com chaves primárias, geralmente é AWS DMS possível configurar os artefatos necessários na fonte. No entanto, para instâncias de origem do SQL Server que são autogerenciadas, configure primeiro a distribuição do SQL Server manualmente. Depois de fazer isso, os usuários de AWS DMS origem com permissão de administrador de sistema podem criar automaticamente a publicação para tabelas com chaves primárias.

Para verificar se a distribuição já foi configurada, execute o comando a seguir.

```
sp_get_distributor
```

Se o resultado for `NULL` para a distribuição de colunas, a distribuição não estará configurada. É possível utilizar o procedimento a seguir para configurar a distribuição.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup"></a>

**Como configurar a distribuição**

1. Conecte-se ao banco de dados de origem do SQL Server utilizando a ferramenta SQL Server Management Studio (SSMS).

1. Abra o menu de contexto (clique com o botão direito do mouse) da pasta **Replicação** e escolha **Configurar distribuição**. O assistente de configuração da distribuição é exibido. 

1. Siga o assistente para inserir os valores padrão e criar a distribuição.<a name="CHAP_Source.SQLServer.CDC.MSCDC.Setup.CDC"></a>

**Como configurar a CDC**

AWS DMS a versão 3.4.7 e superior pode configurar o MS CDC para seu banco de dados e todas as suas tabelas automaticamente se você não estiver usando uma réplica somente para leitura. Para utilizar esse recurso, defina o ECA `SetUpMsCdcForTables` como verdadeiro. Para obter informações sobre ECAs, consulte[Configurações de endpoint](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.ConnectionAttrib).

Para versões AWS DMS anteriores à 3.4.7 ou para uma réplica somente leitura como fonte, execute as seguintes etapas:

1. Para tabelas sem chaves primárias, configure a MS-CDC para o banco de dados. Para fazer isso, utilize uma conta que tenha o perfil sysadmin atribuído a ela e execute o comando a seguir.

   ```
   use [DBname]
   EXEC sys.sp_cdc_enable_db
   ```

1. Configure a MS-CDC para cada uma das tabelas de origem. Para cada tabela com chaves exclusivas, mas sem chave primária, execute a consulta a seguir para configurar a 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
   ```

1. Para cada tabela sem chave primária nem chaves exclusivas, execute a consulta a seguir para configurar a MS-CDC.

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

Para obter mais informações sobre como configurar a MS-CDC para tabelas específicas, consulte a [Documentação do SQL Server](https://msdn.microsoft.com/en-us/library/cc627369.aspx). 

#### Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin
<a name="CHAP_SupportScripts.SQLServer.standalone"></a>

Esta seção descreve como configurar a replicação contínua para uma origem de banco de dados SQL Server autônomo que não exige que a conta do usuário tenha privilégios de sysadmin.

**nota**  
Depois de executar as etapas desta seção, o usuário do DMS que não for administrador de sistema terá permissões para fazer o seguinte:  
Ler as alterações do arquivo de log de transações on-line.
Acessar o disco para ler as alterações dos arquivos de backup do log de transações.
Adicionar ou alterar a publicação que o DMS usa.
Adicionar artigos à publicação.

1. Configure o Microsoft SQL Server para replicação conforme descrito em [Capturar alterações de dados para replicação contínua no SQL Server](#CHAP_Source.SQLServer.CDC).

1. Ative MS-REPLICATION no banco de dados de origem. Isso pode ser feito manualmente ou executando a tarefa uma vez como usuário sysadmin.

1. Crie o esquema `awsdms` no banco de dados de origem utilizando o seguinte script:

   ```
   use master
   go
   create schema awsdms
   go
   
   
   -- Create the table valued function [awsdms].[split_partition_list] on the Master database, as follows:
   USE [master]
   GO
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   go
   
   if (object_id('[awsdms].[split_partition_list]','TF')) is not null
   
   drop function [awsdms].[split_partition_list];
   
   go
   
   create function [awsdms].[split_partition_list]
   
   (
   
   @plist varchar(8000), --A delimited list of partitions
   
   @dlm nvarchar(1) --Delimiting character
   
   )
   
   returns @partitionsTable table --Table holding the BIGINT values of the string fragments
   
   (
   
   pid bigint primary key
   
   )   
   
   as
   
   begin
   
   declare @partition_id bigint;
   
   declare @dlm_pos integer;
   
   declare @dlm_len integer;
   
   set @dlm_len = len(@dlm);
   
   while (charindex(@dlm,@plist)>0)
   
   begin
   
   set @dlm_pos = charindex(@dlm,@plist);
   
   set @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
   
   insert into @partitionsTable (pid) values (@partition_id)
   
   set @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
   
   end
   
   set @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
   
   insert into @partitionsTable (pid) values ( @partition_id );
   
   return
   
   end
   
   GO
   ```

1. Crie o procedimento `[awsdms].[rtm_dump_dblog]` no banco de dados mestre utilizando o seguinte script:

   ```
   use [MASTER]
   
   go
   
   if (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null drop procedure [awsdms].[rtm_dump_dblog];
   go
   
   
   set ansi_nulls on
   go
   
   set quoted_identifier on
   GO
   
   
   
   CREATE procedure [awsdms].[rtm_dump_dblog]
   
   (
   
   @start_lsn varchar(32),
   
   @seqno integer,
   
   @filename varchar(260),
   
   @partition_list varchar(8000), -- A comma delimited list: P1,P2,... Pn
   
   @programmed_filtering integer,
   
   @minPartition bigint,
   
   @maxPartition bigint
   
   )
   
   as begin
   
   declare @start_lsn_cmp varchar(32); -- Stands against the GT comparator
   
   SET NOCOUNT ON -- – Disable "rows affected display"
   
   set @start_lsn_cmp = @start_lsn;
   
   if (@start_lsn_cmp) is null
   
   set @start_lsn_cmp = '00000000:00000000:0000';
   
   if (@partition_list is null)
   
   begin
   
   RAISERROR ('Null partition list waspassed',16,1);
   
   return
   
   end
   
   if (@start_lsn) is not null
   
   set @start_lsn = '0x'+@start_lsn;
   
   if (@programmed_filtering=0)
   
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1]
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   else
   
   
   SELECT
   
   [Current LSN],
   
   [operation],
   
   [Context],
   
   [Transaction ID],
   
   [Transaction Name],
   
   [Begin Time],
   
   [End Time],
   
   [Flag Bits],
   
   [PartitionID],
   
   [Page ID],
   
   [Slot ID],
   
   [RowLog Contents 0],
   
   [Log Record],
   
   [RowLog Contents 1] -- After Image
   
   FROM
   
   fn_dump_dblog (
   
   @start_lsn, NULL, N'DISK', @seqno, @filename,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default,
   
   default, default, default, default, default, default, default)
   
   where [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS
   
   and
   
   (
   
   ( [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
   
   or
   
   ( [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
   
   and
   
   ( ( [context] in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX' and (datalength([RowLog Contents 0]) in (0,1))))
   
   and ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
   
   )
   
   or
   
   ([operation] = 'LOP_HOBT_DDL')
   
   )
   
   
   
   SET NOCOUNT OFF -- Re-enable "rows affected display"
   
   end
   
   GO
   ```

1. Crie o certificado no banco de dados mestre utilizando o seguinte script:

   ```
   Use [master]
   Go
   
   CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert] ENCRYPTION BY PASSWORD = N'@5trongpassword'
   
   WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions';
   ```

1. Crie o login no certificado utilizando o seguinte script: 

   ```
   Use [master]
   Go
   
   CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE [awsdms_rtm_dump_dblog_cert];
   ```

1. Adicione o login ao perfil do servidor sysadmin utilizando o seguinte script:

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
   ```

1. Adicione a assinatura ao [master].[awsdms].[rtm\$1dump\$1dblog] utilizando o certificado e o seguinte script: 

   ```
   Use [master]
   GO
   ADD SIGNATURE
   TO [master].[awsdms].[rtm_dump_dblog] BY CERTIFICATE [awsdms_rtm_dump_dblog_cert] WITH PASSWORD = '@5trongpassword';
   ```
**nota**  
Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente.

1. Crie o [awsdms].[rtm\$1position\$11st\$1timestamp] no banco de dados principal usando o seguinte script:

   ```
   use [master]
       if object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
       DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
       go
       create procedure [awsdms].[rtm_position_1st_timestamp]
       (
       @dbname                sysname,      -- Database name
       @seqno                 integer,      -- Backup set sequence/position number within file
       @filename              varchar(260), -- The backup filename
       @1stTimeStamp          varchar(40)   -- The timestamp to position by
       ) 
       as begin
   
       SET NOCOUNT ON       -- Disable "rows affected display"
   
       declare @firstMatching table
       (
       cLsn varchar(32),
       bTim datetime
       )
   
       declare @sql nvarchar(4000)
       declare @nl                       char(2)
       declare @tb                       char(2)
       declare @fnameVar                 nvarchar(254) = 'NULL'
   
       set @nl  = char(10); -- New line
       set @tb  = char(9)   -- Tab separator
   
       if (@filename is not null)
       set @fnameVar = ''''+@filename +''''
   
       set @sql='use ['+@dbname+'];'+@nl+
       'select top 1 [Current LSN],[Begin Time]'+@nl+
       'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @fnameVar+','+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default,'+@nl+
       @tb+'default, default, default, default, default, default, default)'+@nl+
       'where operation=''LOP_BEGIN_XACT''' +@nl+
       'and [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
   
       --print @sql
       delete from  @firstMatching 
       insert into @firstMatching  exec sp_executesql @sql    -- Get them all
   
       select top 1 cLsn as [matching LSN],convert(varchar,bTim,121) as [matching Timestamp] from @firstMatching;
   
       SET NOCOUNT OFF      -- Re-enable "rows affected display"
   
       end
       GO
   ```

1. Crie o certificado no banco de dados mestre utilizando o seguinte script:

   ```
   Use [master]
   Go
   CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
   ENCRYPTION BY PASSWORD = '@5trongpassword'
   WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
   ```

1. Crie o login no certificado utilizando o seguinte script:

   ```
   Use [master]
   Go
   CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert];
   ```

1. Adicione o login ao perfil sysadmin utilizando o seguinte script:

   ```
   ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
   ```

1. Adicione a assinatura ao [master].[awsdms].[rtm\$1position\$11st\$1timestamp] utilizando o certificado e o seguinte script:

   ```
   Use [master]
       GO
       ADD SIGNATURE
       TO [master].[awsdms].[rtm_position_1st_timestamp]
       BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
       WITH PASSWORD = '@5trongpassword';
   ```

1. Conceda ao usuário do DMS acesso de execução ao novo procedimento armazenado usando o seguinte script:

   ```
   use master
   go
   GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dms_user;
   ```

1. Crie um usuário com as seguintes permissões e perfis em cada um dos seguintes bancos de dados:
**nota**  
Crie a conta de usuário dmsnosysadmin com o mesmo SID em cada réplica. A consulta SQL a seguir pode ajudar a verificar o valor do SID da conta dmsnosysadmin em cada réplica. Para obter mais informações sobre como criar um usuário, consulte [CREATE USER (Transact-SQL) ](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) na [Documentação do Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Para obter mais informações sobre a criação de contas de usuário do SQL para o banco de dados SQL do Azure, consulte [Replicação geográfica ativa](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

   ```
   use master
   go
   grant select on sys.fn_dblog to [DMS_user]
   grant view any definition to [DMS_user]
   grant view server state to [DMS_user]--(should be granted to the login).
   grant execute on sp_repldone to [DMS_user]
   grant execute on sp_replincrementlsn to [DMS_user]
   grant execute on sp_addpublication to [DMS_user]
   grant execute on sp_addarticle to [DMS_user]
   grant execute on sp_articlefilter to [DMS_user]
   grant select on [awsdms].[split_partition_list] to [DMS_user]
   grant execute on [awsdms].[rtm_dump_dblog] to [DMS_user]
   ```

   ```
   use msdb
   go
   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
   ```

   Execute o seguinte script no banco de dados de origem:

   ```
   use Source_DB
       Go
       EXEC sp_addrolemember N'db_owner', N'DMS_user'
   ```

1. Por fim, adicione um atributo de conexão extra (ECA) ao endpoint do SQL Server de origem:

   ```
   enableNonSysadminWrapper=true;
   ```

#### Configurar a replicação contínua em um SQL Server em um ambiente de grupo de disponibilidade: sem o perfil sysadmin
<a name="CHAP_SupportScripts.SQLServer.ag"></a>

Esta seção descreve como configurar a replicação contínua para uma origem de banco de dados SQL Server em um ambiente de grupo de disponibilidade que não exige que a conta do usuário tenha privilégios de sysadmin.

**nota**  
Depois de executar as etapas desta seção, o usuário do DMS que não for administrador de sistema terá permissões para fazer o seguinte:  
Ler as alterações do arquivo de log de transações on-line.
Acessar o disco para ler as alterações dos arquivos de backup do log de transações.
Adicionar ou alterar a publicação que o DMS usa.
Adicionar artigos à publicação.

**Como configurar a replicação contínua sem utilizar o usuário sysadmin em um ambiente de grupo de disponibilidade**

1. Configure o Microsoft SQL Server para replicação conforme descrito em [Capturar alterações de dados para replicação contínua no SQL Server](#CHAP_Source.SQLServer.CDC).

1. Ative MS-REPLICATION no banco de dados de origem. Isso pode ser feito manualmente ou executando a tarefa uma vez utilizando um usuário sysadmin.
**nota**  
Configure o distribuidor MS-REPLICATION como local ou de uma forma que permita acesso a usuários que não sejam administradores de sistema por meio do servidor vinculado associado.

1. Se a opção do endpoint **Usar exclusivamente sp\$1repldone em uma única tarefa** estiver ativada, interrompa o trabalho do MS-REPLICATION Log Reader.

1. Execute as seguintes etapas em cada réplica:

   1. Crie o esquema `[awsdms]`[awsdms] no banco de dados mestre:

      ```
      CREATE SCHEMA [awsdms]
      ```

   1. Crie o perfil com valor de tabela `[awsdms].[split_partition_list]` no banco de dados mestre:

      ```
      USE [master]
      GO
      
      SET ansi_nulls on
      GO
        
      SET quoted_identifier on
      GO
      
      IF (object_id('[awsdms].[split_partition_list]','TF')) is not null
        DROP FUNCTION [awsdms].[split_partition_list];
      GO
      
      CREATE FUNCTION [awsdms].[split_partition_list] 
      ( 
        @plist varchar(8000),    --A delimited list of partitions    
        @dlm nvarchar(1)    --Delimiting character
      ) 
      RETURNS @partitionsTable table --Table holding the BIGINT values of the string fragments
      (
        pid bigint primary key
      ) 
      AS 
      BEGIN
        DECLARE @partition_id bigint;
        DECLARE @dlm_pos integer;
        DECLARE @dlm_len integer;  
        SET @dlm_len = len(@dlm);
        WHILE (charindex(@dlm,@plist)>0)
        BEGIN 
          SET @dlm_pos = charindex(@dlm,@plist);
          SET @partition_id = cast( ltrim(rtrim(substring(@plist,1,@dlm_pos-1))) as bigint);
          INSERT into @partitionsTable (pid) values (@partition_id)
          SET @plist = substring(@plist,@dlm_pos+@dlm_len,len(@plist));
        END 
        SET @partition_id = cast (ltrim(rtrim(@plist)) as bigint);
        INSERT into @partitionsTable (pid) values (  @partition_id  );
        RETURN
      END
      GO
      ```

   1. Crie o procedimento `[awsdms].[rtm_dump_dblog]` no banco de dados mestre:

      ```
      USE [MASTER] 
      GO
      
      IF (object_id('[awsdms].[rtm_dump_dblog]','P')) is not null
        DROP PROCEDURE [awsdms].[rtm_dump_dblog]; 
      GO
      
      SET ansi_nulls on
      GO 
      
      SET quoted_identifier on 
      GO
                                          
      CREATE PROCEDURE [awsdms].[rtm_dump_dblog]
      (
        @start_lsn            varchar(32),
        @seqno                integer,
        @filename             varchar(260),
        @partition_list       varchar(8000), -- A comma delimited list: P1,P2,... Pn
        @programmed_filtering integer,
        @minPartition         bigint,
        @maxPartition         bigint
      ) 
      AS 
      BEGIN
      
        DECLARE @start_lsn_cmp varchar(32); -- Stands against the GT comparator
      
        SET NOCOUNT ON  -- Disable "rows affected display"
      
        SET @start_lsn_cmp = @start_lsn;
        IF (@start_lsn_cmp) is null
          SET @start_lsn_cmp = '00000000:00000000:0000';
      
        IF (@partition_list is null)
          BEGIN
            RAISERROR ('Null partition list was passed',16,1);
            return
            --set @partition_list = '0,';    -- A dummy which is never matched
          END
      
        IF (@start_lsn) is not null
          SET @start_lsn = '0x'+@start_lsn;
      
        IF (@programmed_filtering=0)
          SELECT
            [Current LSN],
            [operation],
            [Context],
            [Transaction ID],
            [Transaction Name],
            [Begin Time],
            [End Time],
            [Flag Bits],
            [PartitionID],
            [Page ID],
            [Slot ID],
            [RowLog Contents 0],
            [Log Record],
            [RowLog Contents 1] -- After Image
          FROM
            fn_dump_dblog (
              @start_lsn, NULL, N'DISK', @seqno, @filename,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default,
              default, default, default, default, default, default, default)
          WHERE 
            [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND       
                [PartitionID] in ( select * from master.awsdms.split_partition_list (@partition_list,','))
              )
            OR
            ([operation] = 'LOP_HOBT_DDL')
          )
          ELSE
            SELECT
              [Current LSN],
              [operation],
              [Context],
              [Transaction ID],
              [Transaction Name],
              [Begin Time],
              [End Time],
              [Flag Bits],
              [PartitionID],
              [Page ID],
              [Slot ID],
              [RowLog Contents 0],
              [Log Record],
              [RowLog Contents 1] -- After Image
            FROM
              fn_dump_dblog (
                @start_lsn, NULL, N'DISK', @seqno, @filename,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default,
                default, default, default, default, default, default, default)
            WHERE [Current LSN] collate SQL_Latin1_General_CP1_CI_AS > @start_lsn_cmp collate SQL_Latin1_General_CP1_CI_AS -- This aims for implementing FN_DBLOG based on GT comparator.
            AND
            (
              (  [operation] in ('LOP_BEGIN_XACT','LOP_COMMIT_XACT','LOP_ABORT_XACT') )
              OR
              (  [operation] in ('LOP_INSERT_ROWS','LOP_DELETE_ROWS','LOP_MODIFY_ROW')
                AND
                ( ( [context]   in ('LCX_HEAP','LCX_CLUSTERED','LCX_MARK_AS_GHOST') ) or ([context] = 'LCX_TEXT_MIX') )
                AND ([PartitionID] is not null) and ([PartitionID] >= @minPartition and [PartitionID]<=@maxPartition)
              )
              OR
              ([operation] = 'LOP_HOBT_DDL')
            )
            SET NOCOUNT OFF -- Re-enable "rows affected display"
      END
      GO
      ```

   1. Crie um certificado no banco de dados mestre:

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_DUMP_DBLOG Permissions'
      ```

   1. Crie um login no certificado:

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_dump_dblog_login FROM CERTIFICATE
        [awsdms_rtm_dump_dblog_cert];
      ```

   1. Adicione o login ao perfil do servidor sysadmin:

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_dump_dblog_login];
      ```

   1. Adicione a assinatura ao procedimento [master].[awsdms].[rtm\$1dump\$1dblog] utilizando o certificado:

      ```
      USE [master]
      GO
      
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_dump_dblog]
        BY CERTIFICATE [awsdms_rtm_dump_dblog_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**nota**  
Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente.

   1. Crie o procedimento `[awsdms].[rtm_position_1st_timestamp]` no banco de dados mestre:

      ```
      USE [master]
      IF object_id('[awsdms].[rtm_position_1st_timestamp]','P') is not null
        DROP PROCEDURE [awsdms].[rtm_position_1st_timestamp];
      GO
      CREATE PROCEDURE [awsdms].[rtm_position_1st_timestamp]
      (
        @dbname                sysname,      -- Database name
        @seqno                 integer,      -- Backup set sequence/position number within file
        @filename              varchar(260), -- The backup filename
        @1stTimeStamp          varchar(40)   -- The timestamp to position by
      ) 
      AS 
      BEGIN
        SET NOCOUNT ON       -- Disable "rows affected display"
      
        DECLARE @firstMatching table
        (
          cLsn varchar(32),
          bTim datetime
        )
        DECLARE @sql nvarchar(4000)
        DECLARE @nl                       char(2)
        DECLARE @tb                       char(2)
        DECLARE @fnameVar                 sysname = 'NULL'
      
        SET @nl  = char(10); -- New line
        SET @tb  = char(9)   -- Tab separator
      
        IF (@filename is not null)
          SET @fnameVar = ''''+@filename +''''
        SET @filename = ''''+@filename +''''
        SET @sql='use ['+@dbname+'];'+@nl+
          'SELECT TOP 1 [Current LSN],[Begin Time]'+@nl+
          'FROM fn_dump_dblog (NULL, NULL, NULL, '+ cast(@seqno as varchar(10))+','+ @filename +','+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default,'+@nl+
          @tb+'default, default, default, default, default, default, default)'+@nl+
          'WHERE operation=''LOP_BEGIN_XACT''' +@nl+
          'AND [Begin Time]>= cast('+''''+@1stTimeStamp+''''+' as datetime)'+@nl
      
          --print @sql
          DELETE FROM @firstMatching 
          INSERT INTO @firstMatching  exec sp_executesql @sql    -- Get them all
          SELECT TOP 1 cLsn as [matching LSN],convert(varchar,bTim,121) AS[matching Timestamp] FROM @firstMatching;
      
          SET NOCOUNT OFF      -- Re-enable "rows affected display"
      
      END
      GO
      ```

   1. Crie um certificado no banco de dados mestre:

      ```
      USE [master]
      GO
      CREATE CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        ENCRYPTION BY PASSWORD = N'@hardpassword1'
        WITH SUBJECT = N'Certificate for FN_POSITION_1st_TIMESTAMP Permissions';
      ```

   1. Crie um login no certificado:

      ```
      USE [master]
      GO
      CREATE LOGIN awsdms_rtm_position_1st_timestamp_login FROM CERTIFICATE
        [awsdms_rtm_position_1st_timestamp_cert];
      ```

   1. Adicione o login ao perfil do servidor sysadmin:

      ```
      ALTER SERVER ROLE [sysadmin] ADD MEMBER [awsdms_rtm_position_1st_timestamp_login];
      ```

   1. Adicione a assinatura ao procedimento `[master].[awsdms].[rtm_position_1st_timestamp]` utilizando o certificado:

      ```
      USE [master]
      GO
      ADD SIGNATURE
        TO [master].[awsdms].[rtm_position_1st_timestamp]
        BY CERTIFICATE [awsdms_rtm_position_1st_timestamp_cert]
        WITH PASSWORD = '@hardpassword1';
      ```
**nota**  
Se você recriar o procedimento armazenado, será necessário adicionar a assinatura novamente.

   1. Crie um usuário com o seguinte permissions/roles em cada um dos seguintes bancos de dados:
**nota**  
Crie a conta de usuário dmsnosysadmin com o mesmo SID em cada réplica. A consulta SQL a seguir pode ajudar a verificar o valor do SID da conta dmsnosysadmin em cada réplica. Para obter mais informações sobre como criar um usuário, consulte [CREATE USER (Transact-SQL) ](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql) na [Documentação do Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/). Para obter mais informações sobre a criação de contas de usuário do SQL para o banco de dados SQL do Azure, consulte [Replicação geográfica ativa](https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview).

      ```
      SELECT @@servername servername, name, sid, create_date, modify_date
        FROM sys.server_principals
        WHERE name = 'dmsnosysadmin';
      ```

   1. Conceda permissões no banco de dados mestre em cada réplica:

      ```
      USE master
      GO 
      
      GRANT select on sys.fn_dblog to dmsnosysadmin;
      GRANT view any definition to dmsnosysadmin;
      GRANT view server state to dmsnosysadmin -- (should be granted to the login).
      GRANT execute on sp_repldone to dmsnosysadmin;
      GRANT execute on sp_replincrementlsn to dmsnosysadmin;
      GRANT execute on sp_addpublication to dmsnosysadmin;
      GRANT execute on sp_addarticle to dmsnosysadmin;
      GRANT execute on sp_articlefilter to dmsnosysadmin;
      GRANT select on [awsdms].[split_partition_list] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_dump_dblog] to dmsnosysadmin;
      GRANT execute on [awsdms].[rtm_position_1st_timestamp] to dmsnosysadmin;
      ```

   1. Conceda permissões no banco de dados msdb em cada réplica:

      ```
      USE msdb
      GO
      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
      ```

   1. Adicione o perfil `db_owner` ao `dmsnosysadmin` no banco de dados de origem. Como o banco de dados é sincronizado, é possível adicionar o perfil somente na réplica primária.

      ```
      use <source DB>
      GO 
      EXEC sp_addrolemember N'db_owner', N'dmsnosysadmin'
      ```

## Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem
<a name="CHAP_Source.SQLServer.Configuration"></a>

Esta seção descreve como configurar a CDC em uma instância de banco de dados SQL Server hospedada na nuvem. Uma instância do SQL Server hospedada na nuvem é uma instância em execução no Amazon RDS para SQL Server, uma instância gerenciada do Azure SQL ou qualquer outra instância gerenciada do SQL Server na nuvem. Para obter informações sobre as limitações da replicação contínua para cada tipo de banco de dados, consulte [Limitações no uso do SQL Server como fonte para AWS DMS](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Limitations). 

Antes de configurar a replicação contínua, consulte [Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Prerequisites). 

Ao contrário das origens autogerenciadas do SQL Server, o Amazon RDS para SQL Server não é compatível com a MS-Replication. Portanto, AWS DMS precisa usar o MS-CDC para tabelas com ou sem chaves primárias.

O Amazon RDS não concede privilégios de administrador de sistema para definir artefatos de replicação AWS DMS usados para alterações contínuas em uma instância de origem do SQL Server. Ative a MS-CDC na instância do Amazon RDS (utilizando privilégios de usuário mestre) como no procedimento a seguir.

**Para ativar a MS-CDC em uma instância de banco de dados do SQL Server na nuvem**

1. Execute as consultas a seguir no nível do banco de dados.

   Para uma instância de banco de dados RDS para SQL Server, utilize essa consulta.

   ```
   exec msdb.dbo.rds_cdc_enable_db 'DB_name'
   ```

   Para uma instância de banco de dados gerenciada do Azure SQL, utilize essa consulta.

   ```
   USE DB_name 
   GO 
   EXEC sys.sp_cdc_enable_db 
   GO
   ```

1. Para cada tabela com uma chave primária, execute a consulta a seguir para ativar a 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 tabela com chaves exclusivas, mas sem chave primária, execute a consulta a seguir para ativar a 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 tabela sem chave primária e sem chaves exclusivas, execute a consulta a seguir para habilitar a MS-CDC.

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

1. Defina o período de retenção:
   + Para instâncias do RDS para SQL Server que estão sendo replicadas usando o DMS versão 3.5.3 e superiores, garanta que o período de retenção esteja definido com o valor padrão de 5 segundos. Se você estiver atualizando ou migrando do DMS 3.5.2 e versões anteriores para o DMS 3.5.3 e versões posteriores, altere o valor do intervalo de sondagem depois que as tarefas estiverem em execução na instância nova ou atualizada. O script a seguir define o período de retenção como 5 segundos:

     ```
     use dbname
     EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 5
     exec sp_cdc_stop_job 'capture'
     exec sp_cdc_start_job 'capture'
     ```
   + O parâmetro `@pollinginterval` é medido em segundos com um valor recomendado definido como 86399. Isso significa que o log de transações retém as alterações por 86.399 segundos (um dia) quando `@pollinginterval = 86399`. O procedimento `exec sp_cdc_start_job 'capture'` inicia as configurações.
**nota**  
Com algumas versões do SQL Server, se o valor de `pollinginterval` for definido como mais de 3599 segundos, o valor será redefinido para os cinco segundos padrão. Quando isso acontece, as entradas do T-Log são removidas antes que AWS DMS você possa lê-las. Para determinar quais versões do SQL Server são afetadas por esse problema conhecido, consulte [este artigo da Microsoft KB](https://support.microsoft.com/en-us/topic/kb4459220-fix-incorrect-results-occur-when-you-convert-pollinginterval-parameter-from-seconds-to-hours-in-sys-sp-cdc-scan-in-sql-server-dac8aefe-b60b-7745-f987-582dda2cfa78).

     Se estiver utilizando o Amazon RDS com multi-AZ, defina também o secundário para ter os valores corretos em caso de failover.

     ```
     exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , <5 or preferred value>
     ```

**Para manter o período de retenção quando uma tarefa de AWS DMS replicação é interrompida por mais de uma hora**
**nota**  
As etapas a seguir não são necessárias para replicação de uma origem do RDS para SQL Server usando o DMS 3.5.3 e superiores.

1. Interrompa o trabalho que está truncando os logs de transações utilizando este comando: 

   ```
   exec sp_cdc_stop_job 'capture'
   ```

1. Encontre sua tarefa no AWS DMS console e continue a tarefa.

1. Escolha a guia **Monitoramento** e marque a métrica `CDCLatencySource`. 

1. Quando a métrica `CDCLatencySource` for igual a 0 (zero) e permanecer nesse valor, reinicie o trabalho truncando os logs de transações com o seguinte comando:

   ```
   exec sp_cdc_start_job 'capture'
   ```

Lembre-se de iniciar o trabalho que trunca os logs de transações do SQL Server. Caso contrário, o armazenamento na instância do SQL Server poderá ficar cheio.

### Configurações recomendadas ao usar o RDS para SQL Server como fonte para AWS DMS
<a name="CHAP_Source.SQLServer.Configuration.Settings"></a>

#### Para AWS DMS 3.5.3 e superior
<a name="CHAP_Source.SQLServer.Configuration.Settings.353"></a>

**nota**  
A versão inicial do recurso de backup de log do RDS para SQL Server está habilitada por padrão para endpoints que você criou ou modificou após o lançamento do DMS versão 3.5.3. Para usar esse recurso para endpoints existentes, modifique o endpoint sem fazer nenhuma alteração.

AWS DMS a versão 3.5.3 introduz suporte para leitura de backups de log. O DMS depende principalmente da leitura dos logs de transações ativos para replicar eventos. Se o backup de uma transação for feito antes que o DMS possa lê-la no log ativo, a tarefa acessará os backups do RDS sob demanda e lerá os logs de backup subsequentes até alcançar o log de transações ativo. Para garantir que o DMS tenha acesso aos backups de log, defina o período de retenção de backup automatizado do RDS para pelo menos um dia. Para ter informações sobre como configurar o período de retenção de backup automatizado, consulte [Período de retenção de backup](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ManagingAutomatedBackups.html#USER_WorkingWithAutomatedBackups.BackupRetention) no *Guia do usuário do Amazon RDS*.

Uma tarefa do DMS que acessa os backups de log utiliza o armazenamento na instância do RDS. Observe que a tarefa só acessa os backups de log necessários para a replicação. O Amazon RDS remove esses backups baixados em algumas horas. Essa remoção não afeta os backups do Amazon RDS retidos no Amazon S3 ou a funcionalidade `RESTORE DATABASE` do Amazon RDS. É recomendável alocar armazenamento adicional em sua origem do RDS para SQL Server, se pretender replicar usando o DMS. Uma forma de estimar a quantidade de armazenamento necessária é identificar o backup a partir do qual o DMS iniciará ou retomará a replicação e somar os tamanhos dos arquivos de todos os backups subsequentes usando a função de metadados `tlog backup` do RDS. Para ter mais informações sobre a função `tlog backup`, consulte [Listar os backups de logs de transações disponíveis](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER.SQLServer.AddlFeat.TransactionLogAccess.html#USER.SQLServer.AddlFeat.TransactionLogAccess.Listing) no *Guia do usuário do Amazon RDS*. 

Como alternativa, você pode optar por ativar o escalonamento automático de armazenamento e/ou acionar o escalonamento de armazenamento com base na métrica CloudWatch `FreeStorageSpace` da sua instância do Amazon RDS.

É altamente recomendável que você não inicie ou retome a partir de um ponto muito distante nos backups do log de transações, pois isso pode fazer com que o armazenamento em sua instância do SQL Server fique cheio. Nesses casos, é aconselhável iniciar uma carga máxima. A replicação do backup do log de transações é mais lenta do que a leitura dos logs de transações ativos. Para obter mais informações, consulte [Processamento de backup do log de transações do RDS para SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md#CHAP_Troubleshooting_Latency_Source_SQLServer_backup).

Observe que o acesso aos backups de log requer privilégios adicionais. Para ter mais informações, consulte os detalhes em [Configurar permissões para replicação contínua a partir de um banco de dados do SQL Server na nuvem](CHAP_Source.SQLServer.md#CHAP_Source.SQLServer.Permissions.Cloud). Conceda esses privilégios antes que a tarefa comece a ser replicada.

#### Para AWS DMS 3.5.2 e versões anteriores
<a name="CHAP_Source.SQLServer.Configuration.Settings.352"></a>

Quando você trabalha com o Amazon RDS para SQL Server como origem, o trabalho de captura do MS-CDC depende dos parâmetros `maxscans` e `maxtrans`. Esses parâmetros governam o número máximo de verificações que a captura do MS-CDC faz no log de transações e o número de transações que são processadas para cada verificação.

Para bancos de dados, em que o número de transações é maior que `maxtrans*maxscans`, aumentar o valor de `polling_interval` pode causar um acúmulo de registros no log de transações. Por sua vez, esse acúmulo pode levar a um aumento no tamanho do log de transações.

Observe que AWS DMS não depende da tarefa de captura do MS-CDC. A tarefa de captura da MS-CDC marca as entradas do log de transações como processadas. Isso permite que a tarefa de backup do log de transações remova as entradas do log de transações.

É recomendável monitorar o tamanho do log de transações e o sucesso das tarefas da MS-CDC. Se as tarefas do MS-CDC falharem, o registro de transações poderá crescer excessivamente e causar falhas na replicação. AWS DMS É possível monitorar erros do trabalho de captura da MS-CDC utilizando a visualização de gerenciamento dinâmico `sys.dm_cdc_errors` no banco de dados de origem. É possível monitorar o tamanho do log de transações utilizando o comando de gerenciamento `DBCC SQLPERF(LOGSPACE)`.

**Como abordar o aumento do log de transações causado pela MS-CDC**

1. Verifique de onde `Log Space Used %` o banco de dados AWS DMS está sendo replicado e valide se ele aumenta continuamente.

   ```
   DBCC SQLPERF(LOGSPACE)
   ```

1. Identifique o que está bloqueando o processo de backup do log de transações.

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

   Se o valor de `log_reuse_wait_desc` for igual a `REPLICATION`, a retenção do backup do log será causada pela latência na MS-CDC.

1. Aumente o número de eventos processados pelo trabalho de captura aumentando os valores dos parâmetros `maxtrans` e `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 resolver esse problema, defina os valores de `maxscans` e para que `maxtrans` `maxtrans*maxscans` sejam iguais ao número médio de eventos gerados para tabelas que são AWS DMS replicadas do banco de dados de origem para cada dia.

Se você definir esses parâmetros acima do valor recomendado, os trabalhos de captura processarão todos os eventos nos logs de transações. Se você definir esses parâmetros abaixo do valor recomendado, a latência da MS-CDC aumentará e o log de transações também.

A identificação dos valores apropriados para `maxscans` e `maxtrans` pode ser difícil porque as alterações na workload produzem um número variável de eventos. Nesse caso, é recomendável configurar o monitoramento na latência da MS-CDC. Para obter mais informações, consulte [Monitorar o processo](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/administer-and-monitor-change-data-capture-sql-server?view=sql-server-ver15#Monitor) na documentação do SQL Server. Configure `maxtrans` e `maxscans` dinamicamente com base nos resultados do monitoramento.

Se a AWS DMS tarefa não conseguir encontrar os números de sequência de log (LSNs) necessários para retomar ou continuar a tarefa, a tarefa poderá falhar e exigir uma recarga completa.

**nota**  
Ao usar AWS DMS para replicar dados de uma fonte do RDS para SQL Server, você pode encontrar erros ao tentar retomar a replicação após um evento de stop-start da instância do Amazon RDS. Isso ocorre porque o processo do SQL Server Agent reinicia o processo da tarefa de captura quando ele é reiniciado após o evento de interrupção-inicialização. Isso ignora o intervalo de pesquisa da MS-CDC.  
Por esse motivo, em bancos de dados com volumes de transações menores do que o processamento da tarefa de captura do MS-CDC, isso pode fazer com que os dados sejam processados ou marcados como replicados e copiados antes AWS DMS de serem retomados de onde pararam, resultando no seguinte erro:  

```
[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 esse problema, defina os valores de `maxtrans` e de `maxscans` conforme recomendado anteriormente.