View a markdown version of this page

Detalhes das opções de migração - AWS Orientação prescritiva
1. Backup e restauração off-line2. Failover do HADR3. Backup e restauração on-line com envio de logs de transações4. Q Replication5. SQL Replication6. AWS DMS7. Ferramentas de replicação de terceiros8. InfoSphere Descarga e carga de alto desempenho da Optim9. LOAD FROM CURSOR10. db2moveMigração de esquema

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

Detalhes das opções de migração

As seções a seguir fornecem detalhes das opções que correspondem ao diagrama na seção anterior.

1. Backup e restauração off-line

O backup nativo do Db2 faz backup de todo o banco de dados. Ele pode ser usado para recriar (restaurar) o banco de dados para qualquer host.

  • O backup e a restauração off-line são a maneira mais básica de migrar um banco de dados on-premises para a AWS.

  • O banco de dados on-premises do Db2 deve estar na plataforma little-endian.

  • É necessário um tempo de inatividade para fazer um backup off-line, transferir a imagem de backup para o Amazon S3 e restaurar o banco de dados do backup.

2. Failover do HADR

O Db2 HADR (recuperação de desastres de alta disponibilidade) fornece uma solução de alta disponibilidade replicando as alterações de dados de um banco de dados de origem, denominado banco de dados primário, para os bancos de dados de destino, denominados bancos de dados de standby. O HADR é compatível com até três servidores remotos de standby.

  • O failover do HADR é a melhor opção para uma instância não DPF executada na plataforma little-endian.

  • Todas as transações no banco de dados de origem devem ser registradas em log.

  • O HADR é compatível com a replicação de alterações de dados do banco de dados de origem (banco de dados primário) para o banco de dados de destino (banco de dados de standby) por meio do fluxo de logs. O HADR é usado TCP/IP para comunicação entre os bancos de dados primário e em espera.

  • Após a validação completa dos negócios, o HADR pode ser removido sem interrupções, e o banco de dados Db2 on-premises pode ser desativado.

3. Backup e restauração on-line com envio de logs de transações

Diferentemente do backup e da restauração off-line (opção 1), o backup on-line não exige tempo de inatividade para o banco de dados de origem. Ele usa logs de transações do banco de dados para aplicar alterações no banco de dados de destino após a conclusão do backup no banco de dados de origem.  

  • Usar backup e restauração com envio de logs de transações é a melhor opção para uma instância Db2 DPF que está na plataforma little-endian. Como o tamanho de um banco de dados Db2 DPF tende a ser grande, o tempo de interrupção para backup e restauração regulares (opção 1) pode exceder 12 horas. O HADR não é compatível com bancos de dados Db2 DPF.

  • Todas as transações no banco de dados de origem devem ser registradas em log.

  • Você pode usar o backup e a restauração com o envio de logs de transações para minimizar a janela de interrupção.

  • O backup e a restauração com envio de logs também podem ser usados para instâncias que não sejam DPF. No entanto, o HADR com a opção de failover é mais fácil de implementar para instâncias que não são DPF.

  • Ao contrário do failover do HADR (opção 2), a sincronização reversa não é automática. Configure-a manualmente.

  • Após a validação comercial completa, você pode desativar o banco de dados Db2 on-premises.

4. Q Replication

O Q Replication é uma solução de replicação de alto volume e baixa latência que usa filas de mensagens do IBM MQ para transmitir transações entre os bancos de dados de origem e de destino.

A configuração mais comum é mostrada no diagrama a seguir.

Diagrama de arquitetura mostrando a conexão do Db2 no local por meio do IBM MQ Site-to-Site e VPN ao Db2 no EC2.

O IBM MQ é executado no mesmo servidor que o Db2. Há duas instâncias do IBM MQ: uma no servidor on-premises e outra no Amazon EC2. O programa Capture é executado no banco de dados de origem. Ele lê os logs de transações e envia as alterações confirmadas (inserção, atualização ou exclusão) para o IBM MQ on-premises. O IBM MQ on-premises envia as mensagens por meio do AWS Site-to-Site VPN para o IBM MQ no Amazon EC2. O programa Apply é executado na instância do EC2 com o banco de dados de destino. Primeiro, ele realiza uma carga completa nas tabelas. Em seguida, ele lê as mensagens de dados de alteração do IBM MQ no Amazon EC2 e as aplica às tabelas de destino.

  • O Db2 on-premises é a origem e o Db2 no Amazon EC2 é o destino. Ambos os bancos de dados são on-line.

  • O banco de dados Db2 on-premises pode estar em qualquer família de plataformas.

  • Todas as transações no banco de dados de origem devem ser registradas em log.

  • O IBM MQ fornece alta performance, alta disponibilidade e entrega garantida de mensagens.

  • As mensagens são excluídas do IBM MQ após as alterações terem sido confirmadas no banco de dados de destino.

  • A replicação bidirecional é uma opção de fallback. No entanto, ela requer configuração adicional.

  • A migração do esquema é necessária. Para obter detalhes, consulte a seção Migração de esquema.

  • A Q Replication exige uma licença extra a partir da versão 11.5.

  • Após a substituição com êxito, interrompa a replicação e desative as instâncias do IBM MQ. Você também pode desativar o banco de dados on-premises, se quiser.

