Informazioni su Oracle Data Guard

Puoi utilizzare Oracle Data Guard in un sistema DB. Oracle Data Guard offre funzionalità di High Availability, protezione dei dati e disaster recovery per i dati enterprise.

Per ulteriori informazioni su Oracle Data Guard, vedere Introduzione a Oracle Data Guard.

Criterio IAM necessario

Per utilizzare Oracle Cloud Infrastructure, un amministratore deve concedere l'accesso di sicurezza in un criterio. Questo accesso è necessario indipendentemente dal fatto che si stia utilizzando la console o l'API REST con un SDK, un'interfaccia CLI o unaltro strumento. Se viene visualizzato un messaggio che indica che non si dispone dell'autorizzazione o che non si dispone dell'autorizzazione, verificare con l'amministratore il tipo di accesso di cui si dispone e il compartimento di cui lavorare.

Se non si conoscono i criteri, vedere Guida introduttiva ai criteri e Criteri comuni.

Informazioni generali

La configurazione di Oracle Data Guard richiede almeno due database: uno in un ruolo primario e uno in un ruolo standby. I database primari e in standby costituiscono insieme una configurazione Data Guard. La maggior parte delle applicazioni accede al database primario. Un database in standby è una copia coerente a livello di transazione del database primario.

Data Guard Group offre la possibilità di creare e gestire più database in standby locale e remoto collegati a un database primario, offrendo flessibilità sia per la protezione dei dati che per il disaster recovery. In un gruppo Data Guard, un database primario può supportare fino a sei database in standby.

Oracle Data Guard gestisce il database di standby trasmettendo e applicando i redo data dal database primario. Se il database primario non è più disponibile, puoi utilizzare Data Guard per eseguire lo switchover o il failover del database di standby sul ruolo primario. Ciò è vero anche se si dispone di più database in standby.

• Switchover: uno switchover inverte i ruoli del database primario e del database di standby.
• Failover: un failover esegue la transizione del database di standby al ruolo primario dopo che il database primario esistente si è verificato in errore o non è raggiungibile.
• Ripristina: ripristina un database nel ruolo di standby in una configurazione Data Guard.

In una configurazione Data Guard tipica, vengono comunemente utilizzati due database in standby:

• Standby locale: un database di standby nella stessa area del database di produzione è ideale per scenari di failover, offrendo alcuna perdita di dati per errori locali (ad esempio errori del database, del cluster o del dominio di disponibilità). In questo caso, l'impatto del failover dell'applicazione viene ridotto, poiché le applicazioni continuano a funzionare senza il sovraccarico delle prestazioni dovuto alla comunicazione con un'area remota.
• Standby remoto (tra più aree): un database di standby remoto, situato in un'altra area, viene in genere utilizzato per il disaster recovery o per scaricare l'elaborazione delle query di sola lettura. Un'impostazione del database in standby remoto garantisce la protezione dei dati da errori regionali.

Alcuni clienti aziendali puntano alla simmetria dopo uno switch del sito. Ad esempio, potrebbero preferire avere sia lo standby primario che locale nell'Area 1, sia uno standby remoto con il proprio standby locale nell'Area 2. In questa configurazione saranno presenti tre database in standby. Dopo uno switch del sito, sarà comunque disponibile un database primario e uno standby locale nella nuova region primaria.

Inoltre, puoi migliorare le loro configurazioni aggiungendo un altro database in standby a scopo di test, sfruttando le nostre funzionalità di standby snapshot (lettura/scrittura).

Una configurazione Data Guard richiede almeno due sistemi DB, uno contenente il database primario e uno contenente il database di standby. Quando abiliti Data Guard per un database, viene creato un nuovo sistema DB con il database di standby e associato al database primario.

Ulteriori dettagli sui requisiti sono i seguenti:

