Oracle AI Database 23.26.2 consente di avviare una standby pluggable database (PDB) e i relativi redo log con un singolo comando Data Guard Broker, eliminando la routine di copia manuale dei file che da tempo rallentava le configurazioni di disaster recovery.

Perché è importante

La creazione di una PDB in modalità physical standby richiedeva una serie di azioni manuali: copiare ogni datafile nel container standby, creare i standby redo logs (SRL) tramite comandi ALTER espliciti e verificare l'intera configurazione. Ogni passaggio comporta il rischio di errori di battitura, file mancanti o gruppi di log non corrispondenti, il che può ritardare i test di ripristino o, nel peggiore dei casi, compromettere il failover. Automatizzare il processo riduce tali rischi e permette ai DBA di concentrarsi su attività di livello superiore.

Come venivano create le PDB standby in precedenza

Nell'architettura multitenant, un CDB (container database) primario ospita una o più PDB. Per proteggere una PDB, gli amministratori dovevano:

  • Identificare e copiare ogni datafile dall'host primario a quello standby.
  • Creare manualmente gli SRL che rispecchiassero la struttura dei redo log del primario.
  • Eseguire restore RMAN o comandi di duplicazione per sincronizzare lo standby.
  • Eseguire una serie di passaggi di verifica per garantire che lo standby potesse accettare uno switchover.

Il flusso di lavoro poteva richiedere diverse ore, specialmente per PDB di grandi dimensioni, e qualsiasi errore poteva rendere lo standby inutilizzabile.

Cosa fa l'aggiornamento 23.26.2

L'ultima release di Oracle AI Database integra i passaggi necessari all'interno del Data Guard Broker. Eseguendo un singolo comando ADD PLUGGABLE DATABASE, il broker:

  1. Registra la nuova PDB standby con il primario.
  2. Copia i datafile necessari in background — senza necessità di restore RMAN o copia manuale dei file.
  3. Genera i relativi standby redo logs, aggiungendoli automaticamente al CDB standby.
  4. Lascia la PDB in modalità READ ONLY, pronta per uno switchover in modalità physical standby.

Il comando utilizzato nel test è stato:

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

Un test nel mondo reale

L'autore ha creato una PDB standby denominata AMOL su un CDB secondario (cdb2) che rispecchiava una PDB primaria su cdb1. Il broker ha completato l'operazione istantaneamente. Non è stato eseguito alcun restore RMAN, non sono apparse copie manuali di file nei log del sistema operativo e i gruppi di standby redo log sono comparsi nel catalogo senza alcun comando ALTER DATABASE.

L'apertura della PDB l'ha commutata in modalità READ ONLY, confermando il suo stato di physical standby. Un rapido controllo dei datafile ha dimostrato che erano stati provisionati sul lato standby. L'applicazione dei redo (redo apply) era già in esecuzione e il broker ha segnalato che la configurazione era pronta per uno switchover.

Implicazioni per i DBA

L'automazione riduce la possibilità di errore umano e abbatte i tempi che intercorrono tra la pianificazione e la messa in produzione dello standby. I team possono ora provisionare PDB standby in pochi minuti anziché in ore, il che è particolarmente prezioso per gli ambienti che avviano nuovi servizi frequentemente.

Il compromesso è una maggiore dipendenza dalla logica interna del Data Guard Broker. Alcuni DBA preferiscono scrivere script per ogni passaggio per mantenere un controllo granulare o per integrare strumenti di monitoraggio personalizzati. In configurazioni complesse — reti multiple, storage eterogenei o layout dei redo non standard — gli amministratori potrebbero comunque dover verificare che i valori predefiniti del broker siano allineati con le proprie policy.

Cosa aspettarsi in futuro

Oracle non ha annunciato ulteriori estensioni di questa automazione, ma la mossa suggerisce che le versioni future potrebbero spostare una parte maggiore del workflow di DR multitenant all'interno del broker. Prestare attenzione a:

  • Supporto per tipi di standby aggiuntivi (ad es., PDB in modalità logical standby).
  • Logging esteso che mostri le decisioni del broker per scopi di audit.
  • Controlli di compatibilità con strumenti di backup di terze parti che precedentemente si affidavano a passaggi RMAN manuali.

Se la vostra organizzazione utilizza Oracle AI Database in una configurazione ad alta disponibilità, testare il nuovo comando su un CDB non di produzione è il modo più rapido per valutarne l'impatto.

In sintesi: Oracle AI Database 23.26.2 trasforma una configurazione di PDB standby multi-fase e soggetta a errori in un'operazione a riga singola, offrendo un disaster recovery più veloce e affidabile per gli ambienti multitenant.