Informazioni sulla configurazione di un database in standby per il recupero da errori irreversibili

Oracle Data Guard garantisce alta disponibilità, protezione dei dati e disaster recovery per i dati enterprise residenti in Oracle Database. Oracle Data Guard offre un set completo di servizi che creano, mantengono, gestiscono e monitorano uno o più database in standby per consentire ai database Oracle di produzione di sopravvivere a disastri e danneggiamenti dei dati.

Oracle Data Guard gestisce questi database in standby come copie del database di produzione. Se il database di produzione diventa non disponibile a causa di un'interruzione pianificata o non pianificata, Oracle Data Guard può passare da qualsiasi database in standby al ruolo di produzione, riducendo al minimo i tempi di inattività associati all'interruzione.

Architettura

Questa architettura mostra una configurazione di Oracle Data Guard con un database primario che trasmette i redo dati a un database in standby. Il database in standby si trova in remoto dal database primario per le operazioni di recupero da errori irreversibili e backup.

Descrizione dell'immagine dataguard-dr-db.png

dataguard-dr_db-oracle.zip

Oracle Data Guard utilizza Redo Transport Services e Apply Services per gestire la trasmissione dei dati di redo, l'applicazione dei dati di redo e le modifiche ai ruoli del database.

Questa architettura supporta i seguenti componenti di Oracle Data Guard:

• Servizi di trasporto di redo

  I servizi di trasporto di redo controllano il trasferimento automatico di dati redo dal database di produzione a una o più destinazioni di archiviazione.

  I servizi di trasporto di redo eseguono i task riportati di seguito.

  • Trasmettere i redo dati dal sistema primario ai sistemi in standby nella configurazione.
  • Gestisce il processo di risoluzione di eventuali lacune nei redo log file archiviati a causa di un errore di rete.
  • Rileva automaticamente i redo log file archiviati mancanti o danneggiati in un sistema in standby e recupera automaticamente i redo log file archiviati di sostituzione dal database primario o da un altro database in standby.
• Applica servizi

  I servizi applicano automaticamente i dati di redo nel database in standby per mantenere la coerenza con il database primario.

  I dati redo vengono trasmessi dal database primario e scritti nel redo log in standby sul database in standby. I dati di redo vengono applicati direttamente dai redo log file in standby, poiché vengono compilati utilizzando l'applicazione in tempo reale. I servizi di applicazione consentono anche l'accesso in sola lettura ai dati.

• Transizioni ruolo
  Grazie a Oracle Data Guard, puoi modificare il ruolo di un database da un database in standby a un database primario oppure da un database primario a un database in standby utilizzando un'operazione di switchover o di failover. Oracle Data Guard semplifica le transizioni dei ruoli e automatizza i failover.

  • Lo switchover è uno switchover dei ruoli tra il database primario e uno dei relativi database in standby. Lo switchover non garantisce alcuna perdita di dati. Questa procedura viene in genere eseguita per la manutenzione pianificata del sistema primario. Durante uno switchover, il database primario passa a un ruolo in standby e il database in standby passa al ruolo primario.
  • Un failover è quando il database primario non è disponibile. Il failover viene eseguito solo in caso di errore del database primario e il failover determina una transizione di un database in standby al ruolo primario. L'amministratore del database può configurare Oracle Data Guard in modo che non si verifichino perdite di dati.

Di seguito sono riportati alcuni passaggi manuali per la configurazione di Oracle Data Guard, tra cui, a titolo esemplificativo, gli elementi riportati di seguito.

• Prepara il database primario con i parametri consigliati
• Preparare gli alias TNS negli ambienti primari e in standby
• Creare il database in standby fisico come duplicazione del database primario
• Configura Data Guard

Questi passi manuali sono ampiamente documentati in più documenti Oracle. Questo playbook fornisce un insieme di script che è possibile utilizzare per automatizzare la maggior parte di queste azioni. Questi script aiutano a configurare Oracle Data Guard impostando un database in standby per un database primario esistente. Gli script utilizzano la funzione restore from service Oracle Recovery Manager (RMAN) e Oracle Data Guard Broker.

Prima di iniziare

Prima di configurare Oracle Data Guard utilizzando gli script forniti in questo documento, esaminare le ipotesi e i requisiti riportati di seguito.

• Il database primario esiste già.

• I nodi in standby esistono già, con o senza un database esistente.

  Nota:

  Se esiste già un database nella posizione in standby, gli script lo elimineranno prima di ricreare il database in standby.

• La connettività tra database primario e in standby avviene mediante la porta del listener del database.

  • Per i database a istanza singola, deve esistere una connessione bidirezionale tra l'host del database primario e l'IP e la porta del listener del database in standby.
  • Per i database Oracle Real Application Clusters (Oracle RAC), deve esistere una connessione bidirezionale tra gli host del database primario e la scansione del database in standby e gli IP e le porte VIP e le porte.

  Gli script eseguono controlli di connettività, ma è possibile utilizzare il comando nc -vw 5 -z IP PORT per verificare la connettività remota.

• Oracle Automatic Storage Management (Oracle ASM) viene utilizzato per i file di dati, i control file, i redo log in linea e i redo log di archivio.

  • Per i database a istanza singola, il file delle password e spfile possono trovarsi in file system normali o in Oracle ASM.
  • Per i database Oracle RAC, è necessario che il file delle password e spfile si trovino in Oracle ASM.
