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 de destino a umAWS DMSinstância de replicação, você configura uma rede. Fazer isso pode ser tão simples quanto conectar doisAWSRecursos do na mesma nuvem privada virtual (VPC) que a instância de replicação. Isto pode variar para configurações mais complexas como conectar um banco de dados local a uma instância de banco de dados do Amazon RDS em uma rede privada virtual (VPN). Para obter mais informações, consulte Configurações de rede para migração de banco de dados.

  • Pontos de extremidade de origem e de destino— Certifique-se de saber quais informações e tabelas do banco de dados de origem devem ser migradas para o banco de dados de destino.AWS DMSoferece suporte à migração básica de esquemas, incluindo a criação de tabelas e chaves primárias. No entanto,AWS DMSO não cria automaticamente índices secundários, chaves estrangeiras, contas de usuário, entre outras coisas, no banco de dados de destino. Dependendo do mecanismo de banco de dados de origem e destino, talvez seja necessário configurar o registro suplementar ou modificar outras configurações para um banco de dados de origem ou destino. Para obter mais informações, consulte Origens para a migração de dados e Destinos para a migração de dados.

  • Migração de código e schema–AWS DMSO não realiza conversão de schema ou de código. É possível 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, use aAWS Schema Conversion Tool(AWS SCT). Ela pode criar um esquema de destino e pode gerar e criar um esquema inteiro: tabelas, índices, exibiçõ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, consulte oAWS SCTGuia do usuário do.

  • Tipos de dados não compatíveis— Certifique-se de que você possa 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 armazenamento de dados.

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

    Se um script de suporte estiver disponível para o banco de dados, faça o download usando o link no tópico de 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— UMAvaliação pré-migraçãoavalia 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 usar 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 pré-migração, consulteHabilitando e trabalhando com avaliações 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ê deseja converter um esquema existente em um mecanismo de banco de dados diferente, use aAWS SCT.AWS SCTConverte os objetos, tabelas, índices, exibições, gatilhos e outros objetos do sistema de origem no formato DDL (datastore Definition Language) de destino. Você também pode usarAWS SCTPara converter a maior parte do código do aplicativo, como PL/SQL ou TSQL, para o linguagem de destino equivalente.

Você pode obterAWS SCTcomo download gratuito deAWS. Para obter mais informações em AWS SCT, consulte o Guia do usuário AWS SCT.

Se os endpoints de origem e destino estiverem no mesmo mecanismo de banco de dados, use ferramentas como Oracle SQL Developer, MySQL Workbench ou PgAdmin4 para mover o esquema.

Revisar oAWS DMSdocumentação pública

Recomendamos que você passe peloAWS DMSpáginas de documentação pública para seus endpoints de origem e destino antes da primeira migração. Esta documentação pode ajudá-lo 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 Trabalho comAWSEndpoints DMS.

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

Executar 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 uma pequena migração de teste. Fazer isso também pode ajudá-lo a definir uma linha de tempo 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 banco de dados pela rede. Durante esse período, recomendamos comparar e otimizar sua carga total inicial e replicação contínua. Fazer isso pode ajudá-lo a entender a latência da rede e avaliar o desempenho geral.

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

  • Quantas tabelas são grandes, médias e pequenas em tamanho.

  • ComoAWS DMSlida com conversões de tipo de dados e conjunto 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 origem.

  • A taxa de transferência disponível.

  • 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 sendo migrados.

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

Provisionamento de um servidor de replicação adequado

AWS DMSÉ um serviço gerenciado que é 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 o consumo do banco de dados de destino e os carrega nele.

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 encontrar o que considerar ao escolher o servidor de replicação.

CPU

AWS DMSfoi projetado para migrações heterogêneas, mas também suporta migrações homogêneas. Para executar uma migração homogênea, primeiro converta cada tipo de dados de origem em seu equivalenteAWS DMSTipo de dados do. 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 dentro doAWS DMSGuia do usuário do.

