Melhores recomendadas para o AWS Database Migration Service - AWS Database Migration Service

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

Melhores recomendadas para o AWS Database Migration Service

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

Planejamento de migração para o AWS Database Migration Service

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

  • Para conectar seus bancos de dados de origem e destino a umAWS DMSinstância de replicação, você configura uma rede. Fazer isso pode ser tão simples quanto conectar doisAWSrecursos na mesma nuvem privada virtual (VPC) da sua instância de replicação. Ele pode variar para configurações mais complexas, como conectar um banco de dados local a uma instância de banco de dados Amazon RDS por meio de uma rede privada virtual (VPN). Para obter mais informações, consulte Configurações de rede para migração de banco de dados.

  • Endpoints de origem e destino— Certifique-se de saber quais informações e tabelas no banco de dados de origem precisam ser migradas para o banco de dados de destino.AWS DMSsuporta a migração básica de esquemas, incluindo a criação de tabelas e chaves primárias. No entanto,AWS DMSnão cria automaticamente índices secundários, chaves estrangeiras, contas de usuário e assim por diante no banco de dados de destino. Dependendo do mecanismo do banco de dados de origem e destino, talvez seja necessário configurar o registro suplementar ou modificar outras configurações de um banco de dados de origem ou destino. Para ter mais informações, consulte Origens para a migração de dados e Destinos para a migração de dados.

  • Migração de esquema e código—AWS DMSnão realiza conversão de esquema ou código. Você pode usar ferramentas como Oracle SQL Developer, MySQL Workbench e pgAdmin III para converter seu esquema. Para converter um esquema existente em um mecanismo de banco de dados diferente, você pode usar oAWS Schema Conversion Tool(AWS SCT). Ele 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 usar a ferramenta para converter PL/SQL ou TSQL para PgSQL e outros formatos. Para obter mais informações sobre oAWS SCT, veja oAWS SCTGuia do usuário.

  • Tipos de dados não suportados— Certifique-se de que você possa converter os 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 destino do seu armazenamento de dados.

  • Resultados do script de suporte de diagnóstico— Ao planejar sua migração, recomendamos que você execute scripts de suporte de diagnóstico. Com os resultados desses scripts, você pode encontrar informações antecipadas sobre possíveis falhas na migração.

    Se um script de suporte estiver disponível para seu banco de dados, baixe-o usando o link no tópico do script correspondente na seção a seguir. Depois de verificar e revisar o script, você pode executá-lo de acordo com o procedimento descrito no tópico do script em seu ambiente local. Quando a execução do script estiver concluída, você poderá revisar os resultados. Recomendamos executar esses scripts como primeira etapa de qualquer esforço de solução de problemas. Os resultados podem ser úteis ao trabalhar com umAWS Supportequipe. Para obter mais informações, consulte Trabalhando com scripts de suporte de diagnóstico emAWS DMS.

  • Avaliações de pré-migração— UMAavaliação de pré-migraçãoavalia componentes específicos 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. Usando essa avaliação, você pode identificar possíveis problemas antes de executar uma tarefa nova ou modificada. Para obter mais informações sobre como trabalhar com avaliações de pré-migração, consulteHabilitando e trabalhando com avaliações de pré-migração para uma tarefa.

Converter o esquema

O AWS DMS não realiza conversão de esquema ou de código. Se você quiser converter um esquema existente em um mecanismo de banco de dados diferente, você pode usarAWS SCT.AWS SCTconverte seus objetos de origem, tabela, índices, visualizações, acionadores e outros objetos do sistema no formato de linguagem de definição de dados (DDL) de destino. Você também pode usarAWS SCTpara converter a maior parte do código do seu aplicativo, como PL/SQL ou TSQL, para o idioma de destino equivalente.

Você pode obterAWS SCTcomo um download gratuito deAWS. Para obter mais informações em AWS SCT, consulte o Guia do usuário 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 ouPgAdmin4 para mover seu esquema.

Analisando oAWS DMSdocumentação pública

