Práticas recomendadas do AWS Database Migration Service

Para utilizar o AWS Database Migration Service (AWS DMS) de maneira mais eficiente, consulte as recomendações desta seção sobre a maneira mais eficaz de migrar dados.

Planejamento de migração do AWS Database Migration Service

Ao planejar uma migração de banco de dados utilizando o AWS Database Migration Service, considere o seguinte:

• Para conectar os bancos de dados de origem e de destino a uma instância de replicação do AWS DMS, configure uma rede. Isso pode ser tão simples quanto conectar dois recursos da AWS na mesma nuvem privada virtual (VPC) que a instância de replicação. Isso pode variar para configurações mais complexas, como conectar um banco de dados on-premises a uma instância de banco de dados Amazon RDS por meio de uma rede privada virtual (VPN). Para ter mais informações, consulte Configurações de rede para migração de banco de dados.

• Endpoints de origem e de destino: é necessário saber quais informações e tabelas do banco de dados de origem devem ser migradas para o banco de dados de destino. O AWS DMS é compatível com a migração básica de esquemas, incluindo a criação de tabelas e de chaves primárias. No entanto, o AWS DMS não cria automaticamente índices secundários, chaves estrangeiras, contas de usuário etc. no banco de dados de destino. Dependendo do mecanismo dos bancos de dados de origem e de destino, poderá ser necessário configurar registro em log suplementar ou modificar outras configurações de um banco de dados de origem ou de destino. Para obter mais informações, consulte Destinos para a migração de dados e Origens para a migração de dados.

• Migração de esquema e de código: o AWS DMS não faz conversão de esquemas ou de código. É possível utilizar ferramentas, como o Oracle SQL Developer, o MySQL Workbench e o pgAdmin III para converter o esquema. Para converter um esquema existente em um mecanismo de banco de dados diferente, utilize a AWS Schema Conversion Tool (AWS SCT). Ela pode criar um esquema de destino e gerar e criar um esquema inteiro: tabelas, índices, visualizações e assim por diante. Também é possível utilizar a ferramenta para converter PL/SQL ou TSQL para PgSQL e outros formatos. Para obter mais informações sobra a AWS SCT, consulte o Guia do usuário da AWS SCT.

• Tipos de dados incompatíveis: verifique se é possível converter tipos de dados de origem em tipos de dados equivalentes para o banco de dados de destino. Para obter mais informações sobre os tipos de dados compatíveis, consulte a seção de origem ou de destino do datastore.

• Resultados do script de apoio de diagnóstico: ao planejar a migração, é recomendável executar scripts de apoio de diagnóstico. Com os resultados desses scripts, é possível encontrar informações sobre possíveis falhas na migração com antecedência.

  Se um script de apoio estiver disponível para o banco de dados, baixe-o utilizando o link no tópico do script correspondente na seção a seguir. Depois de verificar e analisar o script, é possível executá-lo de acordo com o procedimento descrito no tópico do script em seu ambiente on-premises. Quando a execução do script for concluída, será possível analisar os resultados. É recomendável executar esses scripts como a primeira etapa de qualquer tentativa de solução de problemas. Os resultados podem ser úteis ao trabalhar com uma equipe de AWS Support. Para ter mais informações, consulte Trabalhando com scripts de suporte de diagnóstico em AWS DMS.

• Avaliações de pré-migração: uma avaliação de pré-migração avalia componentes especificados de uma tarefa de migração de banco de dados para ajudar a identificar quaisquer problemas que possam impedir que uma tarefa de migração seja executada conforme o esperado. Ao utilizar essa avaliação, é possível identificar problemas potenciais antes de executar uma tarefa nova ou modificada. Para obter mais informações sobre como trabalhar com avaliações de pré-migração, consulte Ativar e trabalhar com avaliações de pré-migração de uma tarefa.

Conversão de esquemas

O AWS DMS não executa a conversão de esquema ou de código. Para converter um esquema existente em um mecanismo de banco de dados diferente, é possível utilizar a AWS SCT. A AWS SCT converte os objetos, as tabelas, os índices, as visualizações, os acionadores da origem e outros objetos do sistema no formato DDL (linguagem de definição de dados) do destino. Também é possível utilizar a AWS SCT para converter a maior parte do código da aplicação, como PL/SQL ou TSQL, para a linguagem equivalente do destino.

É possível obter a AWS SCT para download gratuito na AWS. Para obter mais informações sobre a AWS SCT, consulte o Guia do usuário da AWS SCT.

Se seus endpoints de origem e destino estiverem no mesmo mecanismo de banco de dados, você poderá usar ferramentas como Oracle SQL Developer, MySQL Workbench PgAdmin ou 4 para mover seu esquema.

Análise da documentação pública do AWS DMS

É altamente recomendável consultar as páginas da documentação pública do AWS DMS de seus endpoints de origem e de destino antes da primeira migração. Essa documentação pode ajudar a identificar os pré-requisitos da migração e a compreender as limitações atuais antes de você começar. Para ter mais informações, consulte Como trabalhar com endpoints do AWS DMS.

