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

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:

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:

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

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

É 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:

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.

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:

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.

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:

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

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.

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.

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:

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:

Para ter mais informações, consulte Validação de dados do AWS 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:

Para obter mais informações sobre o monitoramento de métricas, consulte Monitoramento de tarefas do AWS DMS.

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:

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 Notas de versão do DMS.

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: