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

Modo de foco

Usando um banco de dados Microsoft SQL Server como fonte para AWS DMS - AWS Database Migration Service

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

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. Para obter mais informações, consulte Permissões para tarefas do SQL Server.

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.

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

Para obter 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 do SQL Server
Utilizar replicação contínua (CDC) a partir de uma origem do SQL Server
Métodos de compactação compatíveis com o SQL Server
Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server
Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS
Tipos de dados de origem no SQL Server
Capturar alterações de dados para replicação contínua no SQL Server

Limitações 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 é 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
```
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 obter 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.
É 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 oferece suporte ao 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.

Permissões para tarefas do SQL Server

Tópicos

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

Permissões para tarefas somente de carga máxima

As permissões a seguir são necessárias para realizar tarefas somente de carga máxima. Observe que 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;
                GRANT VIEW DEFINITION to dms_user;
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

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

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

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

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

Execute os seguintes comandos GRANT:


GRANT VIEW SERVER STATE TO self_managed_user;

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

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

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

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

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

Execute os seguintes comandos de concessão:


GRANT VIEW SERVER STATE TO rds_user;

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

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


//DMS 3.5.3 version onwards
GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user;
GRANT EXEC ON msdb.dbo.rds_task_status TO rds_user;

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

Você pode usar a replicação contínua (captura de dados de alteração ou CDC) para um banco de dados SQL Server autogerenciado no local ou na Amazon, ou um banco de dados na nuvem EC2, como o Amazon RDS ou uma instância gerenciada SQL do Microsoft Azure.

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

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

Para usar um grupo de disponibilidade secundário como origem em 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 obter 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 obter 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 obter 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 obter 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 obter 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.

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`} Example: `'{"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` Example: `'{"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 Capturar alterações de dados para replicação contínua no SQL Server. Valor padrão: `false` Valores válidos: `true`, `false` Example: `'{"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. Example: `'{"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` Example: `'{"FatalOnSimpleModel": true}'`
`ForceLobLookup`	Força a pesquisa de LOB em LOB em linha. Valor padrão: `false` Valores válidos: `true`, `false` Example: `'{"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`. Example: `'{"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`} Example: `'{"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`} Example: `'{"SetUpMsCdcForTables": true}'`
`TlogAccessMode`	Indica o modo utilizado para buscar dados da CDC. Valor padrão: `PreferTlog` Valores válidos: `BackupOnly`, `PreferBackup`, `PreferTlog`, `TlogOnly` Example: `'{"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 para 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 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. 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

CDC para SQL Server como origem

Nesta página

Selecione suas preferências de cookies

Personalizar preferências de cookies

Essenciais

Desempenho

Funcionais

Publicidade

Não foi possível salvar as preferências de cookie

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

nota

Tópicos

Limitações no uso do SQL Server como fonte para AWS DMS

Permissões para tarefas do SQL Server

Tópicos

Permissões para tarefas somente de carga máxima

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

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

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

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

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

Trabalhando com grupos de AlwaysOn disponibilidade autogerenciados do SQL Server

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:

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

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

Limitações

Failover para outros nós

Configurações de endpoint ao usar o SQL Server como fonte para AWS DMS

Tipos de dados de origem no SQL Server

nota

Nesta página

Esta página foi útil?

Próximo tópico:

Tópico anterior:

Precisa de ajuda?