para oAWS DMSpara executar 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 a migração envolve 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 boa quantidade de memória e 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 sua carga de trabalho. Elas são destinadas para cargas de trabalho que não usam a CPU inteira com frequência, mas que às vezes precisam de intermitência. As instâncias T2 são adequadas para cargas de trabalho de propósito geral, como servidores Web, ambientes de desenvolvedor e bancos de dados pequenos. Se você estiver solucionando problemas de migração lenta e usando um tipo de instância T2, verifique a métrica do host Utilização da CPU. Ele pode mostrar se você está explodindo sobre a linha de base para esse 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. Ele fornece um desempenho significativamente maior de pacotes por segundo (PPS), menor jitter de rede e latência de rede mais baixas.AWS DMSIsto pode ser intensivo no que diz respeito à CPU, especialmente ao executar replicações e migrações heterogêneas como a migração do Oracle para 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ção de alta transferência 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 fornecer desempenho rápido para cargas de trabalho que processam grandes bancos de dados na memória. Migrações ou replicações contínuas de sistemas de transação de alta transferência usandoAWS DMSPode, às vezes, consumir grandes quantidades de CPU e memória. As instâncias R5 fornecem 5% de memória adicional por vCPU do que 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 desempenho de CPU aumentado em ~ 20% em relação ao R4.

As classes de instância C5 otimizadas para cargas de trabalho que exigem muita computação e oferecem alto desempenho e grande economia com uma baixa relação de preço por desempenho de 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 ao Amazon EBS.AWS DMSIsto pode ser intensivo no que diz respeito à CPU, especialmente ao executar replicações e migrações heterogêneas como a migração do Oracle para PostgreSQL. As instâncias C5 podem ser uma boa opção para essas situações.

Armazenamento

Dependendo da classe de 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 quaisquer alterações armazenadas em cache coletadas durante o carregamento. Se o sistema de origem estiver ocupado ou realizar grandes transações, talvez seja necessário aumentar o armazenamento. Se você estiver executando várias tarefas no servidor de replicação, talvez também precise de um aumento de armazenamento. No entanto, o valor padrão geralmente é suficiente.

Todos os volumes de armazenamento noAWS DMSsão GP2 ou unidades de estado sólido (SSDs) de propósito geral. Os volumes GP2 vêm com um desempenho básico de três operações de E/S por segundo (IOPS), com habilidades para intermitir até 3.000 IOPS em uma base de 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 cruze 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 tem a intenção de ser executado por longos períodos de tempo. Se você usarAWS DMSpara fins de replicação contínua, a escolha de 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 um FULL LOAD e ocorre uma substituição de failover ou 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 um estado de erro.

Carregando várias tabelas em parallel

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 noAWS Management Console, abra o console, escolhaTarefas, escolha criar ou modificar uma tarefa e 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 sobTaskSettings.

Usar carga completa parallel

Você pode usar uma carga parallel de fontes Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW com base em partições e subpartições. Fazer 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 parallel na mesma tarefa de migração.

Para usar uma carga parallel, crie uma regra de mapeamento de tabelas 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 parallel. Para especificar os critérios de seleção, defina otypeElemento 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, gatilhos 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 modo como afetam a migração depende se a tarefa de replicação é uma tarefa de carregamento 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 até que as tarefas de carregamento total sejam concluídas. Os índices não são necessários durante uma tarefa de carregamento total, e os índices incorrerão custos indiretos 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. Do mesmo modo, inserir, atualizar e excluir gatilhos pode causar erros se, por exemplo, uma inserção de linha for acionada para uma tabela carregada em massa anteriormente. Outros tipos de gatilhos também afetam o desempenho devido ao processamento adicional.

Se os volumes de dados são relativamente pequenos e o tempo de migração adicional não for uma preocupação, é possível criar índices de chave primária e secundários antes de uma tarefa de carregamento total. Sempre desative restrições de integridade referencial e gatilhos.

Para uma tarefa de carregamento total mais CDC, recomendamos que adicione índices secundários antes da fase de CDC. ComoAWS DMSUse replicação lógica, verifique se os índices secundários que oferecem suporte às operações DML estão em vigor para evitar varreduras totais de tabela. Pause a tarefa de replicação antes da fase de CDC para criar índices e criar as restrições de integridade referencial antes de reiniciar a tarefa de replicação.

Você deve habilitar os gatilhos logo antes da substituição.

Desabilitar backups e o log de transações

Ao migrar para um banco de dados do Amazon RDS, é uma boa ideia desativar backups e Multi-AZ no destino até que você esteja pronto para o redirecionamento. Do mesmo modo, ao migrar para sistemas que não o Amazon RDS, desligar qualquer registro no destino até após o redirecionamento ao migrar para sistemas que não sejam o Amazon RDS.

Usar várias tarefas

Às vezes, usar várias tarefas para uma única migração pode melhorar o desempenho. Se você possui conjuntos de tabelas que não participam de transações em comum, talvez seja possível dividir a migração em várias tarefas. A consistência transacional é mantida em uma tarefa, então é importante que tabelas em tarefas separadas não participem de transações em comum. Além disso, cada tarefa lê o fluxo de transação de modo independente; portanto, tenha cuidado para não sobrecarregar 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.

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

Usar seu próprio servidor de nomes no local

Normalmente, umAWS DMSA instância de replicação usa o resolvedor DNS (Domain Name System) em uma instância do Amazon EC2 para resolver endpoints de domínio. No entanto, você pode usar seu próprio servidor de nomes no local para resolver determinados endpoints se usar o resolvedor do Amazon Route 53. Com essa ferramenta, você pode consultar entre local 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 segurança aprimorada e facilidade de uso por trás de um firewall.

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

Os endpoints de saída se conectam ao servidor de nomes no local. O servidor de nomes só concede acesso a 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. Quando você escolhe um security group para um endpoint de saída, escolha o mesmo security group usado pela instância de replicação.

Para encaminhar domínios selecionados para o servidor de nomes, use regras de encaminhamento. Um endpoint de saída pode lidar com várias regras de encaminhamento. O escopo da regra de encaminhamento é a nuvem privada virtual (VPC). Usando uma regra de encaminhamento associada a uma VPC, você pode provisionar uma seção isolada logicamente doAWSNuvem. A partir desta seção logicamente isolada, você pode iniciarAWSRecursos em uma rede virtual.

Você pode configurar domínios hospedados na infraestrutura DNS no local como regras de encaminhamento condicional que configuram consultas 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 que foram configurados com as regras. Mais uma vez, uma conexão privadaAWS Direct Connectou VPN é necessária.

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


                Route 53 Resolver Arquitetura

Para obter mais informações sobre o Resolvedor de DNS do Route 53, consulteConceitos básicos do Route 53 ResolvernoGuia do desenvolvedor do Amazon Route 53.

Usar o Resolver do Amazon Route 53AWS DMS

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

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

  3. Escolha o diretório de consulta — de entrada, de saída ou ambos.

  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 a serem usados 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 no local.

  7. Envie sua regra.

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

Para obter mais informações sobre o Resolvedor do Route 53, consulteConceitos básicos do Route 53 ResolvernoGuia do desenvolvedor do Amazon Route 53.

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

Em geral,AWS DMSO 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 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 a 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 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 DMSO usa dois métodos que equilibram o desempenho e a conveniência quando a 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áx. do LOBa configuração de parâmetro está correta. Defina esse parâmetro para o maior tamanho de LOB de 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ê escolheuLimited LOB mode, oTamanho máx. do LOBA opção está definida para 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.

Melhoria do desempenho LOB

Ao migrar dados LOB, você pode especificar as seguintes configurações de otimização de LOB diferentes.

Configurações LOB por tabela

Usando as configurações de LOB por tabela, você pode substituir as configurações de LOB no nível da tarefa para algumas ou todas as suas tabelas. Para fazer isso, defina olob-settingsnotable-settingsregra. A seguir, uma tabela de exemplo que inclui alguns valores de LOB grandes.

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 manuseio de LOB para sua tabela usando o novolob-settingsregra. Obulk-max-sizO valor determina o tamanho máximo de LOB (KB). Ele é 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 com oFullLobMode : true, as configurações de LOB por tabela diretasAWS DMSpara truncar dados LOB nesta 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 DMS, o modo de LOB determina como os LOBs são processados.

Com o modo LOB completo e o modo LOB limitado, cada um tem seus próprios benefícios e desvantagens. O modo LOB em linha combina as vantagens do modo LOB completo e do modo LOB limitado.

É possível usar o modo LOB em linha 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 a partir da tabela de origem.

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

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

Você configura essa opção usando um atributo nas configurações da tarefa,InlineLobMaxSize, que só está disponível quandoFullLobModeé definido comotrue. O valor padrão paraInlineLobMaxSizeé 0. O intervalo é de 1 KB a 2 GB.

Por exemplo, você pode usar o seguinteAWS DMSConfigurações de tarefa. Aqui, configuraçãoInlineLobMaxSizepara um valor de 5 resulta em todos os LOBs menores ou iguais a 5.000 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}, . . . }

Melhorar o desempenho na migração de tabelas grandes usando a filtragem de linhas

Para melhorar o desempenho na migração de 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 filtragem de linhas no console:

  1. Abra a AWS Management Console.

  2. SelecioneTarefase crie uma nova tarefa.

  3. Selecione oMapeamentos de tabelae expandaRegras de seleção.

  4. SelecioneAdicionar nova regra de seleção. Agora você pode adicionar um filtro de colunas com uma condição 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 Especificando regras de seleção e transformações de tabelas no console.

Se você tiver uma tabela particionada grande que seja particionada por data, migre os 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 carregamento total para cada partição mensal estática e criar uma tarefa de carregamento total mais CDC para a partição atualizada atualmente.

Se sua tabela tiver uma chave primária de coluna única ou um índice exclusivo, você poderá ter oAWS DMSsegmentar a tabela usando uma carga paralela do tipo de intervalos para carregar os dados em parallel. 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 apenas uma quantidade limitada de instruções DDL (Data Definition Language).AWS DMSO 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.

Se você planeja usar a replicação em andamento, defina oMulti-AZquando você cria sua instância de replicação. EscolhendoMulti-AZ, você recebe alta disponibilidade e suporte a failover para a instância de replicação. No entanto, essa opção pode afetar o desempenho e diminuir a replicação ao aplicar as alterações ao sistema de destino.

Antes de atualizar seus bancos de dados de origem ou de destino, recomendamos que você pare qualquerAWS DMSAs tarefas que estão sendo executadas nesses bancos de dados. Retome as tarefas depois que seus upgrades forem concluídos.

Durante a replicação contínua, é fundamental identificar a largura de banda da rede entre o sistema de banco de dados de origem e oAWS DMSReplication instance. Certifique-se de que a rede não cause nenhum gargalo durante a replicação em andamento.

Também é importante identificar a taxa de alteração e a geração de logs de arquivamento por hora em seu sistema de banco de dados de origem. Fazer isso pode ajudá-lo a entender a taxa de transferência que você pode obter durante a replicação em andamento.

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 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 descobrir que está sobrecarregando o banco de dados de origem, reduza o número de tarefas ou tabelas de cada tarefa para a 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 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 gatilhos desnecessários.

  • Desligue os índices secundários durante a carga inicial e ligue-os novamente mais tarde durante a replicação em andamento.

  • Com os bancos de dados do Amazon RDS, é bom desabilitar backups e Multi-AZ até o redirecionamento.

  • Na migração para sistemas que não são RDS, é bom desabilitar registros em log no destino até o redirecionamento ao migrar para sistemas que não são RDS.

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