Durante a migração, a documentação pública pode ajudar a solucionar qualquer problema com o AWS DMS. As páginas de solução de problemas na documentação podem ajudar a resolver problemas comuns utilizando o AWS DMS e os bancos de dados de endpoints selecionados. Para ter mais informações, consulte Solução de problemas de tarefas de migração no AWS Database Migration Service.

Execução de uma prova de conceito

Para ajudar a descobrir problemas no ambiente nas fases iniciais da migração de banco de dados, é recomendável executar uma pequena migração de teste. Isso também pode ajudar a definir um cronograma de migração mais realista. Além disso, talvez seja necessário executar uma migração de teste em escala total para avaliar se o AWS DMS pode lidar com o throughput do banco de dados na rede. Durante esse período, é recomendável comparar e otimizar a carga máxima inicial e a replicação contínua. Isso pode ajudar a compreender a latência da rede e avaliar o desempenho geral.

Nesse ponto, você também tem a oportunidade de compreender o perfil dos dados e o tamanho do banco de dados, incluindo o seguinte:

• O número de tabelas grandes, médias e pequenas.

• Como o AWS DMS lida com conversões de tipos de dados e conjuntos de caracteres.

• A quantidade de tabelas com colunas de objetos grandes (LOB).

• Quanto tempo é necessário para executar uma migração de teste.

Aprimoramento do desempenho de uma migração do AWS DMS

Diversos fatores afetam o desempenho da migração do AWS DMS:

• Disponibilidade de recursos na origem.

• O throughput disponível da rede.

• A capacidade de recursos do servidor de replicação.

• A capacidade de ingestão de alterações pelo destino.

• O tipo e a distribuição dos dados de origem.

• O número de objetos a serem migrados.

É possível melhorar o desempenho utilizando algumas ou todas as práticas recomendadas mencionadas a seguir. A possibilidade de utilizar uma dessas práticas depende do caso de uso específico. As limitações a seguir podem ser encontradas:

Provisionar um servidor de replicação adequado

O AWS DMS é um serviço gerenciado executado em uma instância do Amazon EC2. O serviço se conecta ao banco de dados de origem, lê os dados de origem, formata os dados para consumo do banco de dados de destino e carrega os dados nesse banco de dados.

A maior parte desse processo ocorre na memória. No entanto, transações grandes podem exigir buffer no disco. Transações armazenadas em cache e arquivos de log também são gravados no disco. Nas seções a seguir, é possível encontrar o que deve ser considerado ao escolher o servidor de replicação.

CPU

O AWS DMS foi projetado para migrações heterogêneas, mas também é compatível com migrações homogêneas. Para executar uma migração homogênea, primeiro converta cada tipo de dados de origem no tipo de dados equivalente do AWS DMS. Converta cada tipo de dados do AWS DMS no tipo de dados de destino. É possível encontrar referências a essas conversões para cada mecanismo de banco de dados no Guia do usuário do AWS DMS.

Para que o AWS DMS execute essas conversões de forma ideal, a CPU deve estar disponível quando as conversões ocorrerem. Sobrecarregar a CPU e não ter recursos suficientes de CPU pode resultar em migrações lentas, o que também pode causar outros efeitos colaterais.

Classe da instância de replicação

Algumas das classes de instância menores são suficientes para testar o serviço ou para migrações pequenas. Se a migração envolver um grande número de tabelas ou se você quiser executar várias tarefas de replicação simultâneas, considere utilizar uma das instâncias maiores. Uma instância maior pode ser uma boa ideia porque o serviço consome uma boa quantidade de memória e de CPU.

As instâncias do tipo T2 são projetadas para fornecer desempenho de linha de base moderado e capacidade de intermitência para obter desempenho significativamente mais alto, conforme necessário para a workload. Elas são destinadas a workloads que não utilizam toda a CPU com frequência ou de forma consistente, mas que às vezes precisam de intermitência. As instâncias T2 são ideais para workloads de uso geral, como servidores web, ambientes de desenvolvedor e bancos de dados pequenos. Se estiver solucionando problemas de uma migração lenta e utilizando um tipo de instância T2, verifique a métrica de utilização de CPU do host. Ela pode mostrar se você está ultrapassando a linha de base desse tipo de instância.

As classes de instância C4 são projetadas para fornecer o mais alto nível de desempenho do processador para workloads de consumo intensivo. Elas alcançam desempenho significativamente mais alto de pacotes por segundo (PPS), jitter de rede mais baixo e latência de rede mais baixa. O AWS DMS pode consumir muita CPU, principalmente ao executar migrações e replicações heterogêneas, como migrar do Oracle para o PostgreSQL. As instâncias C4 podem ser uma boa opção para essas situações.

As classes de instância R4 são otimizadas para memória para workloads de consumo intensivo de memória. As replicações ou migrações contínuas de sistemas de transação de alto throughput que usam o AWS DMS, às vezes, podem consumir grandes quantidades de CPU e de memória. As instâncias R4 incluem mais memória por vCPU.

Suporte do AWS DMS para classes de instâncias R5 e C5