• Le versioni e le edizioni del database devono essere identiche. Per i database 26ai, i database primario e in standby devono trovarsi nella stessa versione della release principale, mentre il database in standby può trovarsi in una versione secondaria superiore.
• Data Guard non supporta Oracle Database Standard Edition. (Active Data Guard richiede Enterprise Edition Extreme Performance).
• Ogni database in una configurazione Data Guard deve avere un valore di nome univoco (DB_UNIQUE_NAME) non utilizzato da altri database nei sistemi DB che ospitano la configurazione Data Guard. Tuttavia, il database primario e in standby possono utilizzare lo stesso valore DB_NAME del nome del database.
• L'edizione del database determina se è possibile utilizzare Active Data Guard (ADG). ADG è disponibile solo con Enterprise Edition Extreme Performance. Se si utilizza il modello di licenza BYOL e la licenza non include ADG, è necessario assicurarsi che ADG non sia abilitato durante la configurazione di Data Guard per Enterprise Edition Extreme Performance. In alternativa, è possibile utilizzare Enterprise Edition o Enterprise Edition High Performance, che non abilitano ADG per impostazione predefinita. Vedere Usa Oracle Data Guard con l'interfaccia CLI del database.
• Se i database primari e in standby si trovano nella stessa area, entrambi devono utilizzare la stessa rete cloud virtuale (VCN).
• Se i database primari e in standby si trovano in aree diverse, devi eseguire il peer delle reti cloud virtuali (VCN) per ogni database. Vedere Peering VCN remoto che utilizza un RPC.
• I database primari e in standby possono trovarsi in un'area diversa, ma devono trovarsi nello stesso realm.
• La password SYS e la password del wallet TDE dei database primario e in standby devono essere tutte uguali.
• È supportato anche un Data Guard tra più aree se il database utilizza OCI Vault per le chiavi TDE.

• Configurare le regole di entrata e di uscita della lista di sicurezza per le subnet dei sistemi DB in una configurazione Data Guard per consentire lo spostamento del traffico TCP tra le porte applicabili. Assicurarsi che le regole create siano con conservazione dello stato (impostazione predefinita).

  Ad esempio, se la subnet del sistema DB primario utilizza il CIDR di origine 10.0.0.0/24 e la subnet del sistema DB in standby utilizza il CIDR di origine 10.0.1.0/24, quindi creare le regole come mostrato nell'esempio successivo. Tenere presente che le regole di uscita nell'esempio mostrano come abilitare il traffico TCP solo per la porta 1521, che è un requisito minimo per il funzionamento di Data Guard. Se il traffico TCP è già abilitato su tutte le porte in uscita (0.0.0.0/0), non è necessario aggiungere in modo esplicito queste regole di uscita specifiche.

• I database in standby in OCI sono standby fisici.
• La creazione di un database di standby associato a un altro database di standby ("standby a cascata") non è supportata.
• È possibile creare una configurazione Data Guard quando il database viene cifrato utilizzando OCI Vault. Tuttavia, OCI Vault attualmente supporta la replica delle chiavi in una sola area remota. Di conseguenza, le configurazioni Data Guard tra più aree per i database che utilizzano OCI Vault sono limitate a due aree: l'area primaria e una remota. È possibile creare più database in standby all'interno di queste aree, ma le configurazioni che si estendono su tre o più aree non sono supportate.

Problemi noti

• In un Data Guard tra più aree, dopo aver eseguito uno switchover, non è possibile ruotare la chiave KMS del database nel nuovo database primario.
• In un Data Guard tra più aree, dopo aver eseguito uno switchover, non è possibile creare un PDB nel nuovo database primario.

Lista di sicurezza per la subnet nel sistema DB primario

Ingress Rules:
	Stateless: No
	Source: 10.0.1.0/24
	IP Protocol: TCPSource Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.1.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Lista di sicurezza per la subnet sul sistema DB in standby

Ingress Rules:
	Stateless: No
	Source: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Egress Rules:
	Stateless: No
	Destination: 10.0.0.0/24
	IP Protocol: TCP
	Source Port Range: All
	Destination Port Range: 1521
	Allows: TCP traffic for ports: 1521

Per informazioni sulla creazione e la modifica delle regole, vedere Elenchi sicurezza.

Considerazioni sul dominio di disponibilità e sul dominio di errore per Oracle Data Guard

Oracle consiglia che il sistema DB contenente il database di standby si trovi in un dominio di disponibilità diverso da quello del sistema DB contenente il database primario per migliorare la disponibilità e il disaster recovery. Se abiliti Oracle Data Guard per un database e il tuo database in standby si trova nello stesso dominio di disponibilità del database primario (per scelta o perché lavori in un'unica region del dominio di disponibilità), Oracle consiglia di posizionare il database in standby in un dominio di errore diverso da quello del database primario.

Nota: se i database primario e in standby sono database Oracle RAC a due nodi ed entrambi si trovano nello stesso dominio di disponibilità, solo uno dei due nodi del database in standby può trovarsi in un dominio di errore che non include altri nodi del database primario o in standby. Questo perché ogni dominio di disponibilità ha solo tre domini di errore e i database primario e in standby hanno un totale combinato di quattro nodi. Per ulteriori informazioni sui domini di disponibilità e sui domini di errore, vedere Aree e domini di disponibilità.