• I database primario e in standby vengono gestiti da Oracle Clusterware (è necessario installare Oracle Grid Infrastructure, in quanto le topologie singole e Oracle RAC utilizzano srvctl).
• Poiché vengono utilizzati i file gestiti Oracle, i parametri del database db_create_file_dest, db_create_online_log_dest_1 e db_recovery_file_dest devono essere già definiti nel database primario con la posizione appropriata del gruppo di dischi Oracle ASM (ad esempio +DATA o +RECO).
• Il proprietario del software RDBMS (Relational Database Management System), ad esempio l'utente oracle, imposta nel profilo le variabili di ambiente Oracle richieste (ORACLE_HOME, LD_LIBRARY_PATH, PATH, ORACLE_UNQNAME e ORACLE_SID).
• Si presume che venga utilizzata una topologia simmetrica (ovvero, se il database primario è un singolo database, il database in standby è un singolo database; se il database primario è un database Oracle RAC, il database in standby è anche un database Oracle RAC).
• Se i database sono Oracle RAC, si presume che ogni Oracle RAC abbia 2 nodi.
• Gli script sono validi per la configurazione di un database in standby per un database primario che non dispone già di un database in standby.
• Gli script sono validi anche per l'aggiunta di un nuovo database di standby aggiuntivo a un Oracle Data Guard esistente. Per questo scenario, è necessario utilizzare la proprietà ADDITIONAL_STANDBY=YES nel file delle proprietà. In questo caso, il nuovo standby viene aggiunto alla configurazione Data Guard Broker esistente.

Informazioni sulle funzioni dello script

Di seguito sono riportate le funzioni degli script.

• Gli script sono idempotenti: possono essere rieseguiti in caso di errori.
• È possibile configurare i nomi utente del sistema operativo (ad esempio oracle e grid) e le cartelle (Database home e Grid home).
• Gli utenti del sistema operativo Oracle e Grid possono essere lo stesso utente o utenti diversi.
• Transparent Data Encryption (TDE) per i file di database è facoltativo: gli script sono validi per entrambi i casi (TDE e nessun TDE).

  Nota:

  verrà eseguita una configurazione simmetrica: se il database primario utilizza TDE, il database in standby verrà configurato con TDE; se il database primario non utilizza TDE, il database in standby non utilizzerà TDE.
• Sono supportate Oracle home di sola lettura (ROOH). Gli script sono pronti a funzionare automaticamente in ambienti con ROOH e con Oracle home "tradizionali".
• Gli script sono validi sia per gli ambienti Oracle RAC che per quelli a istanza singola (in una topologia simmetrica).
• Gli script vengono convalidati nelle versioni 12c (12.2), 18c, 19c e 21c RDBMS.
• Gli script vengono convalidati negli ambienti Oracle Cloud Infrastructure (DB Systems) e on-premise.
• Gli script sono stati convalidati per configurare una Oracle Data Guard ibrida, dove il database primario è on premise e il database in standby è un sistema DB in Oracle Cloud Infrastructure.

Informazioni sui file script

Di seguito sono riportate le descrizioni dei file di script utilizzati in questa soluzione.

• 1_prepare_primary_maa_parameters.sh

  Si connette al database primario e lo configura con i parametri MAA (Oracle Maximum Availability Architecture) consigliati per Oracle Data Guard. Crea i redo log file in standby, imposta i valori per DB_BLOCK_CHECKSUM, DB_FLASHBACK_RETENTION_TARGET e così via. Questo script viene eseguito una sola volta, indipendentemente dal fatto che il database primario sia un Oracle Real Application Clusters (Oracle RAC) o un database a istanza singola.

• 2_dataguardit_primary.sh

  Prepara gli host primari per Oracle Data Guard. Aggiunge gli alias TNS necessari al file tnsnames.ora, controlla la connettività con il database in standby remoto, configura la cifratura di rete se non è già impostata e genera i file tar di output che contengono il file della password principale e il wallet Transparent Data Encryption (TDE) (se utilizzato).

• create_pw_tar_from_asm_root.sh

  Questo script non è sempre necessario. È obbligatorio solo quando il file della password principale è memorizzato in Oracle Automatic Storage Management (Oracle ASM). Crea un file tar di output con il password file.

• 3_dataguardit_standby_root.sh

  Prepara i nuovi host in standby e crea il database in standby utilizzando la funzione restore from service Oracle Recovery Manager (RMAN) e il broker Oracle Data Guard. Se in questi host è presente un database esistente (un database di lavoro o come risultato di un precedente tentativo di esecuzione dello script non riuscito), gli script verranno eliminati prima di ricreare il nuovo database come database in standby.

• DG_properties.ini

  Questo è il file delle proprietà che deve essere personalizzato con i valori specifici dell'ambiente. Viene utilizzato da tutti gli script, sia nel database primario che in standby.

Informazioni sui prodotti e i ruoli necessari

Questa soluzione richiede i seguenti ruoli per i sistemi di database primario e in standby:

Nome prodotto: Ruolo	Richiesto per...
Oracle Database: sys	eseguire tutti gli script
Host Oracle Database (primario): utente del sistema operativo oracle con autorizzazioni di esecuzione	eseguire i seguenti script: 1_prepare_primary_maa_parameters.sh 2_dataguardit_primary.sh
Host Oracle Database (primario): root	eseguire lo script seguente quando il file delle password principali è memorizzato in ASM: create_pw_tar_from_asm_root.sh
Host Oracle Database (secondario): root	eseguire lo script: 3_dataguardit_standby_root.sh

Consulta i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.