Limitações de uso do SQL Server como origem Permissões do SQL Server Pré-requisitos para a utilização da CDC em andamento Capturar alterações do SQL Server autogerenciado on-premises ou no EC2 Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem Configurações opcionais do RDS para SQL Server como origem Métodos de compactação compatíveis Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server Requisitos de segurança Configurações de endpoint Tipos de dados de origem no SQL Server

Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS

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, consulteFontes para 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. Essa conta deve ter as permissões view definition e view server state. Adicione essa permissão utilizando o seguinte comando:


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

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.

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

Tópicos

Limitações no uso do SQL Server como fonte para AWS DMS
Permissões para tarefas somente de carga máxima
Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server
Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2
Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem
Configurações recomendadas ao usar o Amazon RDS for SQL Server como fonte para AWS DMS
Métodos de compactação compatíveis com o SQL Server
Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server
Requisitos de segurança ao usar o SQL Server como fonte para AWS Database Migration Service
Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS
Tipos de dados de origem no SQL Server

Limitações no uso do SQL Server como fonte para 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 oferece suporte ao uso 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, executar o comando AWS DMS a seguir causa falha.
```
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 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_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';)
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 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.
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 ter mais informações, consulte Configurações de ajuste de processamento de alterações.
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.

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 oferece suporte ao processamento direto de backups de registros de transações no nível do arquivo a partir de pastas compartilhadas alternativas.

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 AWS DMS isso não cria o dms_user login. 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 ; 
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_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 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.

Capturar dados alterados no SQL Server autogerenciado on-premises ou no Amazon EC2

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.

Configurar a replicação contínua em um SQL Server autogerenciado

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.

Tópicos

Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin
Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin

Configurar a replicação contínua em um SQL Server autogerenciado: utilizando o perfil sysadmin

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.

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.

Como configurar a distribuição

Conecte-se ao banco de dados de origem do SQL Server utilizando a ferramenta SQL Server Management Studio (SSMS).
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.
Siga o assistente para inserir os valores padrão e criar a distribuição.

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 mais informações sobre ECAs, consulte Configurações de endpoint.

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

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

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

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.

Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin

Para obter informações sobre como configurar a replicação contínua em um SQL Server autônomo sem o perfil sysadmin, consulte Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin.

Configurar a replicação contínua em uma instância de banco de dados SQL Server na nuvem

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.

Antes de configurar a replicação contínua, consulte Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server.

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

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

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

Defina o período de retenção para que as alterações estejam disponíveis na origem utilizando o comando a seguir.
```
use dbname
EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 86399
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'
```
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.

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' , 86399
```

Se uma tarefa de AWS DMS replicação que captura alterações contínuas na origem do SQL Server parar por mais de uma hora, use o procedimento a seguir.

Para manter o período de retenção durante uma tarefa de AWS DMS replicação

Interrompa o trabalho que está truncando os logs de transações utilizando este comando:
```
exec sp_cdc_stop_job 'capture'
```
Encontre sua tarefa no AWS DMS console e continue a tarefa.
Escolha a guia Monitoramento e marque a métrica CDCLatencySource.
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.

Limitações da replicação contínua em uma instância do banco de dados SQL Server na nuvem

AWS DMS suporta 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 você os mover do log de transações ativo para o log de backup ou truncá-los no log de transações ativo.

Configurações recomendadas ao usar o Amazon RDS for SQL Server como fonte para AWS DMS

Quando você trabalha com o Amazon RDS para SQL Server como origem, o trabalho de captura depende dos parâmetros maxscans e maxtrans. Esses parâmetros governam o número máximo de verificações que a captura 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

Verifique de onde Log Space Used % o banco de dados AWS DMS está sendo replicado e valide se ele aumenta continuamente.
```
DBCC SQLPERF(LOGSPACE)
```
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.

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

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:

AWS DMS oferece suporte à compactação de linha/página 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 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

Para usar o grupo de disponibilidade principal como fonte em 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 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 começar. 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 usar um grupo de disponibilidade secundário como origem AWS DMS, faça o seguinte:

Use as mesmas credenciais usadas pelo usuário do endpoint de AWS DMS origem para se conectar a réplicas individuais.
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>';
```
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 usar o SQL Server como fonte para 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:

AWS DMS não oferece suporte ao Safeguard ao usar uma réplica de grupo de disponibilidade somente para leitura como fonte. Para ter mais informações, consulte Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS.
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 ter mais informações, consulte Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS.
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

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

Requisitos de segurança ao usar o SQL Server como fonte para AWS Database Migration Service

A conta de AWS DMS usuário deve ter pelo menos a função de db_owner usuário no banco de dados SQL Server de origem ao qual você está se conectando.

Configurações de endpoint ao usar o SQL Server como fonte para 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 usando o AWS DMS console ou usando o create-endpoint comando no AWS CLI, 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.

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 da migração de AWS DMS um banco de dados de origem do SQL Server hospedado como parte de um cluster de grupos de disponibilidade Always On. AWS DMS tem suporte aprimorado para bancos de dados de origem do SQL Server que estão 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, AWS DMS tenta se conectar a cada nó no cluster, mas falha se não conseguir se conectar a nenhum dos nós. Se você AWS DMS precisar pesquisar todos os nós no cluster Always On para backups de transações, defina esse atributo `false` como. 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 é suportado na 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 Configurar a replicação contínua em um SQL Server autônomo: sem o perfil sysadmin. 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, AWS DMS tenta se conectar a todos os endereços IP associados ao ouvinte do Grupo de Disponibilidade.
`ReadBackupOnly`	A utilização desse atributo requer privilégios de sysadmin. Quando esse atributo é definido como`Y`, durante a replicação contínua, AWS DMS lê as alterações somente dos backups do log de transações e não lê do arquivo de log de transações ativo. 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 um desempenho ideal, AWS DMS tenta capturar todas as alterações não lidas do registro de transações ativo (TLOG). Contudo, às vezes devido a um truncamento, o TLOG ativo talvez não contenha todas as alterações não lidas. Quando isso ocorre, AWS DMS acessa o backup do log para capturar as alterações ausentes. Para minimizar a necessidade de acessar o backup do log, AWS DMS evita o truncamento usando um dos seguintes métodos: `RELY_ON_SQL_SERVER_REPLICATION_AGENT`(Iniciar transações no banco de dados): Esse é o padrão para 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 habilitar a Replicação Microsoft em seu banco de dados para uma finalidade diferente de AWS DMS, escolha essa configuração. Ao usar essa configuraçã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`(Uso exclusivo `sp_repldone` com uma única tarefa): Ao usar essa configuração, AWS DMS tem controle total do processo do agente de replicação que marca as entradas de registro como sendo `ready for truncation` usadas. `sp_repldone` Com essa configuração, AWS DMS não usa uma transação fictícia como na configuração `RELY_ON_SQL_SERVER_REPLICATION_AGENT` (padrão). Você só pode usar essa configuração quando o MS Replication não é usado para nenhuma outra finalidade que não seja AWS DMS no banco de dados de origem. Além disso, ao usar essa configuração, somente uma AWS DMS tarefa pode acessar o banco de dados. Se você precisar executar AWS DMS tarefas paralelas no mesmo banco de dados, use`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 Log Reader Agent estiver em execução quando a tarefa for iniciada, a AWS DMS tarefa a forçará a parar. 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. Você não pode usar essa configuração quando o trabalho de migração do Microsoft SQL Server é executado em uma máquina remota do Distribuidor, porque 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 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, consulteTipos de dados do AWS Database Migration Service.

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 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 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. 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_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

Utilizar um banco de dados Azure SQL como origem