As classes de instâncias R5 otimizadas para memória são projetadas para fornecer desempenho rápido para workloads que processam grandes conjuntos de dados na memória. As replicações ou migrações contínuas de sistemas de transação de alto throughput que usam o AWS DMS, às vezes, podem consumir grandes quantidades de CPU e de memória. As instâncias R5 fornecem 5% a mais de memória por vCPU do que as R4, e o tamanho maior fornece 768 GiB de memória. Além disso, as instâncias R5 fornecem uma melhoria de 10% no preço por GiB e um aumento de aproximadamente 20% no desempenho da CPU em relação às R4.

As classes de instância C5 são otimizadas para cargas de trabalho com uso intensivo de computação e oferecem alto desempenho econômico a um baixo preço por taxa de computação. Elas alcançam um desempenho de rede significativamente maior. O Adaptador de Rede Elástica (ENA) fornece instâncias C5 com até 25 Gbps de largura de banda de rede e até 14 Gbps de largura de banda dedicada para o Amazon EBS. O AWS DMS pode ter um consumo intensivo de CPU, especialmente ao executar migrações e replicações heterogêneas, como a migração do Oracle para o PostgreSQL. As instâncias C5 podem ser uma boa opção para essas situações.

Armazenamento

Dependendo da classe da instância, o servidor de replicação vem com 50 GB ou 100 GB de armazenamento de dados. Esse armazenamento é usado para arquivos de log e para quaisquer alterações em cache coletadas durante a carga. Se o sistema de origem estiver ocupado ou realizar grandes transações, talvez seja necessário aumentar o armazenamento. Ao executar várias tarefas no servidor de replicação, talvez também seja necessário aumentar o armazenamento. No entanto, o valor padrão é geralmente suficiente.

Todos os volumes de armazenamento no AWS DMS são unidades GP2 ou de estado sólido de uso geral (SSDs). Os volumes GP2 vêm com um desempenho básico de três operações de E/S por segundo (IOPS), com capacidade de intermitência até 3.000 IOPS com base em crédito. Como regra geral, verifique as métricas ReadIOPS e WriteIOPS da instância de replicação. Verifique se a soma desses valores não ultrapassa o desempenho básico desse volume.

Multi-AZ

A escolha de uma instância multi-AZ pode proteger a migração contra falhas de armazenamento. A maioria das migrações é transitória e não se destina a ser executada por longos períodos. Ao utilizar o AWS DMS para fins de replicação contínua, a escolha de uma instância multi-AZ pode melhorar a disponibilidade, caso ocorra um problema de armazenamento.

Se ocorrer um failover ou uma substituição do host ao utilizar uma instância de replicação de uma única AZ ou multi-AZ durante uma CARGA MÁXIMA, a tarefa de carga máxima falhará. É possível reiniciar a tarefa a partir do ponto de falha para as tabelas restantes que não foram concluídas ou que estão em estado de erro.

Carregamento de várias tabelas em paralelo

Por padrão, o AWS DMS carrega oito tabelas por vez. É possível ver uma melhora no desempenho aumentando um pouco esse número ao utilizar um servidor de replicação muito grande, como uma instância dms.c4.xlarge ou maior. Contudo, em algum momento, o aumento do paralelismo reduz o desempenho. Se o servidor de replicação for relativamente pequeno, como um dms.t2.medium, é recomendável reduzir o número de tabelas carregadas em paralelo.

Para alterar esse número no AWS Management Console, abra o console, escolha Tarefas, escolha criar ou modificar uma tarefa e Configurações avançadas. Em Configurações de ajuste, altere a opção Número máximo de tabelas para carga em paralelo.

Para alterar esse número utilizando a AWS CLI, altere o parâmetro MaxFullLoadSubTasks em TaskSettings.

Utilização da carga máxima em paralelo

É possível utilizar uma carga paralela de origens do Oracle, do Microsoft SQL Server, do MySQL, do Sybase e do IBM Db2 LUW com base em partições e subpartições. Isso pode melhorar a duração geral da carga máxima. Além disso, ao executar uma tarefa de migração do AWS DMS, é possível acelerar a migração de tabelas grandes ou particionadas. Para isso, divida a tabela em segmentos e carregue os segmentos em paralelo na mesma tarefa de migração.

Para utilizar uma carga paralela, crie uma regra de mapeamento de tabelas do tipo table-settings com a opção parallel-load. Na regra table-settings, especifique os critérios de seleção da tabela ou das tabelas que você quer carregar em paralelo. Para especificar os critérios de seleção, defina o elemento type da parallel-load para uma das seguintes configurações:

• partitions-auto

• subpartitions-auto

• partitions-list

• ranges

• none

Para obter mais informações sobre essas configurações, consulte Regras e operações de configurações de tabelas e coleções.

Como trabalhar com índices, acionadores e restrições de integridade referencial

Índices, acionadores e restrições de integridade referencial podem afetar o desempenho da migração e fazer com que ela falhe. O modo como esses itens afetam a migração depende de se a tarefa de replicação é uma tarefa de carga máxima ou de replicação contínua (captura de dados de alteração ou CDC).

