Migração física online com ZDM: do on-premises para o Exadata na OCI via Object Storage
Por Andrey Schulz – Especialista em Arquiteturas de Missão Crítica e Cloud
Na migração física online, o Oracle Zero Downtime Migration (ZDM) leva um banco on-premises para o Exadata na OCI. A produção só para durante o switchover do Data Guard, que normalmente leva minutos. Enquanto os dados são copiados e sincronizados, a origem segue atendendo as aplicações.
Este passo a passo usa MIGRATION_METHOD=ONLINE_PHYSICAL com DATA_TRANSFER_MEDIUM=OSS. O standby é instanciado a partir de backups RMAN gravados no Object Storage. O destino é o Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D). A arquitetura é mantida: um non-CDB vai como non-CDB, e um CDB vai como CDB, com seus PDBs.
Visão geral do fluxo
O ZDM instancia um standby no ExaDB-D a partir de backups no Object Storage, mantém esse standby sincronizado por Data Guard e faz o switchover na janela de corte.
As etapas 1 a 3 rodam com a produção no ar. A etapa 4 é o corte, e a origem passa a ser o standby que garante o fallback.
Pré-requisitos
Os requisitos abaixo vêm das seções 1.2.8, 3.3, 4.3 e 4.4 do guia oficial. O -eval verifica a maioria deles, mas alguns precisam ser preparados antes.
Origem
Item | Requisito |
|---|---|
Archivelog | Banco em modo ARCHIVELOG |
TDE | A partir do 12.2, wallet configurado e aberto (AUTOLOGIN preferencial); os dados não precisam estar criptografados na origem |
RMAN | CONFIGURE CONTROLFILE AUTOBACKUP ON durante a migração; evite que o backup existente rode ao mesmo tempo que o do ZDM |
Archive logs | Não apague archives que o ZDM ainda precisa para sincronizar o standby |
RAC | Snapshot controlfile em local compartilhado (evita ORA-00245) |
Grid Infrastructure | Banco registrado no srvctl |
Destino
Item | Requisito |
|---|---|
Criação | Banco destino criado pelo console da OCI (Control Plane), não pelo Grid |
DB_NAME | Igual ao da origem, inclusive em maiúsculas e minúsculas |
DB_UNIQUE_NAME | Diferente do da origem, para o Data Guard distinguir os dois |
Senha do SYS | Igual à da origem |
Backups automáticos | Desabilitados na criação |
Versão | Mesma versão da origem; patch level igual ou superior (diferença recomendada de até 1 ano) |
Time zone file | Versão igual ou superior à da origem (v$timezone_file) |
TDE | Wallet aberto, com master key definida |
Shape | Capaz de comportar a origem e o crescimento previsto |
Rede
Servidor ZDM → origem e destino: SSH, TCP 22.
Origem e destino → Object Storage: HTTPS, TCP 443.
Origem ↔ destino: SQL*Net no listener SCAN (TCP 1521 ou a porta em uso), nos dois sentidos. No modo online, essa ligação é obrigatória: é por ela que o redo trafega.
Origem e destino também precisam estar na mesma plataforma e endianness.
Passo 1: Instalação do servidor ZDM
O ZDM roda em um host dedicado, geralmente uma VM Oracle Linux 8, e orquestra tudo via SSH. Nada é instalado nos servidores de banco.
1.1 Preparar o host
Como root, crie o usuário do ZDM e instale as dependências. O comando oci-growfs só se aplica se o servidor ZDM for uma VM na OCI.
1.2 Instalação do software
Descompacte o kit baixado da Oracle. O zdm_home.zip que vem dentro dele não é descompactado: o caminho dele é informado no parâmetro ziploc.
1.3 Iniciar e validar o serviço
1.4 Chaves SSH
Cadastre a chave pública do zdmuser no authorized_keys do usuário com sudo na origem e no destino. Teste o acesso antes de seguir:
Passo 2: Object Storage, bucket e auth token
No modo online com OSS, o Object Storage guarda os backups RMAN usados para criar o standby. Depois disso, a sincronização segue por Data Guard via SQL*Net. O ZDM acessa o bucket com um usuário da OCI e um auth token.
2.1 Criar o bucket
Use o console ou o OCI CLI, em qualquer máquina com o CLI configurado. O CLI não é exigido no servidor ZDM.
2.2 Gerar o auth token
No console, abra o perfil do usuário da migração, vá em Auth tokens e gere um token. Guarde o valor: ele só aparece uma vez e é a senha pedida quando o zdmcli recebe -backupuser.
2.3 Namespace e endpoint
O namespace fica em Administration > Tenancy details > Object Storage settings e compõe o parâmetro HOST:
Passo 3: Preparação da origem e do destino
3.1 Origem
Confira o archivelog, o wallet TDE e o autobackup do controlfile:
Volte o autobackup para OFF ao final, caso esse não seja o padrão do ambiente. Se a origem for RAC em ASM, configure o snapshot controlfile em local compartilhado:
3.2 Destino: banco no ExaDB-D
O ZDM usa um banco criado no destino como template. Ele é descartado e recriado como standby da origem, mas mantém a configuração, inclusive parâmetros e SGA.
No console da OCI, crie no ExaDB-D um Database Home na mesma versão da origem, com patch level igual ou superior.
Crie o banco nesse Home com o mesmo DB_NAME da origem, na mesma caixa de letras, e um DB_UNIQUE_NAME diferente.
Use a mesma senha do SYS da origem.
Desmarque Enable automatic backups.
Mantenha a mesma arquitetura da origem, já que não há conversão neste cenário: non-CDB para non-CDB, CDB para CDB.
Confira se o time zone file é de versão igual ou superior à da origem e se o wallet TDE está aberto.
3.3 Conectividade SQL*Net
Teste nos dois sentidos antes do -eval. O Data Guard depende disso:
# Da origem para o destino
# Do destino para a origem
Na OCI, libere nas Security Lists ou NSGs a porta 1521 vinda da rede on-premises e a porta 22 vinda do servidor ZDM. No firewall on-premises, libere a porta 1521 vinda da OCI, já que o Data Guard trafega nos dois sentidos. Para o Object Storage (porta 443), o destino usa o Service Gateway da VCN, e a origem acessa pela internet ou pelo FastConnect.
Passo 4: Response file
Crie o response file em:
Senhas não vão no arquivo: o ZDM pede todas de forma interativa ou lê de wallets.
# Banco de destino
# Método, meio de transferência e plataforma
# Object Storage (endpoint Swift + bucket)
# Fallback: manter o envio de redo do novo primário (OCI) para a origem
Parâmetro | Função | Referência |
|---|---|---|
TGT_DB_UNIQUE_NAME | Precisa ser diferente do DB_UNIQUE_NAME da origem | E.40 |
MIGRATION_METHOD | ONLINE_PHYSICAL = standby com Data Guard + switchover | E.6 |
DATA_TRANSFER_MEDIUM | OSS = standby instanciado a partir de backups no Object Storage | E.2 |
PLATFORM_TYPE | EXACS = Exadata Database Service (vale também para Exascale) | E.11 |
HOST / OPC_CONTAINER | Endpoint e bucket; os dois são obrigatórios com OSS | E.9 |
SKIP_FALLBACK | FALSE (padrão) mantém o redo do primário na OCI chegando à origem após o switchover | E.13 |
SHUTDOWN_SRC | FALSE (padrão) mantém a origem ativa como standby | E.12 |
Passo 5: Avaliação pré-migração (-eval)
A flag -eval roda as pré-checagens sem alterar nada na origem nem no destino: SSH, sudo, SQL*Net nos dois sentidos, acesso ao bucket, TDE e compatibilidade de versão e patch.
-sourcedb recebe o db_unique_name da origem.
-backupuser é obrigatório com OSS. A senha pedida é o auth token do passo 2.2. Em tenancies federadas, o usuário costuma ter o formato oracleidentitycloudservice/<email>.
-tdekeystorepasswd e -tgttdekeystorepasswd pedem as senhas dos keystores TDE. Para execução não interativa, troque por -tdekeystorewallet e -tgttdekeystorewallet, apontando para wallets auto-login.
Acompanhe pelo ID retornado e só siga quando todas as fases estiverem COMPLETED, sem erros:
Passo 6: Execução, pausa antes do switchover e corte
A prática recomendada é rodar a migração com -pauseafter ZDM_CONFIGURE_DG_SRC. O ZDM cria e sincroniza o standby e para antes do switchover. Assim, o corte acontece só na janela combinada com o negócio.
6.1 Iniciar a migração
Para ver todas as fases do job e escolher outro ponto de pausa, rode o mesmo comando com -listphases.
6.2 O que acontece até a pausa
Validações e configuração do ambiente.
Backup RMAN da origem para o bucket.
Restore do standby no ExaDB-D, sobre o destino, com o mesmo DB_NAME da origem.
Configuração do Data Guard e início do envio de redo da origem para o standby.
Nesse ponto a produção continua na origem, e o standby na OCI se mantém sincronizado.
6.3 Acompanhar
O job fica como PAUSED após ZDM_CONFIGURE_DG_SRC. Antes do corte, confirme no standby que não há lag de transporte nem de apply:
6.4 Switchover (janela de corte)
Na janela, retome o job. O ZDM executa o switchover e a OCI vira o primário:
O downtime percebido vai do início do switchover até as aplicações se reconectarem ao destino. Deixe connect strings e services prontos com antecedência. Se alguma fase falhar, corrija a causa pelo log indicado no query job e rode resume job de novo.
Pós-migração, fallback e considerações
Fallback
Com SKIP_FALLBACK=FALSE, a origem on-premises vira standby do novo primário na OCI e continua recebendo redo. Se algo der errado depois do corte, um switchover de volta devolve a produção à origem sem perda de dados. Essa é a principal vantagem sobre o modo offline. A origem não entra na configuração do Data Guard Broker gerenciada pelo console da OCI, então o eventual retorno é feito manualmente.
Validação
Confirme que o banco na OCI abriu como PRIMARY e em READ WRITE. Valide os services e os testes funcionais das aplicações. Após o switchover, o banco aparece no console e pode ser gerenciado com srvctl.
Encerramento
Com o ambiente aprovado, desfaça a relação de Data Guard com a origem e descomissione o banco on-premises. Volte o CONTROLFILE AUTOBACKUP ao padrão anterior na origem, se ela for mantida. Reative os backups automáticos no ExaDB-D.
DR na nuvem
O ZDM 21.5 também pode entregar primary e standby já configurados na OCI, com o Broker restaurado após o switchover.
Referências
Oracle. Move to Oracle Cloud Using Zero Downtime Migration, G27612-01
Oracle. Oracle Zero Downtime Migration 21.5 – Product Overview
Portal do produto: oracle.com/goto/zdm
Licensing Information do Oracle Database 26ai: docs.oracle.com
Comentários