É altamente recomendável que você passe peloAWS DMSpáginas de documentação pública para seus endpoints de origem e destino antes da primeira migração. Essa documentação pode ajudar você a identificar os pré-requisitos para a migração e entender as limitações atuais antes de começar. Para obter mais informações, consulte Trabalhando comAWSEndpoints do DMS.

Durante a migração, a documentação pública pode ajudá-lo a solucionar quaisquer problemas comAWS DMS. As páginas de solução de problemas na documentação podem ajudá-lo a resolver problemas comuns usando os doisAWS DMSe bancos de dados de endpoints selecionados. Para obter mais informações, consulte Solução de problemas de tarefas de migração no AWS Database Migration Service.

Executando uma prova de conceito

Para ajudar a descobrir problemas com seu ambiente nas fases iniciais da migração do banco de dados, recomendamos que você execute um pequeno teste de migração. Isso também pode ajudar você a definir um cronograma de migração mais realista. Além disso, talvez seja necessário executar uma migração de teste em grande escala para medir seAWS DMSpode lidar com a taxa de transferência do seu banco de dados em sua rede. Durante esse período, recomendamos comparar e otimizar sua carga total inicial e a replicação contínua. Isso pode ajudar você a entender a latência da sua rede e avaliar o desempenho geral.

Neste momento, você também tem a oportunidade de entender seu perfil de dados e o tamanho do seu banco de dados, incluindo o seguinte:

  • Quantas mesas são grandes, médias e pequenas.

  • ComoAWS DMSlida com conversões de tipos de dados e conjuntos de caracteres.

  • Quantas tabelas têm 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 fonte.

  • A taxa de transferência de rede disponível.

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

  • A capacidade do alvo de ingerir mudanças.

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

  • O número de objetos a serem migrados.

Melhore o desempenho usando algumas ou todas as melhores práticas mencionadas a seguir. Se você pode usar uma dessas práticas depende do seu caso de uso específico. Você pode encontrar algumas limitações a seguir:

Provisionando um servidor de replicação adequado

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

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, você pode descobrir o que considerar ao escolher seu servidor de replicação.

CPU

AWS DMSfoi projetado para migrações heterogêneas, mas também oferece suporte a migrações homogêneas. Para realizar uma migração homogênea, primeiro converta cada tipo de dados de origem em seu equivalenteAWS DMStipo de dados. Em seguida, converta cadaAWS DMSdigite dados no tipo de dados de destino. Você pode encontrar referências para essas conversões para cada mecanismo de banco de dados noAWS DMSGuia do usuário.

ParaAWS DMSpara realizar essas conversões de forma otimizada, a CPU deve estar disponível quando as conversões acontecerem. Sobrecarregar a CPU e não ter recursos de CPU suficientes pode resultar em migrações lentas, o que também pode causar outros efeitos colaterais.

Classe de 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 sua migração envolver um grande número de tabelas ou se você pretende executar várias tarefas de replicação simultâneas, considere usar uma das instâncias maiores. Uma instância maior pode ser uma boa ideia porque o serviço consome uma quantidade razoável de memória e CPU.

As instâncias do tipo T2 são projetadas para fornecer desempenho básico moderado e a capacidade de atingir um desempenho significativamente maior, conforme exigido por sua carga de trabalho. Eles são destinados a cargas de trabalho que não usam a CPU completa com frequência ou de forma consistente, mas que ocasionalmente precisam explodir. As instâncias T2 são adequadas para cargas de trabalho de uso geral, como servidores web, ambientes de desenvolvedores e pequenos bancos de dados. Se você estiver solucionando problemas de uma migração lenta e usando um tipo de instância T2, verifique a métrica de utilização da CPU do host. Ele 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 de processador para cargas de trabalho intensivas. Eles alcançam um desempenho significativamente maior de pacotes por segundo (PPS), menor oscilação de rede e menor latência de rede.AWS DMSpode consumir muita CPU, especialmente ao realizar migrações e replicações heterogêneas, como a migração 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 possuem otimização de memória para cargas de trabalho intensivas do ponto de vista de memória. Migrações ou replicações contínuas de sistemas de transações de alto rendimento usandoAWS DMSpode, às vezes, consumir grandes quantidades de CPU e memória. As instâncias R4 incluem mais memória por vCPU.

AWS DMSsuporte para classes de instância R5 e C5

As classes de instância R5 são instâncias otimizadas para memória, projetadas para oferecer desempenho rápido para cargas de trabalho que processam grandes conjuntos de dados na memória. Migrações ou replicações contínuas de sistemas de transações de alto rendimento usandoAWS DMSpode, às vezes, consumir grandes quantidades de CPU e memória. As instâncias R5 fornecem 5% a mais de memória por vCPU do que as R4, e o maior tamanho fornece 768 GiB de memória. Além disso, as instâncias R5 oferecem uma melhoria de preço de 10% por GiB e um aumento de ~ 20% no desempenho da CPU em relação ao R4.

As classes de instância C5 são otimizadas para cargas de trabalho de computação intensiva e oferecem alto desempenho econômico a uma baixa relação preço/computação. Eles alcançam um desempenho de rede significativamente maior. O Elastic Network Adapter (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.AWS DMSpode consumir muita CPU, especialmente ao realizar 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, seu servidor de replicação vem com 50 GB ou 100 GB de armazenamento de dados. Esse armazenamento é usado para arquivos de log e quaisquer alterações em cache coletadas durante o carregamento. Se seu sistema de origem estiver ocupado ou receber grandes transações, talvez seja necessário aumentar seu armazenamento. Se você estiver executando várias tarefas no servidor de replicação, talvez também precise aumentar o armazenamento. No entanto, o valor padrão geralmente é suficiente.

Todos os volumes de armazenamento emAWS DMSsão unidades de estado sólido (SSDs) GP2 ou de uso geral. Os volumes GP2 vêm com um desempenho básico de três operações de I/O por segundo (IOPS), com capacidade de estourar até 3.000 IOPS com base em crédito. Como regra geral, verifique oReadIOPSeWriteIOPSmétricas para a instância de replicação. Certifique-se de que a soma desses valores não ultrapasse o desempenho básico desse volume.

Multi-AZ

A escolha de uma instância Multi-AZ pode proteger sua 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 de tempo. Se você usaAWS DMSpara fins de replicação contínua, escolher uma instância Multi-AZ pode melhorar sua disponibilidade caso ocorra um problema de armazenamento.

Ao usar uma única instância de replicação AZ ou Multi-AZ durante uma CARGA COMPLETA e ocorre um failover ou substituição do host, espera-se que a tarefa de carga total falhe. Você pode reiniciar a tarefa a partir do ponto de falha para as tabelas restantes que não foram concluídas ou estão em estado de erro.

Carregando 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 usar um servidor de replicação muito grande, como uma instância dms.c4.xlarge ou maior. Contudo, em um certo ponto, o aumento do paralelismo reduz o desempenho. Se o seu servidor de replicação é relativamente pequeno, como um dms.t2.medium, recomendamos que reduza o número de tabelas carregadas em paralelo.

Para alterar esse número naAWS Management Console, abra o console, escolhaTarefas, escolha criar ou modificar uma tarefa e, em seguida, escolhaConfigurações avançadas. Em Tuning Settings (Configurações de ajuste), altere a opção Maximum number of tables to load in parallel (Número máximo de tabelas para carregamento em paralelo).

Para alterar esse número usando oAWS CLI, altere oMaxFullLoadSubTasksparâmetro abaixoTaskSettings.

Usando carga total paralela

Você pode usar uma carga paralela de fontes Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW com base em partições e subpartições. Isso pode melhorar a duração geral da carga total. Além disso, ao executar umAWS DMStarefa de migração, você pode acelerar a migração de tabelas grandes ou particionadas. Para fazer isso, divida a tabela em segmentos e carregue os segmentos em paralelo na mesma tarefa de migração.

Para usar uma carga paralela, crie uma regra de mapeamento de tabela do tipotable-settingscom oparallel-loadopção. Dentro dotable-settingsregra, especifique os critérios de seleção para a tabela ou tabelas que você deseja carregar em paralelo. Para especificar os critérios de seleção, definatypeelemento paraparallel-loadpara uma das seguintes configurações:

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

Para obter mais informações sobre essas configurações, consulteRegras e operações de configurações de tabela e coleção.

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

Índices, gatilhos e restrições de integridade referencial podem afetar o desempenho da migração e fazer com que ela falhe. A forma como elas afetam a migração depende de sua tarefa de replicação ser uma tarefa de carga total ou uma tarefa de replicação contínua (captura de dados de alteração ou CDC).

Para uma tarefa de carregamento total, recomendamos que esqueça os índices de chave primária, índices secundários, restrições de integridade referencial e gatilhos da linguagem de manipulação de dados (DML). Ou você pode atrasar a criação deles até que as tarefas de carga completa sejam concluídas. Você não precisa de índices durante uma tarefa de carregamento completo, e os índices incorrem em sobrecarga de manutenção se estiverem presentes. Como a tarefa de carregamento total carrega grupos de tabelas por vez, as restrições de integridade referencial são violadas. Da mesma forma, os acionadores de inserção, atualização e exclusão podem causar erros, por exemplo, se uma inserção de linha for acionada para uma tabela previamente carregada em massa. Outros tipos de gatilhos também afetam o desempenho devido ao processamento adicional.

Se seus volumes de dados forem relativamente pequenos e o tempo adicional de migração não lhe interessar, você poderá criar índices primários e secundários antes de uma tarefa de carregamento completo. Sempre desative as restrições e os gatilhos de integridade referencial.

Para uma tarefa de carga completa mais CDC, recomendamos que você adicione índices secundários antes da fase CDC. PorqueAWS DMSusa replicação lógica, certifique-se de que os índices secundários que oferecem suporte às operações DML estejam em vigor para evitar a varredura completa da tabela. Você pode pausar a tarefa de replicação antes da fase do CDC para criar índices e criar restrições de integridade referencial antes de reiniciar a tarefa.

Você deve ativar os gatilhos logo antes da transição.

Desative os backups e o registro de transações

Ao migrar para um banco de dados do Amazon RDS, é uma boa ideia desativar os backups e o Multi-AZ no destino até que você esteja pronto para fazer a transferência. Da mesma forma, ao migrar para sistemas diferentes do Amazon RDS, desligar qualquer registro no destino até depois da transferência geralmente é uma boa ideia.

Use várias tarefas

Às vezes, usar várias tarefas para uma única migração pode melhorar o desempenho. Se você tiver conjuntos de tabelas que não participam de transações comuns, talvez seja possível dividir sua migração em várias tarefas. A consistência transacional é mantida em uma tarefa, por isso é 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, tome cuidado para não sobrecarregar demais o banco de dados de origem.

Você pode usar várias tarefas para criar fluxos separados de replicação. Ao fazer isso, você pode paralelizar as leituras na origem, os processos na instância de replicação e as gravações no banco de dados de destino.

Otimizando o processamento de mudanças

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. Usar a opção de aplicação otimizada em lote quase sempre viola as restrições de integridade referencial. Portanto, recomendamos que você desative essas restrições durante o processo de migração e as ative novamente como parte do processo de transferência.

Usar seu próprio servidor de nomes no local

Normalmente, umAWS DMSA instância de replicação usa o resolvedor do Sistema de Nomes de Domínio (DNS) em uma instância do Amazon EC2 para resolver endpoints de domínio. No entanto, você pode usar seu próprio servidor de nomes local para resolver determinados endpoints se você usar o Amazon Route 53 Resolver. Com essa ferramenta, você pode consultar entre locais eAWSusando endpoints de entrada e saída, regras de encaminhamento e uma conexão privada. Os benefícios de usar um servidor de nomes local incluem maior segurança e facilidade de uso por trás de um firewall.

Se você tiver endpoints de entrada, poderá usar consultas de DNS originadas no local para resolverAWS-domínios hospedados. Para configurar os endpoints, atribua endereços IP em cada sub-rede que você deseja fornecer a um resolvedor. Para estabelecer a conectividade entre sua infraestrutura de DNS local eAWS, useAWS Direct Connectou uma rede privada virtual (VPN).

Os endpoints de saída se conectam ao seu servidor de nomes local. 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 domínios selecionados para o servidor de nomes, use as regras de encaminhamento. Um endpoint de saída pode lidar com várias regras de encaminhamento. O escopo da regra de encaminhamento é sua nuvem privada virtual (VPC). Usando uma regra de encaminhamento associada a uma VPC, você pode provisionar uma seção logicamente isolada doAWSNuvem. A partir desta seção logicamente isolada, você pode iniciarAWSrecursos em uma rede virtual.

Você pode configurar domínios hospedados em sua infraestrutura de DNS local como regras de encaminhamento condicional que configuram consultas de DNS de saída. Quando uma consulta é feita em um desses domínios, as regras acionam uma tentativa de encaminhar solicitações de DNS para servidores que foram configurados com as regras. Novamente, uma conexão privada acabouAWS Direct Connectou VPN é necessário.

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


                Arquitetura do Resolvedor do Rou

Para obter mais informações sobre o Resolvedor de DNS do Route 53, consulteComeçando com o Route 53 ResolvernaGuia do desenvolvedor do Amazon Route 53.

Usando o Amazon Route 53 Resolver comAWS DMS

Você pode criar um servidor de nomes local paraAWS DMSpara resolver endpoints usandoAmazon Route 53 Resolver.

Para criar um servidor de nomes local paraAWS DMSbaseado na 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, escolhaAWSRegião onde você deseja configurar seu Resolvedor do Route 53. O Resolvedor do Route 53 é específico para uma região.

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

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

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

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

    3. Atribua endereços IP específicos para usar como endpoints ou faça com que o Resolvedor do Route 53 os atribua automaticamente.

  5. Crie uma regra para seu domínio no local, para que as cargas de trabalho dentro da VPC possam rotear as consultas de DNS para sua infraestrutura de DNS.

  6. Insira um ou mais endereços IP para seus servidores DNS locais.

  7. Envie sua regra.

Quando tudo é criado, sua VPC é associada às suas regras de entrada e saída e pode começar a rotear o tráfego.

Para obter mais informações sobre o Route 53 Resolver, consulteComeçando com o Route 53 ResolvernaGuia do desenvolvedor do Amazon Route 53.

Migrar Large Binary Objects (LOBs, Objetos binários grandes)

Em geral,AWS DMSmigra dados 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 para 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, você pode criar as tabelas de destino usando algum outro mecanismo, como importação ou exportação. Nesses casos, certifique-se de que as colunas LOB sejam anuláveis antes de iniciar a tarefa de migração.

Esse requisite possui uma exceção. Suponha que você realize uma migração homogênea a partir de uma origem Oracle para um destino Oracle, e escolha Limited Lob mode (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.

Usar o modo LOB limitado

AWS DMSusa dois métodos que equilibram desempenho e conveniência quando sua migração contém valores de LOB:

  1. O Limited LOB mode (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 Limited LOB mode (Modo LOB limitado), padrão para todas as tarefas de migração, normalmente oferece o melhor desempenho. No entanto, assegure-se de que oTamanho máximo do LOBa configuração do parâmetro está correta. Defina esse parâmetro como o maior tamanho de LOB para todas as suas tabelas.

  2. O Full LOB mode (Modo LOB completo) migra todos os dados de LOB nas tabelas, independentemente do tamanho. O Full LOB mode oferece 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 PostgreSQL, o AWS DMS trata tipos de dados JSON como LOBs. Certifique-se de que, se você escolherModo LOB limitado, oTamanho máximo do LOBA opção é definida como um valor que não faz com que os dados JSON sejam truncados.

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 usar 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, você pode especificar as seguintes configurações diferentes de otimização de LOB.

Configurações de LOB por tabela

Usando as configurações de LOB por tabela, você pode substituir as configurações de LOB em nível de tarefa para algumas ou todas as suas tabelas. Para fazer isso, defina olob-settingsno seutable-settingsregra. Veja a seguir um exemplo de tabela que inclui alguns grandes valores 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

Em seguida, crie uma tarefa de migração e modifique o tratamento de LOB para sua tabela usando o novolob-settingsregra. Obulk-max-sizO valor determina o tamanho máximo do LOB (KB). É 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 issoAWS DMSa tarefa é criada comFullLobMode : true, as configurações de LOB por tabela são diretasAWS DMSpara truncar os dados LOB nessa tabela específica para 16.000. Você pode verificar os registros 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

Quando você cria umAWS DMStarefa, o modo LOB determina como os LOBs são tratados.

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.

Você pode usar o modo LOB embutido quando precisar replicar LOBs pequenos e grandes, e a maioria dos LOBs são pequenos. Quando você escolhe essa opção, durante a carga total, oAWS DMSA tarefa transfere os pequenos LOBs em linha, o que é mais eficiente. OAWS DMSA tarefa transfere os LOBs grandes executando uma pesquisa na tabela de origem.

Durante o processamento de alterações, tanto os LOBs pequenos quanto os grandes são replicados por meio de uma pesquisa na tabela de origem.

Quando você usa o modo LOB embutido, oAWS DMSA tarefa verifica todos os tamanhos de LOB para determinar quais devem ser transferidos em linha. LOBs maiores que o tamanho especificado são replicados usando o modo LOB completo. Portanto, se você souber que a maioria dos LOBs é maior do que a configuração especificada, é melhor não usar essa opção. Em vez disso, permita um tamanho de LOB ilimitado.

Você configura essa opção usando um atributo nas configurações da tarefa,InlineLobMaxSize, que só está disponível quandoFullLobModeestá definido comotrue. O valor padrão paraInlineLobMaxSizeé 0 e o intervalo é de 1 a 102400 kilobytes (100 MB).

Por exemplo, você pode usar o seguinteAWS DMSconfigurações de tarefas. Aqui, configuraçãoInlineLobMaxSizecom um valor de 5, todos os LOBs menores ou iguais a 5 KiB (5.120 bytes) são 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}, . . . }

Melhorando o desempenho ao migrar tabelas grandes usando a filtragem de linhas

Para melhorar o desempenho ao migrar uma tabela grande, divida a migração em mais de uma tarefa. Para dividir a migração em várias tarefas usando a filtragem de linha, use 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 usando a filtragem de linha para migrar um milhão de registros em cada.

Para aplicar a filtragem de linha no console:
  1. Abra a AWS Management Console.

  2. EscolhaTarefase crie uma nova tarefa.

  3. Escolha oMapeamentos de tabelastab e expandaRegras de seleção.

  4. EscolhaAdicionar nova regra de seleção. Agora você pode adicionar um filtro de coluna com uma condição menor 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 filtragem de colunas, consulte Especificando regras de seleção e transformação de tabelas no console.

Se você tiver uma tabela grande particionada por data, poderá migrar dados com base na 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, você pode criar uma tarefa de carga total para cada partição mensal estática e criar uma tarefa de carga total mais CDC para a partição atualmente atualizada.

Se sua tabela tiver uma chave primária de coluna única ou um índice exclusivo, você poderá ter suaAWS DMSsegmente a tabela usando uma carga paralela do tipo de intervalos para carregar os dados em paralelo. Para obter mais informações, consulte Regras e operações de configurações de tabela e coleção.

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 somente uma quantidade limitada de instruções da linguagem de definição de dados (DDL).AWS DMSnão propaga itens como índices, usuários, privilégios, procedimentos armazenados e outras alterações no banco de dados que não estejam diretamente relacionadas aos dados da tabela.

Se você planeja usar a replicação contínua, definaMulti-AZopção ao criar sua instância de replicação. Ao escolherMulti-AZ, você obtém alta disponibilidade e suporte de failover para a instância de replicação. No entanto, essa opção pode ter um impacto no desempenho e diminuir a velocidade da replicação ao aplicar alterações no sistema de destino.

Antes de atualizar seus bancos de dados de origem ou de destino, recomendamos que você interrompa qualquerAWS DMStarefas que estão sendo executadas nesses bancos de dados. Retome as tarefas após a conclusão das 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 oAWS DMSinstância de replicação. Certifique-se de que a rede não cause nenhum gargalo durante a replicação contínua.

Também é importante identificar a taxa de alteração e a geração de registros de arquivamento por hora em seu sistema de banco de dados de origem. Isso pode ajudar você a entender a taxa de transferência que você pode obter durante a replicação contínua.

Reduzir a carga no banco de dados de origem

O AWS DMS usa alguns recursos do banco de dados de origem. Durante uma tarefa de carregamento total, o AWS DMS executa uma varredura total da tabela de origem para cada tabela processada em paralelo. Além disso, cada tarefa que você cria como parte de uma migração consulta a origem das alterações como parte do processo do 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ê achar que está sobrecarregando seu banco de dados de origem, reduza o número de tarefas ou tabelas para cada tarefa de sua migração. Cada tarefa obtém as alterações de origem de forma independente, portanto consolidar as tarefas pode diminuir a carga de trabalho da captura de alterações.

Reduzindo os gargalos em seu banco de dados de destino

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

  • Desative os gatilhos desnecessários.

  • Desative os índices secundários durante o carregamento inicial e ligue-os novamente mais tarde 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 transferência.

  • Ao migrar para sistemas não RDS, é uma boa ideia desativar qualquer registro no destino até a transferência.

Usando a validação de dados durante a migração

Para garantir que seus dados tenham sido migrados com precisão da origem para o destino, é altamente recomendável que você use a validação de dados. Se você ativar a validação de dados para uma tarefa,AWS DMScomeça a comparar os dados de origem e de destino imediatamente após a execução de uma carga completa para uma tabela.

A validação de dados funciona com os seguintes bancos de dados sempre que o AWS DMS oferece suporte a eles como endpoints de origem e de destino:

  • Oracle

  • PostgreSQL

  • MySQL

  • MariaDB

  • Microsoft SQL Server

  • Amazon Aurora MySQL-Compatible Edition

  • Amazon Aurora PostgreSQL-Compatible Edition

  • IBM Db2 LUW

Para obter mais informações, consulte AWSValidação de dados do DMS.

Monitorando seuAWS DMStarefas usando métricas

Você tem várias opções para monitorar métricas para suas tarefas usando oAWS DMSconsole:

Métricas do host

Você pode encontrar métricas do host noCloudWatchmétricasguia para cada instância de replicação específica. Aqui, você pode monitorar se sua instância de replicação está dimensionada adequadamente.

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 noCloudWatchmétricasguia para cada tarefa específica.

Métricas da tabela

Você pode encontrar métricas de tabela individuais noEstatísticas da tabelaguia para cada tarefa individual. Essas métricas incluem esses números:

  • Linhas carregadas durante a carga total.

  • Insere, atualiza e exclui desde o início da tarefa.

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

Para obter mais informações sobre monitoramento de métricas, consulteMonitoramentoAWSTarefas do DMS.

Eventos e notificações

AWS DMSusa o Amazon SNS para fornecer notificações quando umAWS DMSevento ocorre, por exemplo, a criação ou exclusão de uma instância de replicação. Você pode trabalhar com essas notificações em qualquer formato compatível com o Amazon SNS para umAWSRegião. Isso pode incluir mensagens de e-mail, mensagens de texto ou chamadas para um endpoint HTTP.

Para obter mais informações, consulte Trabalhando com eventos e notificações do Amazon SNS noAWS Database Migration Service.

Usar o log de tarefas para solucionar problemas de migração

Em alguns casos, o AWS DMS pode encontrar problemas dos quais os avisos ou as mensagens de erro aparecerão somente no log de tarefas. Especificamente, problemas de truncamento de dados ou rejeições de linhas devido a violações de chave externa só são gravadas no log de tarefas. Portanto, analise o log de tarefas ao migrar um banco de dados. Para visualizar o registro de tarefas, configure a AmazonCloudWatchcomo parte da criação de tarefas.

Para obter mais informações, consulteMonitoramento de tarefas de replicação usando a AmazonCloudWatch.

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

Para solucionar problemasAWS DMSproblemas de migração, você pode trabalhar com o Time Travel. Para obter mais informações sobre viagens no tempo, consulteConfigurações da tarefa de viagem no tempo.

Ao trabalhar com a Time Travel, esteja ciente das seguintes considerações:

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

  • Ao usar 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 para verificar as despesas gerais de recursos. Essa abordagem se aplica especialmente nos casos em que altas cargas de transações são executadas nos bancos de dados de origem por longos períodos de tempo. Para obter mais detalhes, consulte MonitoramentoAWSTarefas do DMS.

  • Quando a configuração da tarefa Time TravelEnableRawDataestá definido 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 de tempo, monitore sua tarefa.

  • Atualmente, você pode ativar a Viagem no Tempo somente no nível da tarefa. As alterações em todas as tabelas são registradas nos registros de viagem no tempo. Se você estiver solucionando problemas para tabelas específicas em um banco de dados com alto volume de transações, crie uma tarefa separada.

Alterando o usuário e o esquema de um alvo Oracle

Quando você usa o Oracle como alvo,AWS DMSmigra os dados para o esquema de propriedade do usuário do endpoint de destino.

Por exemplo, suponha que você esteja migrando um esquema chamadoPERFDATApara um endpoint de destino Oracle, e que o nome do usuário do endpoint de destino sejaMASTER.AWS DMSse conecta ao alvo Oracle comoMASTERe preenche oMASTEResquema com objetos de banco de dados dePERFDATA.

Para substituir esse comportamento, forneça uma transformação de esquema. Por exemplo, para migrar oPERFDATAobjetos de esquema para umPERFDATAesquema no endpoint de destino, use a transformação a seguir.

{ "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 Especificando regras de seleção e transformação de tabelas usando JSON.

Alterando espaços de tabela e tabela de índice para um alvo Oracle

Ao usar o Oracle como alvo,AWS DMSmigra todas as tabelas e índices para o espaço de tabela padrão no destino. Por exemplo, suponha que sua 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 de tabela padrão.

Para substituir esse comportamento, forneça as transformações de tablespace correspondentes. Por exemplo, suponha que você queira migrar tabelas e índices para espaços de tabela de índices e de tabelas no destino do Oracle que têm o mesmo nome do esquema na origem. Nesse caso, você pode usar transformações semelhantes às seguintes. Aqui, o esquema na fonte é denominadoINVENTORYe os espaços de tabela e tabela de índice correspondentes no destino são nomeadosINVENTORYTBLeINVENTORYIDX.

{ "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 Especificando regras de seleção e transformação de tabelas usando JSON.

Quando o Oracle é tanto a origem quanto o destino, você pode preservar as atribuições existentes de tablespace de tabela ou índice definindo o atributo de conexão extra de origem do Oracle.enableHomogenousTablespace=true. Para obter mais informações, consulte Configurações de endpoint ao usar o Oracle como fonte paraAWS DMS.

Atualizando uma versão da instância de replicação

AWSlança periodicamente novas versões doAWS DMSsoftware de mecanismo de replicação, 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. É fundamental testar a versão existente do seuAWS DMSinstância de replicação executando uma carga de trabalho de produção antes de você atualizar sua instância de replicação para uma versão posterior. Para obter mais informações sobre as atualizações de versão disponíveis, consulteAWSNotas de release de DMS.

Entendendo seu custo de migração

AWS Database Migration Serviceajuda você a migrar bancos de dados paraAWSde forma fácil e segura a um baixo custo. Você paga somente por suas instâncias de replicação e por qualquer armazenamento adicional de registros. Cada instância de migração de banco de dados inclui armazenamento suficiente para espaço de troca, registros de replicação e cache de dados para a maioria das replicações, e a transferência de dados de entrada é gratuita.

Talvez você precise de mais recursos durante o carregamento inicial ou durante o horário de pico de carregamento. Você pode monitorar de perto a utilização dos recursos da instância de replicação usando métricas de monitoramento na nuvem. Em seguida, você pode aumentar e reduzir o tamanho da instância de replicação com base no uso.

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