Para uma tarefa de carga máxima, é recomendável ignorar os índices de chave primária, os índices secundários, as restrições de integridade referencial e os acionadores da linguagem de manipulação de dados (DML). Ou você pode atrasar a criação até que as tarefas de carga máxima sejam concluídas. Os índices não são necessários durante uma tarefa de carga máxima e incorrerão em sobrecarga de manutenção se estiverem presentes. Como a tarefa de carga máxima carrega grupos de tabelas por vez, as restrições de integridade referencial são violadas. Do mesmo modo, a inserção, a atualização e a exclusão de acionadores pode causar erros se, por exemplo, uma inserção de linha for acionada para uma tabela carregada em massa anteriormente. Outros tipos de acionadores também afetam o desempenho devido ao processamento adicionado.

Se os volumes de dados forem relativamente pequenos e o tempo de migração adicional não for uma preocupação, será possível criar índices de chave primária e secundários antes de uma tarefa de carga máxima Sempre desative as restrições de integridade referencial e os acionadores.

Para uma tarefa de carga máxima mais CDC, é recomendável adicionar índices secundários antes da fase de CDC. Como o AWS DMS utiliza replicação lógica, verifique se os índices secundários compatíveis com operações DML estão presentes para evitar varreduras de tabelas inteiras. Pause a tarefa de replicação antes da fase de CDC para criar índices e crie restrições de integridade referencial antes de reiniciar a tarefa.

Você deve ativar os acionadores logo antes da substituição.

Desativação dos backups e do log de transações

Ao migrar para um banco de dados Amazon RDS, convém desativar backups e multi-AZ no destino até que você esteja pronto para a transferência. Da mesma forma, ao migrar para sistemas que não sejam o Amazon RDS, convém desativar qualquer registro em log no destino até depois da substituição.

Utilização de várias tarefas

Às vezes, utilizar várias tarefas para uma única migração pode melhorar o desempenho. Quando houver conjuntos de tabelas que não participam de transações comuns, talvez seja possível dividir a migração em várias tarefas. A consistência transacional é mantida em uma tarefa, portanto, é importante que tabelas em tarefas separadas não participem de transações comuns. Além disso, cada tarefa lê o fluxo de transações de forma independente; portanto, tenha cuidado para não sobrecarregar o banco de dados de origem.

É possível utilizar várias tarefas para criar fluxos separados de replicação. Ao fazer isso, é possível paralelizar as leituras na origem, os processos na instância de replicação e as gravações no banco de dados de destino.

Otimização do processamento de alterações

Por padrão, o AWS DMS processa alterações em um modo transacional, que preserva a integridade transacional. Se houver condições para lapsos temporários em integridade transacional, você poderá usar a opção batch optimized apply. Essa opção agrupa transações de maneira eficaz e as aplica em lotes para fins de eficiência. A utilização da opção de aplicação otimizada em lote quase sempre viola as restrições de integridade referencial. Portanto, é recomendável desativar essas restrições durante o processo de migração e ativá-las novamente como parte do processo de substituição.

Utilização do seu próprio servidor de nomes on-premises

Normalmente, uma instância de replicação do AWS DMS utiliza o resolvedor do Sistema de Nomes de Domínio (DNS) em uma instância do Amazon EC2 para resolver os endpoints de domínio. No entanto, é possível utilizar o seu próprio servidor de nomes on-premises para resolver determinados endpoints se você utilizar o Amazon Route 53 Resolver. Com essa ferramenta, é possível consultar entre on-premises e AWS utilizando endpoints de entrada e de saída, regras de encaminhamento e uma conexão privada. Os benefícios de utilizar um servidor de nomes on-premises incluem maior segurança e facilidade de uso por trás de um firewall.

Com endpoints de entrada, é possível utilizar consultas ao DNS originadas on-premises para resolver domínios hospedados pela AWS. Para configurar os endpoints, atribua endereços IP em cada sub-rede para a qual você quer fornecer um resolvedor. Para estabelecer conectividade entre a infraestrutura do DNS on-premises e da AWS, utilize AWS Direct Connect ou uma rede privada virtual (VPN).

Os endpoints de saída se conectam ao servidor de nomes on-premises. O servidor de nomes só concede acesso aos endereços IP incluídos em uma lista de permissões e definidos em um endpoint de saída. O endereço IP do servidor de nomes é o endereço IP de destino. Ao escolher um grupo de segurança para um endpoint de saída, escolha o mesmo grupo de segurança usado pela instância de replicação.

Para encaminhar os domínios selecionados para o servidor de nomes, utilize as regras de encaminhamento. Um endpoint de saída pode processar várias regras de encaminhamento. O escopo da regra de encaminhamento é a nuvem privada virtual (VPC). Ao utilizar uma regra de encaminhamento associada a uma VPC, é possível provisionar uma seção logicamente isolada da nuvem AWS. Nessa seção logicamente isolada, é possível iniciar os recursos da AWS em uma rede virtual.