5. SQL Replication

O SQL Replication consiste nos seguintes componentes principais: Capture, Apply, interface da GUI e CLI e monitor de alertas.

O programa Capture é executado no banco de dados de origem. Ele lê os logs de transações e salva as alterações confirmadas (inserção, atualização ou exclusão) nas tabelas de dados alterados (CD). Há uma tabela de CD para cada tabela de origem.

Os pontos de commit do Db2 para as unidades de trabalho são armazenados na tabela de unidades de trabalho (UOW). Em um ponto no tempo especificado pelo usuário, o programa Capture exclui dados que não são mais necessários nas tabelas de CD e UOW. Isso é denominado remoção.

O programa Apply é executado no banco de dados de destino. Ele se conecta ao banco de dados de origem, busca os dados armazenados nas tabelas de CD, armazena as linhas buscadas em um ou mais arquivos de derramamento e, em seguida, os aplica ao banco de dados de destino.

  • O banco de dados Db2 on-premises pode estar em qualquer família de plataformas.

  • Todas as transações no banco de dados de origem devem ser registradas em log.

  • A sobrecarga no banco de dados de origem é considerada alta porque cada gravação deve ser executada várias vezes (nas tabelas baseada, de CD e de UOW). Em geral, recomendamos o SQL Replication para sistemas com baixo tráfego de gravação.

  • A replicação bidirecional é uma opção de fallback. No entanto, ela requer configuração adicional.

  • A migração do esquema é necessária. Para obter detalhes, consulte a seção Migração de esquema para obter detalhes.

  • Diferentemente do Q Replication, o SQL Replication está incluído em todas as edições do Db2. Não requer uma licença extra.

  • Após a substituição com êxito, interrompa a replicação e desative o banco de dados on-premises, se desejar.

6. AWS DMS

AWS Database Migration Service (AWS DMS) é um serviço gerenciado de migração e replicação que ajuda a mover suas cargas de trabalho de banco de dados e análises com AWS segurança, com o mínimo de tempo de inatividade e sem perda de dados.

  • Uma instância de AWS DMS replicação realiza a migração do banco de dados.

  • AWS DMS os endpoints de origem e destino permitem que a AWS DMS instância conecte o banco de dados de origem e de destino para migração.

  • Uma AWS DMS tarefa se conecta ao endpoint de origem e replica os dados no endpoint de destino.

  • Você pode ativar a validação de dados para verificar se eles são migrados corretamente da origem para o destino.

  • Você pode ativar o registro usando a Amazon CloudWatch.

7. Ferramentas de replicação de terceiros

Ferramentas de replicação de terceiros, como Infosphere CDC, Qlik Replicate, Precisely real-time CDC e Oracle, GoldenGate podem oferecer suporte à migração de dados para o Db2 for LUW como destino.

Para o Qlik Replicate, o Db2 para LUW precisa ser configurado como um destino do Open Database Connectivity (ODBC).

8. InfoSphere Descarga e carga de alto desempenho da Optim

InfoSphere O Optim High Performance Unload ignora o mecanismo Db2 e descarrega dados diretamente dos arquivos físicos.

  • O Optim High Performance Unload geralmente pode descarregar dados do Db2 várias vezes mais rápido do que o comando EXPORT do Db2. Ele pode ignorar o gerenciador de banco de dados Db2 lendo arquivos de dados diretamente do disco. Também evita verificar a tabela do Db2 várias vezes ao especificar várias instruções SELECT ou vários formatos de arquivo em um arquivo de controle.

  • O Optim High Performance Unload também pode descarregar dados do Db2 da imagem de backup. Isso significa que você pode executar o Optim High Performance Unload em outra máquina para reduzir o impacto na performance do servidor de banco de dados de origem. Isso é muito útil para grandes tabelas históricas ou partições de tabelas.

  • Os arquivos de saída de dados podem ser transferidos para o Amazon S3, que pode ser acessado pelo servidor Db2 EC2.

  • O carregamento do Db2 é compatível com acesso direto ao Amazon S3. Por exemplo, é possível usar o seguinte comando:

    db2 load from DB2REMOTE://<storage access alias>//<storage-path>/<file-name> replace into mytable

  • A migração do esquema é necessária. Para obter detalhes, consulte a seção Migração de esquema.

  • InfoSphere O Optim High Performance Unload requer uma licença extra.