Para verificar se seus dados foram migrados com precisão da origem para o destino, recomendamos que você use a validação de dados. Se você ativar a validação de dados para uma tarefa,AWS DMSO começa a comparar os dados de origem e de destino imediatamente após a realização de um carregamento total de 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 DMS.

Monitorar aAWS DMStarefas usando métricas

Você tem várias opções para monitorar métricas para suas tarefas usando aAWS DMSConsole do :

Métricas do host

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

Métricas de tarefas de replicação

Métricas para tarefas de replicação, incluindo as alterações de entrada e confirmadas, e a latência entre o host de replicação e os bancos de dados de origem/destino podem ser encontradas naMétricas do CloudWatchguia para cada tarefa em particular.

Métricas de 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 DDL desde o início da tarefa.

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

Eventos e notificações

AWS DMSusa o Amazon SNS para fornecer notificações quando umAWS DMSO evento ocorre, por exemplo, a criação ou a exclusão de uma instância de replicação. Você pode trabalhar com essas notificações de qualquer forma compatível com o Amazon SNS para umAWSRegião : Eles podem 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 emAWS 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 exibir o log de tarefas, configure a Amazon CloudWatch como parte da criação de tarefas.

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

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

Para solucionar problemas doAWS DMSproblemas de migração, você pode trabalhar com o Time Travel. Para obter mais informações sobre a viagem no tempo, consulteConfigurações de tarefas de viagem no tempo.

Quando você trabalha com a Time Travel, esteja ciente das seguintes considerações:

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

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

  • Quando a configuração de tarefa Viagem no TempoEnableRawDataé definido comotrue, o uso da memória da tarefa durante a replicação DMS pode ser maior do que quando a Viagem no Tempo não está ativada. 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 logs 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.

Alterar o usuário e o esquema de um destino do Oracle

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

Por exemplo, digamos que você está migrando um esquema chamadoPERFDATApara um endpoint de destino Oracle e que o nome de usuário do endpoint de destino éMASTER.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 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 Especificando regras de seleção e transformações de tabelas usando JSON.

Alterar espaços de tabela de índice e de tabela de índice para um destino do Oracle

Ao usar o Oracle como destino,AWS DMSmigra todas as tabelas e índices para o tablespace 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 transformações de espaços de tabela 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 origem é nomeadoINVENTORYOs espaços de tabela e índices correspondentes no destino são chamadosINVENTORYTBLeINVENTORYIDX.

{ "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ções de tabelas usando JSON.

Quando o Oracle é origem e destino, é possível preservar as atribuições de tablespace de tabela ou índice existentes definindo o atributo de conexão extra de origem OracleenableHomogenousTablespace=true. Para obter mais informações, consulte Atributos de conexão adicionais ao usar o Oracle como origem do AWS DMS.

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

AWSLibera periodicamente novas versões doAWS DMSSoftware de mecanismo de replicação, com novos recursos e melhorias de performance. 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 atualizar sua instância de replicação para uma versão posterior. Para obter mais informações sobre atualizações de versões disponíveis, consulteAWSNotas de release do DMS.

Noções básicas sobre o custo do

AWS Database Migration Serviceajuda você a migrar bancos de dados paraAWSde forma fácil e segura a um baixo custo. Você paga apenas por suas 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.

Você pode precisar de mais recursos durante a carga inicial ou durante o tempo de pico de carga. Você pode monitorar de perto a utilização de recursos da instância de replicação usando métricas de observação na nuvem. Em seguida, você pode escalar e reduzir o tamanho da instância de replicação com base no uso.

Para obter mais informações sobre a estimativa de custos de migração, consulte: