AWS Database Migration Services: Migrando seu Banco de Dados Oracle para o Amazon RDS

Por Hugo Rozestraten e Felipe Garcia, AWS Solutions Architects

Amazon RDS

O serviço gerenciado de banco de dados relacional Amazon RDS (Relational Database Service) provê uma série de vantagens em relação a uma instalação customizada utilizando instâncias EC2 (Elastic Compute Cloud). A seguir algumas das vantagens do RDS sobre a instalação em EC2, que trazem segurança, redução grande de custo operacional, redução de custo de aquisição e manutenção.

• Alta disponibilidade em um clique, com um botão de marcação configura-se o banco de dados com uma replicação automática para outra Zona de Disponibilidade (conjunto de data center separado por dezenas de quilômetros) dentro de uma mesma Região, garantindo uma réplica com recuperação de falha da instância primária automática, e sem necessidade de reconfigurar a conexão da aplicação.
• Instalação, gestão e atualização do sistema operacional e discos pela AWS retira uma carga de trabalho operacional e de baixo valor agregado para as equipes TI, deixando com que se dediquem à otimização de aplicação e queries ao invés de detalhes da infraestrutura.
• Escalabilidade vertical, é possível para atender picos de necessidade de negócios aumentar a capacidade das máquinas, mudando o tipo da instância para de maior capacidade realizando um reboot. O incremento de storage é muito fácil de realizar e é feito de maneira transparente e online.
• Backup online automatizado faz parte do serviço gerenciado, sem necessidade de elaborar rotinas ou interagir com software, o serviço possui a facilidade de programar o horário de execução para minimizar impacto e definir o tempo retenção.
• Recuperação “point-in-time” é um benefício interessante pois com apenas um setup de poucos “clicks” pode-se gerar um ambiente de Homologação idêntico ao de produção, ou recuperar o banco de dados de um erro humano como a deleção de uma tabela, ou um erro lógico na aplicação.
• Criptografia em trânsito e dos discos é uma facilidade de setup pelo RDS.

Se sua base de dados tiver mais do que 5 Terabytes e ainda estiver em crescimento o  RDS pode não ser uma boa opção pois é limitado atualmente a 6 Terabytes, neste caso utilize instâncias EC2 e para realizar um rápido provisionamento utilize o AWS Quick Start para Oracle em EC2. Para maiores detalhes sobre o RDS consultar a documentação do Amazon RDS Oracle.

Entendendo a migração para o Amazon RDS

Para trazer os dados de seu data center ou de uma instância Amazon EC2 para o RDS existem algumas possibilidades, como o acesso ao sistema operacional é restrito no RDS todas as alternativas exploram a cópia lógica dos dados e replicação de transações para o mínimo downtime.

Por segurança, evita-se expor bancos de dados para à internet, sendo assim, o RDS deve ser lançado dentro de uma VPC (Virtual Private Cloud) em uma subnet privada. Desta forma é necessário criar uma comunicação VPN ou Direct Connect (conexão via fibra) para que seja possível acessar esta subnet à partir de seu data center.

É importante considerar a capacidade do link (Gbps/Mbps) que está utilizando para a comunicação com a AWS e o total de Gigabytes que serão trafegados, para estimar quanto tempo será necessário para a migração, e ainda verificar se há horários de maior utilização e concorrência do link atual.

Figura 1 – Cenário de migração de seu Data Center para o RDS

Quando seu banco de dados já está em uma Amazon EC2 na mesma VPC, é muito fácil estabelecer a conectividade entre ele e sua instância de RDS, bastando habilitar o firewall (Security Group) da instância. Neste caso a capacidade de transferência será ditada pelo tipo de instância utilizada, e é importante saber que cada tipo de instância sejam RDS e EC2 tem uma capacidade de tráfego de rede (Network Performance) e isto pode impactar negativamente ou positivamente a migração, a migração será sempre nivelada pela instância com menor capacidade de tráfego de rede, seja ela origem ou destino.

Figura 2 – Cenário de migração de Amazon EC2 para o RDS

Se houver impossibilidade de link para a migração direta para o RDS, é possível considerar uma estratégia em duas fases, primeiro com a migração para o EC2 e posterior migração de EC2 para o RDS. Desta forma pode-se para subir backups físicos comprimidos realizados com o RMAN por exemplo, restaura-lo em EC2 e posteriormente executar a migração descrita aqui para RDS. Para a cópia física para o EC2 pode-se utilizar utilitários como Tsunami UDP, transferência temporária dos arquivos para o S3 com multipart upload, ou ainda serviços de parceiros com envio de discos com arquivos criptografado. Em algumas regiões é possível utilizar o Amazon Import/Export SnowBall para este envio inicial.

Métodos de migração disponíveis

O método de migração ideal varia de acordo com a quantidade de Gigabytes e se é possível downtime ou não.

Opções com DownTime:

• Oracle SQL Developer é uma possibilidade para bases pequenas até 200 MB, com qualquer quantidade de objetos, processo simples de operar.
• Oracle materialized views são uma possibilidade para bases pequenas até 500 MB, com poucos objetos.
• Oracle exp/imp utilitário anterior ao Oracle data pump, pode ser utilizado para bases até 10GB.
• Oracle external tables, neste caso as tabelas são gravadas com arquivos em file system e migradas via diretório DATA_PUMP_DIR do RDS, se as tabelas forem muito grandes requer uma instância EC2, utilizando Tsunami UDP para o envio, utilizado para número reduzido de tabelas, algumas dezenas, com até 1TB.
• Oracle SQL*Loader é um utilitário de carga de arquivos texto do Oracle que com um esforço de configuração pode ser utilizado para bancos com poucos objetos (dezenas) e até 10GB.
• DataPump é o método mais utilizado para a migração dos objetos e carga inicial dados, sendo indicado para bases de até 5 terabytes.

Opções de zero ou quase-zero downtime:

• AWS Database Migration Service é a alternativa de baixíssimo custo para bases de dados de até 5 TB, quer precisam estar 24×7 ativas, utilizando recursos computacionais para uma instância de replicação na AWS durante a migração.
• Oracle GoldenGate é uma boa alternativa para bases de qualquer tamanho que necessitem zero-downtime, é um produto da Oracle e para ser utilizado deve ser adquirido .

Neste blog vamos explorar a migração utilizando o AWS Database Migration Service, por ser uma opção de baixo custo e viável para a grande maioria dos bancos de dados até 5 Terabytes.

Levante alguns dados da sua origem

Conecte-se no seu banco de dados de origem para verificar alguns dados para a migração. Verifique o tamanho de suas tablespaces, para evitar criar um banco de dados maior do que o necessário. Verifique também quais os schemas que serão migrados e seus tamanhos. Note que como se trata de uma migração lógica os tamanhos poderão se alterar devido à reorganização dos blocos de dados.

Verificando o tamanho das tablespaces na Origem:

set pages 1000 line 150
select nvl(b.tablespace_name,nvl(a.tablespace_name,'UNKOWN')) name,
       kbytes_alloc kbytes,
       kbytes_alloc-nvl(kbytes_free,0) used,
       nvl(kbytes_free,0) free,
       trunc(((kbytes_alloc-nvl(kbytes_free,0))/kbytes_alloc)*100,2) pct_used
  from (select sum(bytes)/1024 Kbytes_free,
                 max(bytes)/1024 largest,
                 tablespace_name
           from sys.dba_free_space
           group by tablespace_name ) a,
       (select sum(bytes)/1024 Kbytes_alloc,
                tablespace_name
           from sys.dba_data_files
           group by tablespace_name ) b
  where a.tablespace_name (+) = b.tablespace_name
order by PCT_USED;

Verificando os tamanhos de cada schema, com suas tabelas, índices e segmentos LOB, e defina quais schemas necessitam ser migrados:

set pages 1000 line 150
select owner, sum(bytes/1024/1024/1024) from dba_segments where owner<>'SYS' and owner<>'SYSTEM' group by owner;

Habilite supplemental logs para as tabelas na origem que não tenham primary key e para o Database.

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
-- para tabelas sem primary key realize o seguinte setup:
ALTER TABLE USERNAME.TABLENAME ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
-- pode fazer uma query na BDA constraints para checar a necessidade

Criação do RDS

Configure seu RDS de destino, utilizando a Amazon Console ou pela linha de comando.

• Passo 1 – Acesse a console do RDS e lance uma instância de DB.

Figura 3 – RDS passo 1, crie uma instância

• Passo 2 – Selecione qual banco de dados e dentro deste a versão que vai usar.

Figura 4 – RDS passo 2, selecione o Banco de Dados

• Passo 3 – Se seu banco de dados terá replicação em outra Zona de disponibilidade ou não. É possível fazer este setup depois, então recomendamos que siga sem Multi-AZ, e mude para Multi-AZ quando for realizar a virada de produção para o RDS.

Figura 5 –RDS passo 3, seleciona e disponibilidade

• Passo 4 – Selecione o tamanho do banco de dados (GB de disco) e da instância (vCPU e GB memória), a versão do “patchset” um nome para o banco de dados (Oracle service name), um usuário DBA e sua senha. E seu licenciamento, se está utilizando uma licença que já possui (BYOL), é o mais comum.

Figura 6 –RDS passo 4, configure a instância

• Passo 5 – Escolha a VPC (rede do seu ambiente AWS), o firewall (Security Group), se ele terá acesso público (recomenda-se não), janelas e retenção de backup e monitoramento avançado ou não. Consulte a documentação do RDS.

Figura 7 – RDS passo 5, escolha parâmetros de segurança e backup

É possível fazer o lançamento do RDS programaticamente utilizando AWS SDKs, ou utilizando o AWS CLI, em um único comando, confira a documentação de instalação do AWS CLI  para informações, bem como a biblioteca de comandos do AWS CLI para RDS , note que se você não especificar alguns parâmetros como VPC, security groups o AWS CLI vai assumir os parâmetros padrão como nos exemplos abaixo:

Para Linux (altere os parâmetros, meuoracle, meuuser e minhasenha):

aws rds create-db-instance \
    --db-instance-identifier meuoracle \
    --allocated-storage 100 \
     --db-instance-class db.m1.small \
    --engine oracle-ee \
    --master-username meuuser \
    --master-user-password minhasenha \
    --backup-retention-period 15

Para Windows (altere os parâmetros, meuoracle, meuuser e minhasenha):

aws rds create-db-instance ˆ
    --db-instance-identifier meuoracle ˆ
    --allocated-storage 100 ˆ 
    --db-instance-class db.m1.small ˆ
    --engine oracle-se1 ˆ
    --master-username meuuser ˆ
    --master-user-password minhasenha ˆ
    --backup-retention-period 15

Configure o Amazon RDS para a migração

Após o setup do RDS algumas ações iniciais são recomendadas para a replicação e acompanhamento:

• Passo 1 – Acesse seu banco de dados Amazon RDS através do hostname configurado pelo Amazon RDS (RDS endpoint), que estará disponível em alguns minutos após o lançamento, utilizando um cliente SQL da sua preferência, por exemplo SQLWorkbench e SQuirel, com os drivers JDBC para sua versão, ou instale o Oracle Client completo em usa estação, que já terá o utilitário de Data Pump.
• Passo 2 – Dentro de uma sessão SQL conectado neste banco de dados RDS configure um Database Link entre seu banco de dados destino e origem para que você possa acompanhar e comparar objetos a partir de um único local.

CREATE DATABASE LINK ORIGEM CONNECT TO dbaUserOrigem IDENTIFIED BY "DBA-PASSWORD-ORIGEM" using '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=origemIP-or-Hostname)(PORT=DBPORT))(CONNECT_DATA=(SID=PRODSID)))';

-- Execute uma query para verificar:
select username from dba_users@ORIGEM; 

• Passo 3 – Ainda na mesma sessão crie um diretório que será utilizado para logs do Data Pump

exec rdsadmin.rdsadmin_util.create_directory('dest_dir');

• Passo 4 – Crie as tablespaces, modifique os valores do nome da tablespace e tamanho.

create tablespace tablespace1 datafile size 200G;
create tablespace tablespace2 datafile size 100G;
create tablespace tablespace3 datafile size 500G;

• Passo 5 – Opcional para bancos menores com poucos objetos. Para bancos de dados com dezenas de tabelas e poucos relacionamentos o DMS pode ser utilizado para criar as tabelas, antes de populá-las.

Utilize o Data Pump para gerar o metadados. Embora as tabelas podem ser criadas pelo DMS para ambientes simples, sem levar dependências em consideração, a maneira mais completa e segura de levar os objetos e dependências é utilizando o utilitário Oracle Data Pump.

• • Crie um tnsnames “rdstnsnames” na sua máquina com o Oracle Client instalado, para se conectar remotamente de disparar a importação dos schemas;
  • MYUSER1, HR and COMMERC são exemplos, utilize seus Schemas, levantados nos passos anteriores na Origem;
  • Rdsuser password, são seus valores para usuário e senha;
  • Parallel somente pode ser utilizando na versão Enterprise Edition;
  • Atenção para o parâmetro content com “metadata_only” , isto garante que não serão importadas linhas nas tabelas:

impdp rdsuser/rdspassword@rdstnsnames network_link=ORIGEM \
schemas=MYUSER1,HR,COMMERC directory=dest_dir \
 logfile=metadataonly.log parallel=8 \
content=metadata_only TABLE_EXISTS_ACTION=SKIP 

# para acompanhamento o import pode-se realizar a seguinte query em uma sessão SQL no DB RDS:
select * from table(RDSADMIN.RDS_FILE_UTIL.READ_TEXT_FILE('DEST_DIR', metadataonly.log')); 

• Passo 6 – Somente se Não executou o Passo 5. Crie os schemas que receberão os dados no destino (Amazon RDS). Verifique quais privilégios diferente de Connect e Resource queria conceder.

CREATE USER MYUSER1 
    IDENTIFIED BY mypass1 
    DEFAULT TABLESPACE tbs1 
    QUOTA unlimited ON tbs1 
    TEMPORARY TABLESPACE temp;
GRANT CONNECT, RESOURCE to MYUSER;

• Passo 7 – Desabilite triggers e constraints das tabelas no RDS destino.

ALTER TABLE   MYUSER1.CUSTOMER    DISABLE ALL TRIGGERS ;
-- ao final da migração faça o contrário:
ALTER TABLE   MYUSER1.CUSTOMER    ENABLE ALL TRIGGERS ;
-- verifique na DBA_TABLES as tabelas

alter table MYUSER1.CUSTOMER disable constraint CONSTRAINAME; 
-- verifique na DBA_CONSTRAINTS as constrains para desabilitar
-- ao final realize a operação inversa
alter table MYUSER1.CUSTOMER enable constraint CONSTRAINAME; 
-- para tabelas que tenham registros que fogem à regra da constraint na Origem será necessário habilitar com “enable novalidate”

Utilizando o AWS Database Migration Service

Em alguns minutos você pode realizar a configuração do serviço de migração de banco de dados da sua origem para o RDS, mantendo a execução de seus aplicativos sem alteração, e se preferir pode mudar o banco de dados atual, por exemplo de Oracle 11g para Oracle 12c, ou de um patchset para outro dentro da mesma versão. Se desejar mudar de Oracle para Postgres, ou Amazon Aurora (MySQL), consulte nossa documentação do Schema Conversion Tool antes.

O serviço é composto de uma instância de replicação, a qual é responsável por rodar atividades de migração (tasks)  que você define, tendo sempre pelo menos uma origem e um destino (end points), porém pode existir mais de um destino para uma mesma origem, e também mais de uma origem para um único destino no caso de uma consolidação de schemas em uma única base de dados.

Figura 8 – Componentes da replicação

A seguir os passos para realizar o Setup.

• Passo 1 – Crie uma instância de Replicação. Selecione um tamanho de instância compatível com seu Workload, as menores instâncias tem menor capacidade de redes e memória, e devem ser utilizadas para volumes pequenos com dezenas de gigabytes.

Figura 9 – Passo 1, criando instância de replicação

• Passo 2 – Selecione a quantidade de memória, o security group, e  a rede (VPC), que deve ter acesso tanto à Origem quanto ao Destino. Escolha também uma chave de criptografia (KMS key). Verifique eu tenha privilégios para o KMS.

Figura 10 – Passo 2, parâmetros de segurança

• Passo 3 – Crie um endpoint para a Origem.

Figura 11 –Passo 3, criando endpoint de origem

• Passo 4 – Crie um endpoint para cada schema no Destino, utilizando como conexão o usuário (schema). Por exemplo endpoint MYUSER1, terá como usuário de conexão MYUSER1.  COMMERC user, terá outro endpoint e assim por diante. Isto evita com que objetos seja criados em usuários errados.

Figura 12 – Passo 4, crie um endpoint para cada Schema

• Passo 5 – Selecione a rede e a instância de replicação para cada endpoint e habilite o “Schema refresh” após teste de conexão.

Figura 13 – Passo 5, selecione a instância de replicação e rede

• Passo 6 – Crie Tasks. No parâmetro “Migration type” escolha migrar os dados existentes e replicação ongoing, desta forma além de migrar os dados o DMS vai manter um sincronismo entre a Origem e Destino:

Figura 14 – Passo 6

Nota “Tasks” são grupamentos de tabelas de um schema, que devem ser migradas em conjunto. Tabelas com relacionamento entre si ou dependências lógicas devem ser carregadas/replicadas nas mesmas tasks. Algumas tabelas com LOB segments atualizados frequentemente que não tenham dependências, podem ser retiradas das tasks para carrega-las com Data Pump ao final da migração.

• Passo 7 – Configure como carregar as tabelas. “Truncate” é interessante pois se precisar recarregar as tabelas em algum momento elas não serão recriadas (perdendo alguns metadados).  Sobre LOB segments a replicação contínua não é suportada para LOBs com colunas atualizadas. Porém pode ser usado como carga de dados. Sempre habilite “logging” para ter acesso a qualquer problema ocorrido.

Figura 15 –Passo 7

• Passo 8 – Selecione o Schema que vai migrar, neste caso todas as tabelas do Schema serão migradas

Figura 16 –Passo 8

Ou realize a configuração Custom, neste caso excluindo algumas tabelas que quiser, como abaixo, as tabelas BASKET e BASKET_SNAPSHOT foram retiradas da task por algum motivo, seja porque não se utiliza mais na aplicação ou por conter LOB segments que são atualizados, ainda não suportado pelo Oracle Logminer.

{
  "rules": [
  {     "rule-type": "selection",
       "rule-id": "1",
       "rule-name": "1",
       "object-locator": {"schema-name": "MYUSER1", "table-name": "%" },
"rule-action": "include"
  },
    {
    "rule-type": "selection",
        "rule-id": "2",
        "rule-name": "2",
        "object-locator": {
          "schema-name": "MYUSER1",
          "table-name": "BASKET_SNAPSHOT"
        },
        "rule-action": "exclude"
      },
      {
          "rule-type": "selection",
          "rule-id": "3",
          "rule-name": "3",
          "object-locator": {
            "schema-name": "MYUSER1",
            "table-name": "BASKET"
          },
          "rule-action": "exclude"
        }  
  ]
}

No caso acima “table-name”: “%“, significa levar todas as tabelas, na cláusula de número “1”, que tem “rule-action”: “include”, e excluir as tabelas das outras duas clásulas que tem “rule-action”: “exclude”.

Pode-se realizar ainda o contrário replicar somente algumas tabelas com include, conforma abaixo, levando somente os dados das tabelas CUSTOMERS e SALES:

{
  "rules": [
  {     "rule-type": "selection",
       "rule-id": "1",
       "rule-name": "1",
       "object-locator": {"schema-name": "MYUSER1", "table-name": "CUSTOMERS" },
"rule-action": "include"
  },
    {
    "rule-type": "selection",
        "rule-id": "2",
        "rule-name": "2",
        "object-locator": {
          "schema-name": "MYUSER1",
          "table-name": "SALES"
        },
        "rule-action": "include"
        }  
  ]
}

• DMS passo 9 – Após criadas as tasks podem ser iniciadas “Start”. E passam a mostrar um status de Running, Load complete, Error or Failed.

Figura 17 –DMS passo 9

Acompanhando sua migração

Além do painel de status, que se pode verificar o status geral, é possível acompanhar a migração tabela a tabela e também verificar as logs de replicação.

Para cada tabelas, após o Full Load da tabela, ela mostra o status de Completed e começa a logar as transações que ocorreram após o final da carga, podendo acompanhar os inserts, deletes e updates.

Figura 18 –Status de tabelas carregadas e comandos executados

Tabelas com status de error são ignoradas, e precisam ser analisadas se podem ou não ser ignoradas, ou se pelas logs pode-se corrigir algum problema para que seja carregadas. Neste caso a Task fica com status de Error porém continua rodando.

Quando as Tasks ficam com status de Failed não foi possível ignorar algum erro, e todas as tabelas ficam comprometidas. Por este motivo é interessante separar em Tasks separadas tabelas que não tenham dependência.

Acompanhar o andamento da replicação é importante para ter certeza de que as tabelas foram carregadas e replicadas corretamente.

Figura 19 –Status de tabelas após algum tempo de carga com milhares de registros atualizados

Clique no log da task para analisar as mensagens e solucionar algum problema que possa ter ocorrido. Por exemplo a falta de um domain index.

Figura 20 – Log da Task no cloudwatch mostrando problema em uma coluna do tipo LOB, que não tinha primary key on índices únicos.

Ao final da migração desative a aplicação, deixa o banco de dados de Origem sem atividade, então após as Tasks não terem mais atividades desative-as e faça as operações de ENABLE TRIGGERS e CONSTRAINTS mencionadas no início do tutorial.

Conclusão

Este artigo teve o objetivo de detalhar a migração de um Banco de Dados Oracle para o Amazon RDS, utilizando o Amazon DMS (Database Migration Service) e Oracle Data Pump para carregar os metadados. Como foi descrito há outras formas de migração tanto dos dados quanto dos metadados, e esta forma escolhida é bastante abrangente em tamanho de base e atende ambientes de maior complexidade também.

Resumidamente, seguem os passos principais utilizados para execução da migração:

• Criação de um banco de dados Oracle utilizando Amazon RDS;
• Migração dos metadados;
• Criação de um serviço de migração no Amazon DMS (Database Migration Service);
• Migração e sincronismo dos Dados;

Leitura Adicional

Amazon RDS para Banco de Dados Oracle – https://thinkwithwp.com/pt/rds/oracle/

Serviço de migração de banco de dados Amazon DMS – https://thinkwithwp.com/pt/dms/

Oracle como Origem para Amazon DMS – http://docs.thinkwithwp.com/dms/latest/userguide/CHAP_Source.Oracle.html

Oracle como Destino para Amazon DMS – http://docs.thinkwithwp.com/dms/latest/userguide/CHAP_Target.Oracle.html

Estratégias de migração de banco de dados Oracle para AWS – https://d0.awsstatic.com/whitepapers/strategies-for-migrating-oracle-database-to-aws.pdf

Comments? Questions? Talk to us