9. LOAD FROM CURSOR

O LOAD FROM CURSOR é uma opção do utilitário de carregamento do Db2 que usa uma tabela no destino como origem, sem descarregar os dados em um arquivo.

  • Um link federado precisa ser criado no banco de dados de destino e vinculado ao banco de dados de origem.

  • Para cada tabela, um apelido é criado com link para a tabela de origem on-premises. Se houver muitas tabelas envolvidas, recomendamos o uso de um script de automação para gerar os apelidos e as instruções de carregamento.

  • O LOAD FROM CURSOR ignora o armazenamento temporário, e as tabelas podem ser separadas em diferentes fluxos para serem executadas em paralelo. Recomendamos monitorar o congestionamento da rede durante grandes carregamentos.

  • Ao manipular a instrução SELECT na definição do cursor, você pode selecionar a tabela completa, ignorar dados que não deseja carregar ou dividir uma tabela de partições baseada em intervalos em várias instruções de carregamento (por exemplo, trimestral e mensal).

  • A migração do esquema é necessária. Para obter detalhes, consulte a seção Migração de esquema.

10. db2move

O comando db2move, quando usado nos modos EXPORT, IMPORT ou LOAD, facilita a movimentação de um grande número de tabelas entre bancos de dados Db2.

  • A migração do esquema é necessária. Para obter detalhes, consulte a seção Migração de esquema.

  • Você pode usar o comando db2move para descarregar os dados das tabelas em arquivos e carregar os dados nas tabelas do Db2. Isso é útil porque o utilitário db2move pode baixar todas as tabelas no banco de dados de origem e carregá-las no banco de dados de destino com alguns comandos.

  1. Para exportar todas as tabelas no banco de dados de origem com LOBs to<lob-path>, execute o seguinte comando:

    db2move <db-name> export -l /<lob-path>/<lobfile>

  2. Transfira os arquivos para o Amazon S3, onde eles podem ser recuperados pelo servidor Db2 EC2.

  3. Para carregar todas as tabelas no banco de dados de destino, execute o seguinte comando:

    db2move <db-name> load -l /<lob-path>/<lobfile>

Migração de esquema

Para backup e restauração, failover do HADR e backup e restauração com envio de logs (opções 1 a 3), a migração do esquema está incluída na migração de dados. Nenhuma etapa adicional é necessária.

Para replicação lógica e migração big-endian (opções 4 a 10), você deve criar manualmente o banco de dados e o esquema no destino. Recomendamos evitar alterações de esquema na origem durante a migração. A migração pode levar vários dias, embora o tempo real de interrupção seja muito menor.

No servidor de origem:

  1. Extraia a linguagem de definição de dados (DDL) usando o utilitário db2look, e salve a saída em db2look.ddl.

  2. Transfira db2look.ddl para o Amazon S3.

No servidor de destino:

  1. Obtenha db2look.ddl do Amazon S3.

  2. Remova a restrição de chave estrangeira, a restrição de verificação e as instruções CREATE TRIGGER. Salve-as em arquivos separados. Esse processo não é difícil porque a saída do db2look agrupa essas instruções.

  3. Crie um banco de dados e um esquema sem a chave estrangeira, a restrição de verificação e o gatilho.

  4. Converta tabelas com colunas de identidade que têm GENERATED ALWAYS para GENERATED BY DEFAULT.

  5. Para as opções de replicação lógica 4, 5, 6 e 7, inicie a replicação. Você pode recriar chaves estrangeiras e verificar as restrições após a conclusão do carregamento completo. No entanto, você deve recriar os gatilhos antes da substituição.

  6. Para as opções 8, 9 e 10, após a conclusão do carregamento de dados, recrie as chaves estrangeiras, verifique as restrições e os gatilhos.

  7. Reverta tabelas com colunas de identidade que você alterou na etapa 4 de volta para GENERATED ALWAYS.

  8. Propague novamente as colunas e sequências de identidade antes da substituição.