É possível configurar os domínios hospedados na infraestrutura do DNS on-premises como regras de encaminhamento condicional que configuram consultas ao DNS de saída. Quando uma consulta é feita a um desses domínios, as regras acionam uma tentativa de encaminhar solicitações de DNS para os servidores DNS que foram configurados com as regras. Novamente, é necessária uma conexão privada via AWS Direct Connect ou VPN.

O diagrama a seguir mostra a arquitetura do Route 53 Resolver.

Para obter mais informações sobre o Route 53 DNS Resolver, consulte Conceitos básicos do Route 53 Resolver no Guia do desenvolvedor do Amazon Route 53.

Utilização do Amazon Route 53 Resolver com o AWS DMS

É possível criar um servidor de nomes on-premises para que o AWS DMS resolva endpoints utilizando Amazon Route 53 Resolver.

Como criar um servidor de nomes on-premises para o AWS DMS com base no Route 53

1. Faça login no AWS Management Console e abra o console do Route 53 em https://console.aws.amazon.com/route53/.

2. No console do Route 53, escolha a região da AWS em que você deseja configurar o Route 53 Resolver. O Route 53 Resolver é específico para uma região.

3. Escolha a direção da consulta: entrada, saída ou ambas.

4. Forneça a configuração da consulta de entrada:

   1. Insira um nome de endpoint e escolha uma VPC.

   2. Atribua uma ou mais sub-redes na VPC (por exemplo, escolha duas para aumentar a disponibilidade).

   3. Atribua endereços IP específicos a serem usados como endpoints ou permita que o Route 53 Resolver os atribua automaticamente.

5. Crie uma regra para o domínio on-premises, para que as workloads na VPC possam rotear as consultas ao DNS para a sua infraestrutura de DNS.

6. Insira um ou mais endereços IP para os servidores DNS on-premises.

7. Envie sua regra.

Quando tudo estiver criado, a VPC estará associada às regras de entrada e de saída e poderá iniciar o roteamento do tráfego.

Para obter mais informações sobre o Route 53 Resolver, consulte Conceitos básicos do Route 53 Resolver no Guia do desenvolvedor do Amazon Route 53.

Migração de objetos binários grandes (LOBs)

Em geral, o AWS DMS migra dados de LOB em duas fases:

1. O AWS DMS cria uma nova linha na tabela de destino e preenche a linha com todos os dados, exceto o valor do LOB associado.

2. O AWS DMS atualiza a linha na tabela de destino com os dados de LOB.

Esse processo de migração de LOBs exige que, durante a migração, todas as colunas de LOB na tabela de destino sejam anuláveis. Isso acontece mesmo que as colunas de LOB não sejam anuláveis na tabela de origem. Se o AWS DMS criar as tabelas de destino, ele definirá as colunas de LOB como anuláveis por padrão. Em alguns casos, é possível criar as tabelas de destino utilizando algum outro mecanismo, como importação ou exportação. Nesses casos, verifique se as colunas de LOB são anuláveis antes de iniciar a tarefa de migração.

Esse requisito possui uma exceção. Suponha que você execute uma migração homogênea a partir de uma origem Oracle para um destino Oracle, e escolha Modo LOB limitado. Nesse caso, toda a linha é preenchida de uma só vez, incluindo os valores de LOB. Para esse caso, o AWS DMS pode criar as colunas de LOB da tabela de destino com restrições não anuláveis, se necessário.

Utilização do modo LOB limitado

O AWS DMS utiliza dois métodos que equilibram o desempenho e a conveniência quando a migração contém valores de LOB.

1. O Modo LOB limitado migra todos os valores de LOB até um limite de tamanho especificado pelo usuário (o padrão é 32 KB). Os valores de LOB maiores que o limite de tamanho devem ser migrados manualmente. O Modo LOB limitado, o padrão para todas as tarefas de migração, normalmente fornece o melhor desempenho. No entanto, verifique se o parâmetro Tamanho máximo do LOB está correto. Defina esse parâmetro como o maior tamanho de LOB de todas as tabelas.

2. O Modo LOB completo migra todos os dados de LOB nas tabelas, independentemente do tamanho. O Modo LOB completo fornece a conveniência de mover todos os dados de LOB em suas tabelas, mas o processo pode ter um impacto significativo no desempenho.

Para alguns mecanismos de banco de dados, como o PostgreSQL, o AWS DMS trata tipos de dados JSON como LOBs. Verifique se você escolheu Modo LOB limitado, se a opção Tamanho máximo de LOB está definida como um valor que não trunca os dados JSON.

O AWS DMS oferece suporte total ao uso de tipos de dados de objetos grandes (BLOBs, CLOBs e NCLOBs). Os endpoints de origem a seguir têm suporte completo a LOB:

• Oracle

• Microsoft SQL Server

• ODBC

Os endpoints de destino a seguir têm suporte completo a LOB:

• Oracle

• Microsoft SQL Server

O endpoint de destino a seguir tem suporte limitado a LOB. Não é possível utilizar um tamanho ilimitado de LOB para esse endpoint de destino.

• Amazon Redshift

• Amazon S3

Para os endpoints que têm suporte completo a LOB, também é possível definir um limite de tamanho para tipos de dados de LOB.

Desempenho de LOB aprimorado

Ao migrar dados de LOB, é possível especificar as seguintes configurações diferentes de otimização de LOB.

Configurações de LOB por tabela

Utilizando as configurações de LOB por tabela, é possível substituir as configurações de LOB em nível de tarefa para algumas ou todas as tabelas. Para fazer isso, defina lob-settings na regra table-settings. Veja a seguir um exemplo de tabela que inclui alguns valores grandes de LOB.

SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

Crie uma tarefa de migração e modifique o tratamento de LOB da tabela utilizando a nova regra lob-settings. O valor de bulk-max-siz determina o tamanho máximo de LOB (KB). Ele será truncado se for maior que o tamanho especificado.

{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

Mesmo que essa tarefa do AWS DMS seja criada com FullLobMode : true, as configurações de LOB por tabela direcionam o AWS DMS a truncar os dados de LOB nessa tabela específica para 16.000. É possível verificar os logs de tarefas para confirmar isso.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

Configurações de LOB em linha

Ao criar uma tarefa do AWS DMS, o modo LOB determina como os LOBs são processados.

Com o modo LOB completo e o modo LOB limitado. Cada um tem suas próprias vantagens e desvantagens. O modo LOB em linha combina as vantagens do modo LOB completo e do modo LOB limitado.

É possível utilizar o modo LOB em linha quando for necessário replicar LOBs pequenos e grandes, e a maioria dos LOBs forem pequenos. Ao escolher essa opção, durante a carga máxima, a tarefa do AWS DMS transfere os pequenos LOBs em linha, o que é mais eficiente. A tarefa do AWS DMS transfere os LOBs grandes executando uma pesquisa na tabela de origem.

Durante o processamento de alterações, LOBs pequenos e grandes são replicados executando uma pesquisa na tabela de origem.

Ao utilizar o modo LOB em linha, a tarefa do AWS DMS verifica todos os tamanhos de LOB para determinar quais devem ser transferidos em linha. LOBs maiores que o tamanho especificado são replicados utilizando o modo LOB completo. Portanto, se você sabe que a maioria dos LOBs é maior que a configuração especificada, é melhor não utilizar essa opção. Em vez disso, permita um tamanho de LOB ilimitado.

Configure essa opção utilizando um atributo nas configurações da tarefaInlineLobMaxSize, que só está disponível quando FullLobMode está definido como true. O valor padrão de InlineLobMaxSize é 0, e o intervalo é de 1 a 102400 kilobytes (100 MB).

Por exemplo, é possível utilizar as seguintes configurações da tarefa AWS DMS. Aqui, a configuração de InlineLobMaxSize como um valor de 5 resulta em todos os LOBs menores que ou iguais a 5 KiB (5.120 bytes) sendo transferidos em linha.

{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

Melhoria do desempenho ao migrar tabelas grandes utilizando filtragem de linhas

Para melhorar o desempenho ao migrar uma tabela grande, é possível dividir a migração em mais de uma tarefa. Para dividir a migração em várias tarefas utilizando a filtragem de linhas, utilize uma chave ou uma chave de partição. Por exemplo, se tiver um ID de chave primária do tipo inteiro de 1 a 8.000.000, é possível criar oito tarefas utilizando a filtragem de linha para migrar um milhão de registros em cada.

Para aplicar a filtragem de linhas no console:

1. Abra a AWS Management Console.

2. Escolha Tarefas e crie uma nova tarefa.

3. Escolha a guia Mapeamentos de tabela e expanda a guia Regras de seleção.

4. Escolha Adicionar nova regra de seleção. Agora é possível adicionar um filtro de colunas com menor que ou igual a, maior que ou igual a, igual a ou uma condição de intervalo entre dois valores. Para obter mais informações sobre a filtragem de colunas, consulte Especificar a seleção de tabelas e as regras de transformação no console.

Se você tiver um grande tabela particionada por data, poderá migrar os dados com base em data. Por exemplo, suponha que você tenha uma tabela particionada por mês e somente os dados do mês atual estão atualizados. Nesse caso, é possível criar uma tarefa de carga máxima para cada partição mensal estática e criar uma tarefa de carga máxima CDC para a partição atualizada atualmente.

Se a tabela tiver uma chave primária de coluna única ou um índice exclusivo, você poderá fazer com que a tarefa do AWS DMS segmente a tabela utilizando uma carga paralela do tipo de intervalos para carregar os dados em paralelo. Para ter mais informações, consulte Regras e operações de configurações de tabelas e coleções.

Replicação contínua

O AWS DMS fornece replicação contínua de dados, mantendo os bancos de dados de origem e de destino em sincronia. Ele replica apenas uma quantidade limitada de instruções da linguagem de definição de dados (DDL). O AWS DMS não propaga itens como índices, usuários, privilégios, procedimentos armazenados e outras alterações de banco de dados não relacionadas diretamente a dados de tabela.

Ao planejar utilizar a replicação contínua, defina a opção Multi-AZ ao criar a instância de replicação. Ao escolher a opção Multi-AZ, você obtém alta disponibilidade e suporte a failover para a instância de replicação. No entanto, essa opção pode ter um impacto no desempenho e retardar a replicação ao aplicar alterações no sistema de destino.

Antes de atualizar os bancos de dados de origem ou de destino, é recomendável interromper todas as tarefas do AWS DMS que estão sendo executadas nesses bancos de dados. Retome as tarefas após concluir as atualizações.

Durante a replicação contínua, é essencial identificar a largura de banda da rede entre o sistema de banco de dados de origem e a instância de replicação do AWS DMS. Verifique se a rede não causa gargalos durante a replicação contínua.

Também é importante identificar a taxa de alterações e a geração do log de arquivamento por hora no sistema de banco de dados de origem. Isso pode ajudar a compreender o throughput que pode ser obtido durante a replicação contínua.

Redução da carga no banco de dados de origem

O AWS DMS utiliza alguns recursos no banco de dados de origem. Durante uma tarefa de carga máxima, o AWS DMS executa uma varredura total da tabela de origem de cada tabela processada em paralelo. Além disso, cada tarefa criada como parte de uma migração consulta a origem em busca de alterações como parte do processo de CDC. Para que o AWS DMS execute a CDC para algumas origens, como o Oracle, poderá ser necessário aumentar a quantidade de dados gravados no log de alterações do bancos de dados.

Se você descobrir que está sobrecarregando o banco de dados de origem, será possível reduzir o número de tarefas ou de tabelas de cada tarefa da migração. Cada tarefa obtém as alterações de origem de forma independente, portanto a consolidação das tarefas pode diminuir a workload da captura de alterações.

Reduzir os gargalos no banco de dados de destino

Durante a migração, tente remover todos os processos que competem por recursos de gravação no banco de dados de destino:

• Desative os acionadores desnecessários.

• Desative os índices secundários durante a carga inicial e ative-os posteriormente durante a replicação contínua.

• Com os bancos de dados do Amazon RDS, é uma boa ideia desativar os backups e o multi-AZ até a substituição.

• Ao migrar para sistemas não RDS, é uma boa ideia desativar qualquer log no destino até a substituição.

Utilização da validação de dados durante a migração

Para garantir que os dados foram migrados com precisão da origem para o destino, é altamente recomendável utilizar a validação de dados. Se você ativar a validação de dados de uma tarefa, o AWS DMS começará a comparar os dados de origem e de destino imediatamente após a execução da carga máxima de uma tabela.

A validação de dados funciona com os seguintes bancos de dados sempre que o AWS DMS é compatível com eles como endpoints de origem e de destino:

• Oracle

• PostgreSQL

• MySQL

• MariaDB

• Microsoft SQL Server

• Amazon Aurora Edição Compatível com MySQL

• Amazon Aurora Edição Compatível com PostgreSQL

• IBM Db2 LUW

• Amazon Redshift

Para ter mais informações, consulte AWS Validação de dados do DMS.

Monitoramento das tarefas do AWS DMS utilizando métricas

Há várias opções para monitorar as métricas das tarefas utilizando o console do AWS DMS:

Métricas de host

Você pode encontrar métricas do host na guia de CloudWatch métricas de cada instância de replicação específica. Aqui, é possível monitorar se a instância de replicação está dimensionada de forma adequada.

Métricas de tarefas de replicação

Métricas para tarefas de replicação, incluindo alterações recebidas e confirmadas, e latência entre o host de replicação e os bancos de dados de origem/destino, podem ser encontradas na guia de métricas de cada tarefa específica. CloudWatch

Métricas de tabela

É possível descobrir as métricas de tabela individuais na guia Estatísticas da tabela de cada tarefa individual. Essas métricas incluem os números de:

• Linhas carregadas durante a carga máxima.

• Inserções, atualizações e exclusões desde o início da tarefa.

• Operações de DDL desde o início da tarefa.

Para obter mais informações sobre o monitoramento de métricas, consulte AWS DMSTarefas de monitoramento.

Eventos e notificações

O AWS DMS utiliza o Amazon SNS para fornecer notificações sobre um evento ocorrido no AWS DMS, por exemplo, a criação ou a exclusão de uma instância de replicação. É possível trabalhar com essas notificações em qualquer formato compatível com o Amazon SNS de uma região da AWS. Isso pode incluir mensagens de e-mail, mensagens de texto ou chamadas para um endpoint HTTP.

Para ter mais informações, consulte Como trabalhar com eventos e notificações do Amazon SNS no AWS Database Migration Service.

Utilização do log de tarefas para solucionar problemas de migração

Em alguns casos, o AWS DMS pode encontrar problemas para os quais os avisos ou as mensagens de erro aparecem somente no log de tarefas. Especificamente, os problemas de truncamento de dados ou de rejeições de linhas devido a violações de chave estrangeira só são gravados no log de tarefas. Portanto, analise o log de tarefas ao migrar um banco de dados. Para visualizar o registro de tarefas, configure a Amazon CloudWatch como parte da criação da tarefa.

Para obter mais informações, consulte Monitoramento de tarefas de replicação usando a Amazon CloudWatch.

Solução de problemas de tarefas de replicação com o Time Travel

Para solucionar problemas de migração do AWS DMS, é possível trabalhar com o Time Travel. Para obter mais informações sobre o Time Travel, consulte Configurações de tarefa do Time Travel.

Ao trabalhar com o Time Travel, lembre-se das seguintes considerações:

• Para evitar sobrecarga em uma instância de replicação do DMS, ative o Time Travel somente para tarefas que precisam de depuração.

• Ao utilizar o Time Travel para solucionar problemas de tarefas de replicação que podem ser executadas por vários dias, monitore as métricas da instância de replicação quanto à sobrecarga de recursos. Essa abordagem se aplica especialmente aos casos em que altas cargas de transações são executadas nos bancos de dados de origem por longos períodos. Para obter mais detalhes, consulte AWS DMSTarefas de monitoramento.

• Quando a configuração EnableRawData da tarefa do Time Travel está definida comotrue, o uso da memória da tarefa durante a replicação do DMS pode ser maior do que quando o Time Travel não está ativado. Se você ativar a Viagem no Tempo por longos períodos, monitore a tarefa.

• Atualmente, é possível ativar o Time Travel somente no nível de tarefa. As alterações em todas as tabelas são registradas nos logs do Time Travel. Se estiver solucionando problemas de tabelas específicas em um banco de dados com alto volume de transações, crie uma tarefa separada.

Alteração de usuário e de esquema de um destino do Oracle

Ao utilizar o Oracle como destino, o AWS DMS migra os dados para o esquema de propriedade do usuário do endpoint de destino.

Por exemplo, suponha que você esteja migrando um esquema chamado PERFDATA para um endpoint de destino do Oracle, e que o nome do usuário do endpoint de destino seja MASTER. O AWS DMS se conectará ao destino do Oracle como MASTER, e preencherá o esquema MASTER com objetos do banco de dados PERFDATA.

Para substituir esse comportamento, forneça uma transformação de esquema. Por exemplo, para migrar os objetos do esquema PERFDATA para um esquema PERFDATA no endpoint de destino, utilize a seguinte transformação:

{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

Para obter mais informações sobre transformações, consulte Especificar a seleção de tabelas e as regras de transformação utilizando JSON.

Alteração de espaços para tabela de índice e de tabela para um destino do Oracle

Quando o Oracle é usado como destino, o AWS DMS migra todas as tabelas e índices para o espaço para tabela padrão no destino. Por exemplo, suponha que a origem seja um mecanismo de banco de dados diferente do Oracle. Todas as tabelas e índices de destino são migrados para o mesmo espaço para tabela padrão.

Para substituir esse comportamento, forneça transformações de espaço para tabela correspondentes. Por exemplo, suponha que você queira migrar tabelas e índices para espaços para tabela de índices e de tabelas no destino do Oracle que têm o mesmo nome do esquema na origem. Nesse caso, é possível utilizar transformações semelhantes às seguintes. Aqui, o esquema na origem é chamado INVENTORY, e os espaços para tabela de índices e de tabelas correspondentes no destino são chamados INVENTORYTBL e INVENTORYIDX.

{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

Para obter mais informações sobre transformações, consulte Especificar a seleção de tabelas e as regras de transformação utilizando JSON.

Quando o Oracle é a origem e o destino, é possível preservar as atribuições de espaço para tabela de índice ou de tabela existente definindo o atributo enableHomogenousTablespace=true de conexão extra da origem do Oracle. Para ter mais informações, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.

Atualização de uma versão de instância de replicação

A AWS lança periodicamente novas versões do software do mecanismo de replicação do AWS DMS, com novos recursos e melhorias de desempenho. Cada versão do software do mecanismo de replicação tem seu próprio número de versão. É essencial testar a versão existente da instância de replicação do AWS DMS executando uma workload de produção antes de atualizar a instância de replicação para uma versão posterior. Para obter mais informações sobre upgrades de versões disponíveis, consulte AWS DMSnotas de lançamento.

Compreender o custo da migração

O AWS Database Migration Service ajuda a migrar bancos de dados para a AWS de forma fácil e econômica. Você paga somente pelas instâncias de replicação e por qualquer armazenamento de log adicional. Cada instância de migração de banco de dados inclui armazenamento suficiente para espaço de troca, logs de replicação e cache de dados para a maioria das replicações, e a transferência de dados de entrada é gratuita.

Talvez sejam necessários mais recursos durante a carga inicial ou durante o horário de pico de carga. É possível monitorar estreitamente a utilização dos recursos da instância de replicação utilizando as métricas do Cloud Watch. É possível aumentar e reduzir a escala verticalmente do tamanho da instância de replicação com base no uso.

Para obter mais informações sobre como estimar os custos da migração, consulte:

• Preços do AWS Database Migration Service

• Calculadora de preços da AWS