O Oracle AI Database 23.26.2 permite criar uma pluggable database (PDB) de standby e seus redo logs com um único comando do Data Guard Broker, eliminando a rotina de copiar arquivos manualmente que há muito tempo atrasava as configurações de recuperação de desastres.

Por que isso é importante

Criar uma PDB de standby física exigia uma cadeia de ações manuais: copiar cada datafile para o container de standby, construir os standby redo logs (SRLs) com comandos ALTER explícitos e conferir toda a configuração. Cada etapa traz o risco de erros de digitação, arquivos esquecidos ou grupos de logs incompatíveis, o que pode atrasar os testes de recuperação ou, no pior dos casos, comprometer o failover. Automatizar o processo reduz esses riscos e libera os DBAs para focarem em tarefas de nível superior.

Como as PDBs de standby eram construídas anteriormente

Na arquitetura multitenant, um CDB (container database) primário hospeda uma ou mais PDBs. Para proteger uma PDB, os administradores precisavam:

  • Identificar e copiar cada datafile do host primário para o de standby.
  • Criar manualmente os SRLs que espelhassem o layout de redo-log do primário.
  • Executar restores do RMAN ou comandos de duplicação para sincronizar o standby.
  • Executar uma série de etapas de verificação para garantir que o standby pudesse aceitar um switchover.

O fluxo de trabalho poderia levar várias horas, especialmente para PDBs grandes, e qualquer deslize poderia deixar o standby inutilizável.

O que a atualização 23.26.2 faz

A versão mais recente do Oracle AI Database incorpora as etapas necessárias ao Data Guard Broker. Ao emitir um único comando ADD PLUGGABLE DATABASE, o broker:

  1. Registra a nova PDB de standby no primário.
  2. Copia os datafiles necessários nos bastidores — sem necessidade de restore do RMAN ou cópia manual de arquivos.
  3. Gera os standby redo logs apropriados, adicionando-os automaticamente ao CDB de standby.
  4. Deixa a PDB em modo READ ONLY, pronta para um switchover de standby física.

O comando usado no teste foi:

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

Um teste no mundo real

O autor criou uma PDB de standby chamada AMOL em um CDB secundário (cdb2) que espelhava uma PDB primária no cdb1. O broker concluiu a operação instantaneamente. Nenhum restore do RMAN foi executado, nenhuma cópia manual de arquivos apareceu nos logs do SO e os grupos de standby redo log apareceram no catálogo sem qualquer comando ALTER DATABASE.

Ao abrir a PDB, ela foi alterada para READ ONLY, confirmando seu status de standby física. Uma verificação rápida dos datafiles provou que eles haviam sido provisionados no lado do standby. O redo apply já estava em execução, e o broker informou que a configuração estava pronta para um switchover.

Implicações para DBAs

A automação reduz a chance de erro humano e corta drasticamente o tempo entre o planejamento e o standby de produção. As equipes agora podem provisionar PDBs de standby em minutos, em vez de horas, o que é especialmente valioso para ambientes que criam novos serviços com frequência.

A contrapartida é uma dependência maior da lógica interna do Data Guard Broker. Alguns DBAs preferem criar seus próprios scripts para cada etapa para manter o controle granular ou para integrar com ferramentas de monitoramento personalizadas. Em configurações complexas — múltiplas redes, armazenamento heterogêneo ou layouts de redo não padronizados — os administradores ainda podem precisar verificar se os padrões do broker estão alinhados com suas políticas.

O que observar a seguir

A Oracle não anunciou novas extensões para essa automação, mas o movimento sugere que versões futuras podem transferir mais do fluxo de trabalho de DR multitenant para o broker. Fique atento a:

  • Suporte para tipos adicionais de standby (ex: PDBs de standby lógica).
  • Logs expandidos que mostrem as decisões do broker para fins de auditoria.
  • Verificações de compatibilidade com ferramentas de backup de terceiros que anteriormente dependiam de etapas manuais do RMAN.

Se a sua organização utiliza o Oracle AI Database em uma configuração de alta disponibilidade, testar o novo comando em um CDB de não-produção é a maneira mais rápida de avaliar o impacto.

Resumo: O Oracle AI Database 23.26.2 transforma uma configuração de PDB de standby de várias etapas e propensa a erros em uma operação de linha única, entregando uma recuperação de desastres mais rápida e confiável para ambientes multitenant.