Documentazione dell'infrastruttura Oracle Cloud

Informazioni sui database in standby

Fornisce informazioni sull'abilitazione e sull'uso di Autonomous Data Guard per il disaster recovery su Autonomous Database.

Quando utilizzi Autonomous Data Guard, il sistema crea un database di standby che viene aggiornato continuamente con le modifiche del database primario. Puoi utilizzare Autonomous Data Guard con un database in standby nella region corrente, un database in standby locale o con uno o più database in standby in region diverse, database in standby tra più region oppure puoi aggiungere sia un database in standby locale che uno o più database in standby remoto.

Puoi anche creare un standby Autonomous Data Guard, locale o remoto in una tenancy diversa.

Nota

Autonomous Data Guard è disponibile con i tipi di carico di lavoro Data Warehouse ed Transaction Processing. Autonomous Data Guard non è disponibile con i tipi di carichi di lavoro JSON e APEX.

Scegliendo tra le opzioni di disaster recovery offerte da Autonomous Database, puoi scegliere le funzioni e le opzioni che soddisfano i requisiti RTO (Recovery Time Objective) e RPO (Recovery Point Objective).

Per impostazione predefinita, ogni istanza di Autonomous Database fornisce un database peer di Disaster Recovery basato su backup locale.

Per aggiungere il failover automatico e ridurre l'obiettivo RTO (Recovery Time Objective), puoi utilizzare un database di standby Autonomous Data Guard locale.

Per utilizzare l'opzione di disaster recovery più resiliente offerta da Autonomous Database, puoi aggiungere un database di standby Autonomous Data Guard locale e uno o più database di standby Autonomous Data Guard tra più aree.

Inoltre, altre opzioni che utilizzano il disaster recovery basato su backup ti consentono di fornire opzioni di disaster recovery RTO (Recovery Time Objective) a costi inferiori e più elevati rispetto ad Autonomous Data Guard. Vedere Usa Disaster Recovery basato sul backup per i dettagli sul Disaster Recovery basato sul backup.

Argomenti

Argomento padre: Utilizzare i database in standby con Autonomous Data Guard per il disaster recovery

Autonomous Data Guard con standby locale

Quando utilizzi un database di standby Autonomous Data Guard nell'area corrente, Autonomous Database esegue il provisioning di un database di standby locale e monitora il database primario; se il database primario diventa inattivo, l'istanza di standby assume automaticamente il ruolo dell'istanza primaria.

I database peer Autonomous Data Guard locali comportano il costo aggiuntivo delle CPU di base e dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database primario stesso. Le CPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer Autonomous Data Guard locale. Per ulteriori informazioni, consulta Oracle Autonomous Database Serverless Features Billing.

L'aggiunta di un database di standby locale fornisce un database di standby identico che consente, a seconda dello stato del database primario, di:

  • Se il database primario diventa inattivo, Autonomous Data Guard converte il database di standby in database primario con un'interruzione minima. Al termine del failover, Autonomous Data Guard crea automaticamente un nuovo database di standby.

  • È possibile eseguire un'operazione di switchover in cui il database primario diventa il database in standby e il database in standby diventa il database primario.

Autonomous Database non fornisce l'accesso a un database di standby nell'area corrente. Si eseguono tutte le operazioni, ad esempio lo scale up del conteggio ECPU (conteggio OCIPU se il database utilizza le OCPU) e l'abilitazione della scala automatica di computazione nel database primario, e Autonomous Data Guard esegue quindi le stesse azioni nel database di standby locale. Allo stesso modo, si eseguono solo azioni quali l'arresto o il riavvio del database nel database primario.

Un database di standby locale viene creato nella stessa area del database primario (area corrente). Per una migliore resilienza, viene eseguito il provisioning del database in standby come indicato di seguito.

  • Nelle aree con più domini di disponibilità, il provisioning di un database in standby locale viene eseguito automaticamente in un dominio di disponibilità diverso da quello del database primario.

  • Nelle aree con un singolo dominio di disponibilità, il provisioning di un database in standby locale viene eseguito automaticamente in un dominio di errore diverso da quello del database primario, ovvero in una macchina fisica diversa.

Per ulteriori informazioni sui domini di disponibilità, vedere Visualizza informazioni di rete nella console OCI e Aree e domini di disponibilità.

Tutte le funzioni di Autonomous Database dal database primario sono disponibili quando l'istanza di standby locale diventa primaria, dopo il guasto del sistema o dopo l'esecuzione di un'operazione di switchover, tra cui:

  • Opzioni del database: le opzioni di licenza Conteggio ECPU (Conteggio OCIPU se il database utilizza OCPU), Storage, Nome visualizzato, Nome database, Ridimensionamento automatico, Tag e BYOL hanno gli stessi valori dopo un failover al database in standby o dopo aver eseguito uno switchover.

  • Notebook OML: i notebook e gli utenti creati nel database primario sono disponibili in standby.

  • Dati e metadati APEX: le informazioni APEX create nel database primario vengono copiate in standby.

  • ACL: la lista di controllo dell'accesso (ACL) del database primario è duplicata per lo standby.

  • Endpoint privato: l'endpoint privato del database primario si applica allo standby.

    Oracle consiglia di utilizzare l'opzione subnet regionale per garantire disponibilità e latenza ottimali per i database in un endpoint privato quando si crea la subnet. Per ulteriori informazioni, vedere Creazione di una subnet.

  • API o script: qualsiasi API o script utilizzato per gestire l'Autonomous Database continua a funzionare senza modifiche dopo un'operazione di failover o dopo aver eseguito uno switchover.

  • Connessioni alle applicazioni client: le applicazioni client non devono modificare le stringhe di connessione per connettersi al database dopo un failover al database in standby o dopo aver eseguito uno switchover.

  • Connessioni basate su wallet: è possibile continuare a utilizzare i wallet esistenti per connettersi al database dopo un failover al database in standby o dopo aver eseguito uno switchover.

Informazioni sulle funzioni tra più aree e tra tenancy di Autonomous Data Guard

Fornisce informazioni sulle funzioni e sul funzionamento di Autonomous Data Guard con un database di standby tra più aree o tra più tenancy.

Quando aggiungi un database di standby in un'altra area, se l'istanza primaria diventa inattiva, Autonomous Data Guard fornisce un database di standby fisicamente separato in un'area remota. Il database di standby è disponibile per assumere il ruolo dell'istanza primaria non disponibile. Quando aggiungi un database di standby in una tenancy diversa, Autonomous Data Guard fornisce un database di standby che si trova in una tenancy diversa. Il database di standby è disponibile per assumere il ruolo dell'istanza primaria non disponibile.

Un database di standby tra più aree è una replica del database primario e può essere utilizzato per il recupero in caso di errore o quando il database primario non è disponibile. L'abilitazione di Autonomous Data Guard con uno standby tra più aree fornisce una soluzione RTO bassa per il disaster recovery nel caso in cui un'intera area non sia disponibile o quando il database primario è inattivo per qualsiasi motivo.

I database di standby tra più aree di Autonomous Data Guard comportano il costo aggiuntivo delle CPU di base e il doppio dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database peer remoto. Le CPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer remoto. Il numero di CPU di base viene specificato dal numero di ECPU (OCPU se il database utilizza OCPU) come mostrato nel campo Conteggio ECPU (Conteggio OCPU) della console di Oracle Cloud Infrastructure.

Autonomous Database consente di creare uno o più database peer di disaster recovery remoti, a seconda del modello di computazione:

  • Modello di computazione OCPU: puoi aggiungere un database in standby remoto in un'area abbinata. Le aree abbinate sono aree remote in cui è possibile creare un peer tra più aree.

  • Modello di computazione ECPU: puoi aggiungere più peer di disaster recovery remoti, con un massimo di un peer in ogni area remota accoppiata. Ad esempio, se il database primario si trova nell'area IAD, è possibile aggiungere un database in standby in PHX e un database in standby in SJC, ma non è possibile aggiungere due peer di disaster recovery remoti in PHX.

Le region abbinate sono region remote in cui puoi creare un database di standby tra più aree. Per ulteriori informazioni sulle aree accoppiate, consulta la sezione relativa alle aree accoppiate tra più aree di Autonomous Database.

È possibile eseguire quasi tutte le operazioni, ad esempio lo scale-up del conteggio ECPU (conteggio OCIPU se il database utilizza le OCPU) e l'abilitazione della scala automatica di computazione nel database primario. Autonomous Data Guard esegue quindi le stesse azioni sul database di standby tra più aree.

Dopo aver aggiunto un database in standby remoto, Autonomous Database fornisce l'accesso al database in standby remoto dalla console di Oracle Cloud Infrastructure. Autonomous Database fornisce l'accesso al database di standby remoto in modo da poter eseguire alcune operazioni in modo indipendente sul database di standby remoto, ad esempio configurando reti e VCN per gli endpoint privati e aggiungendo l'applicazione di tag per definire chiavi e valori non replicati tra il database primario e il database di standby remoto.

Nota

Autonomous Data Guard non esegue il failover automatico per uno standby tra più aree. Se il database primario non è disponibile e uno standby locale non è disponibile, è possibile eseguire un failover manuale per fare in modo che un database di standby tra più aree assuma il ruolo primario.

Non è possibile connettersi a uno standby tra più aree mentre opera come database di standby e non è disponibile per le operazioni di sola lettura. È possibile connettersi al database nei seguenti casi:

Le seguenti aree presentano differenze per il failover o lo switchover dal database primario a un database in standby remoto, se confrontate con il failover o lo switchover a uno standby locale:

  • Nome visualizzato: il nome visualizzato ha un'estensione "_region". Dove regione è il nome dell'area, ad esempio IAD o BOM.

    Se il peer tra più aree è stato creato prima dell'introduzione del supporto per più pari livello tra più aree, il nome visualizzato del peer tra più aree ha un'estensione "_Remote".

  • Notebook OML: dopo uno switchover o un failover tra più aree, i notebook OML del database primario di cui è stato eseguito lo switchover o il failover non sono presenti nel database primario (il database primario corrente dopo la modifica del ruolo). È possibile creare nuovi notebook OML.

  • Endpoint privato: è possibile configurare e aggiornare in modo indipendente gli endpoint privati su un database di standby prima del failover o prima di eseguire uno switchover. Ciò consente di disporre di un endpoint privato configurato in modo diverso, dopo il failover o dopo l'esecuzione dello switchover. Autonomous Database non mantiene sincronizzata la configurazione di rete dal database primario a quello remoto.

    Il peering VCN e l'inoltro del dominio sono necessari affinché i wallet funzionino in tutte le region, con database autonomi con un endpoint privato con standby Autonomous Data Guard, in cui il database primario e in standby si trovano in VCN diverse. See Remote VCN Peering using an RPC and DNS in Your Virtual Cloud Network for information on VCN peering and domain forwarding.

  • Elenco di controllo dell'accesso di rete: per impostazione predefinita, un database primario di disaster recovery e i database peer remoti utilizzano le stesse liste di controllo dell'accesso di rete (ACL, Network Access Control List). Se si desidera, è possibile modificare in modo indipendente le ACL di rete su un database peer remoto. Ciò consente di utilizzare ACL diverse in un database peer remoto.

    Per ulteriori informazioni, vedere Gestire le ACL di rete peer remoto.

  • Tag: le tag vengono gestite in modo indipendente su un database primario di disaster recovery e su un database peer remoto. Ciò significa che:

    • Quando si aggiunge, rimuove o aggiorna una tag su un peer remoto, la modifica si applica solo al database peer remoto.

    • Quando si aggiunge, aggiorna o rimuove una tag nel database primario, la tag non viene aggiunta, aggiornata o rimossa nei database peer remoti.

  • API o script: qualsiasi API o script utilizzato per gestire l'Autonomous Database potrebbe dover essere aggiornato per chiamare le API nel database primario.

    Puoi anche utilizzare variabili di sostituzione predefinite negli URL Oracle Cloud Infrastructure (OCI) per il failover tra più aree per Autonomous Database quando utilizzi le API REST OCI. Per ulteriori informazioni, vedere Variabili di sostituzione negli URL di Oracle Cloud Infrastructure (OCI).

    Per le connessioni mTLS, è necessario scaricare un wallet dal database primario, dal database primario corrente, dopo un failover o dopo aver eseguito uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Applicazioni client: le applicazioni client devono connettersi utilizzando le stringhe di connessione e il wallet scaricato dal database primario, dal database primario corrente, dopo un failover o dopo l'esecuzione di uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Connessioni basate su wallet: è necessario scaricare un wallet e connettersi utilizzando le stringhe di connessione del database primario, il database primario corrente, per connettersi al database dopo un failover o dopo l'esecuzione di uno switchover. Per ulteriori informazioni, vedere Stringhe e wallet di connessione di disaster recovery tra più aree.

  • Strumenti Autonomous Database: gli strumenti dispongono di URL diversi nel database primario, nel database primario corrente, dopo un failover o dopo l'esecuzione di uno switchover (gli URL degli strumenti non cambiano per uno switchover o un failover in uno standby locale):

    • Azioni database

    • Oracle APEX

    • Oracle REST Data Services (ORDS)

    • Graph Studio

    • Oracle Machine Learning Notebooks

    • Trasformazioni dei dati

    • API MongoDB

  • Uso di Oracle Cloud Infrastructure Object Storage: dopo aver eseguito il failover o lo switchover dal database primario a un database in standby, nel database primario (il database primario corrente) le credenziali e gli URL che forniscono l'accesso allo storage degli oggetti continuano a funzionare come prima del failover o dello switchover, fornendo l'accesso a quanto segue:

    • Tabelle esterne

    • Tabelle partizionate esterne

    • Tabelle partizionate ibride esterne

    Nota

    Ciò si applica quando lo storage degli oggetti è disponibile. Per scenari rari in cui lo storage degli oggetti non è disponibile, Oracle consiglia di disporre di backup o repliche dello storage degli oggetti in un'area diversa. Se lo storage degli oggetti non è disponibile, ovvero la risorsa di storage degli oggetti utilizzata con il primario prima di uno switchover o di un failover, è possibile aggiornare le credenziali utente e i parametri che impostano gli URL per lo storage degli oggetti in modo che i parametri specifichino i valori per accedere allo storage degli oggetti di un'area disponibile. Per ulteriori informazioni, vedere Utilizzo della replica.

Autonomous Data Guard tra tenancy con standby tra più aree

Puoi abilitare Autonomous Data Guard tra tenancy con uno standby tra più aree. Quando aggiungi un database di standby Autonomous Data Guard tra tenancy in un'area diversa, Autonomous Database esegue il provisioning di un database di standby tra più aree nella tenancy di destinazione. Con uno standby Autonomous Data Guard tra tenancy, puoi eseguire il failover, eseguire lo switchover o creare uno standby snapshot con uno standby tra più aree in una tenancy diversa. Questa funzione consente di utilizzare Autonomous Data Guard per eseguire la migrazione di un database in una tenancy diversa.

Per ulteriori informazioni, vedere Usa un database di standby Autonomous Data Guard cross-tenancy.

OCI Full Stack Disaster Recovery con un Autonomous Data Guard Cross-Region Standby

Quando Full Stack Disaster Recovery è abilitato, la pagina dei dettagli di Autonomous Database, in Disaster Recovery, mostra il campo Full Stack DR come Enabled.


Segue la descrizione di adb_full_stack_dr_enabled.png
Descrizione dell'immagine adb_full_stack_dr_enabled.png

Per ulteriori informazioni, consulta Usa OCI Full Stack Disaster Recovery con Autonomous Database.

Argomenti

Argomento padre: Informazioni sui database in standby

Ruolo di Autonomous Data Guard Database

Dopo aver aggiunto un database di standby tra più aree, ogni database ha un ruolo designato: standby primario, standby o standby snapshot.

Il ruolo specifica lo stato corrente di un database, un database primario, uno standby o uno standby snapshot e questo valore cambia dopo aver eseguito uno switchover o un failover o dopo aver convertito un database di standby in uno standby snapshot. È possibile visualizzare il ruolo di Autonomous Database nell'icona che mostra accanto al nome visualizzato nella pagina Informazioni su Autonomous Database. Ad esempio:

Segue la descrizione di adb_adg_primary.png
Descrizione dell'immagine adb_adg_primary.png

Segue la descrizione di adb_adg_standby.png
Descrizione dell'immagine adb_adg_standby.png

Dopo aver aggiunto un database di standby tra più aree, è possibile visualizzare il ruolo nell'area Disaster recovery nella pagina dei dettagli. Il ruolo è uno dei seguenti:

  • In Ruolo viene visualizzato Principale nel database primario.

  • Dopo uno switchover o un failover, nello stesso database il ruolo mostra Standby.

  • Dopo aver convertito un peer tra più aree in uno standby snapshot, il ruolo viene visualizzato come Standby snapshot.

Per visualizzare i dettagli di un peer, nella pagina dei dettagli di Autonomous Database selezionare la scheda Disaster recovery. La lista mostra le informazioni sul database peer e la colonna Ruolo peer mostra il ruolo peer:

  • In standby (locale): la colonna ruolo peer mostra In standby e il database ha lo stesso nome visualizzato nella colonna Autonomous Database peer. La colonna Area mostra il nome dell'area corrente.

  • In standby (tra più aree) la colonna Ruolo peer mostra In standby per un database in standby remoto e il database ha lo stesso nome con un'estensione "_regione" nella colonna Peer Autonomous Database. È possibile fare clic sul collegamento per accedere al database remoto. La colonna Area mostra il nome dell'area remota.

    Se il peer tra più aree è stato creato prima dell'introduzione del supporto per più pari livello tra più aree, il nome visualizzato del peer tra più aree ha un'estensione "_Remote".

  • Standard snapshot: la colonna Ruolo peer mostra Standard snapshot. La colonna Area mostra il nome dell'area remota.

Failover e switchover tra più aree di Autonomous Data Guard

Puoi avere un peer di disaster recovery locale e, facoltativamente, puoi aggiungere uno o più peer tra più aree (più peer tra più aree sono consentiti con il modello di computazione ECPU). In entrambi i casi locali e tra più aree, il peer può essere una copia di Disaster Recovery basata su backup o uno standby Autonomous Data Guard.

Con un'area corrente e uno o più database peer Autonomous Data Guard tra più aree, a seconda dello stato del database primario, hai le seguenti opzioni:

  • Se il database primario diventa inattivo e il database di standby locale è disponibile, Autonomous Data Guard esegue automaticamente il failover per convertire il database di standby locale nel database primario, con un'interruzione minima. Al termine del failover, Autonomous Data Guard crea automaticamente un nuovo database di standby locale. Se il failover automatico non è possibile, è possibile eseguire un failover manuale.

    Autonomous Data Guard continua a utilizzare gli stessi database peer tra più aree.

  • Se il database primario diventa inattivo e il database in standby locale non è disponibile, è possibile eseguire un failover manuale in un database peer tra più aree e il database peer tra più aree di cui si esegue il failover diventa il database primario.

    In questo caso, una volta completato il failover, Autonomous Data Guard non crea un nuovo database di standby locale (per impostazione predefinita, si dispone di un peer di copia di backup).

  • È possibile eseguire un'operazione di switchover, in cui il database primario diventa il database di standby locale e il database di standby locale diventa il database primario.

    Autonomous Data Guard continua a utilizzare gli stessi database peer tra più aree.

  • È possibile eseguire un'operazione di switchover, in cui un database peer tra più aree diventa il database primario e il database che era il database primario viene ricreato come nuovo database di standby in modo che diventi un database peer.

    Uno switchover modifica i ruoli del database primario e di un database peer. Se si esegue uno switchover due volte tra le stesse due aree remote, il database primario torna a essere di nuovo il database primario.

Backup e ripristino tra più aree di Autonomous Data Guard Database

Dopo aver aggiunto un database di standby tra più aree Autonomous Data Guard, il backup e il ripristino dal backup vengono gestiti come indicato di seguito.

  • Se il database primario viene ripristinato da un backup, viene creato un nuovo standby remoto dal database primario ripristinato.

  • I backup automatici vengono eseguiti solo sul database primario (il database che mostra il ruolo: principale). Ad esempio, dopo uno switchover o un failover, il database con il ruolo Primary inizia a eseguire i backup automatici. Un database con il ruolo In standby non esegue più i backup. Se si esegue di nuovo lo switchover, il database che diventa il database dei ruoli Principale inizia a eseguire di nuovo i backup.

  • Non è possibile eseguire il ripristino o la copia da un backup quando un database peer si trova nel ruolo In standby. I backup vengono eseguiti solo sul database nel ruolo Principale e l'operazione di ripristino non è disponibile nella console di Oracle Cloud Infrastructure in un database Standby.

Stringhe e wallet di connessione Disaster Recovery tra più aree

Quando si aggiunge un database di standby tra più aree (remote) di Autonomous Data Guard o si utilizza un peer di Disaster Recovery basato su backup tra più aree, il wallet e la stringa di connessione del database primario contengono solo il nome host del database primario.

Inoltre, il wallet e la stringa di connessione da un database peer remoto contengono solo il nome host del database remoto. Ciò vale sia per i wallet delle istanze che per quelli regionali.

Oracle consiglia di configurare le applicazioni in esecuzione nel database dei ruoli primari in modo che utilizzino il wallet o la stringa di connessione scaricati dal database primario. Per le applicazioni eseguite su un database remoto, utilizzare il wallet o la stringa di connessione scaricata dal database remoto (dove il database remoto è il database primario corrente dopo un failover o dopo l'esecuzione di uno switchover). È possibile ottenere queste stringhe di connessione o il wallet facendo clic su Connessione al database nella console di Oracle Cloud Infrastructure.

Ad esempio, se Autonomous Data Guard tra più aree è impostato con il database primario in Ashburn (IAD) e un database di standby tra più aree in Phoenix (PHX), Oracle consiglia di utilizzare le applicazioni di livello intermedio in esecuzione in IADstringa di connessione o wallet dal database primario in IAD e dalle applicazioni corrispondenti che vengono eseguite in PHX dopo un failover o dopo aver eseguito uno switchover, utilizzare la stringa di connessione o il wallet dal database di standby in PHX. Durante il failover o lo switchover regionale, Oracle consiglia di eseguire il failover del database e delle applicazioni di livello intermedio sul nuovo database dei ruoli primario per ottenere prestazioni ottimali e ridurre al minimo qualsiasi latenza tra più aree.

Per ulteriori informazioni, vedere Scarica credenziali client (wallet).

Se richiesto dall'applicazione, è possibile creare manualmente stringhe di connessione contenenti nomi host del database primario e remoto, per supportare la connessione a un'istanza disponibile e aperta per le connessioni automaticamente, al database primario o remoto.

Per i dettagli sui passi per creare manualmente queste stringhe di connessione, vedere:

Autonomous Data Guard con chiavi gestite dal cliente

Quando aggiungi un standby tra più aree di Autonomous Data Guard, ci sono considerazioni speciali quando il database primario utilizza chiavi gestite dal cliente o se desideri passare all'uso di chiavi gestite dal cliente nel database primario.

Nota

Autonomous Database supporta più provider di chiavi gestite dal cliente. Solo Oracle Cloud Infrastructure Vault è supportato per l'uso con Autonomous Data Guard. Altri vault non sono supportati per le chiavi gestite dal cliente.

Affinché uno standby remoto possa utilizzare la stessa chiave di cifratura master del database primario, è necessario replicare la chiave di cifratura master nell'area remota. Le chiavi di cifratura gestite dal cliente sono supportate solo con un singolo standby Autonomous Data Guard tra più aree. Più standby tra più aree non sono supportati perché Oracle Cloud Infrastructure Vault supporta solo la replica in un'area remota.

Considerare i seguenti casi:

  • L'aggiunta di un standby remoto Autonomous Data Guard è consentita se Autonomous Database utilizza chiavi gestite dal cliente. Quando il database utilizza una chiave gestita dal cliente e si aggiunge un standby tra più aree di Autonomous Data Guard, la lista Area nella finestra di dialogo Aggiungi database peer mostra solo le aree che contengono il vault e le chiavi replicati. Se non viene visualizzata un'area remota elencata, devi replicare il vault e le chiavi nell'area in cui desideri il database in standby (questa deve essere un'area abbinata).

  • Il passaggio alle chiavi gestite dal cliente è consentito sul database primario quando si dispone di un standby tra più aree di Autonomous Data Guard. Nel caso in cui il database utilizzi chiavi gestite da Oracle e passi a chiavi gestite dal cliente sul database primario, vengono visualizzate solo le chiavi replicate sia nell'area primaria che in quella in standby. Le liste Gestisci chiave di cifratura Vault e Chiave di cifratura primaria mostrano solo vault e chiavi replicati nelle region primarie e in standby. Se non viene visualizzata una chiave elencata, replicare il vault e le chiavi in un'area associata.

Per ulteriori informazioni, vedere gli argomenti riportati di seguito.

Replica dei backup in un database di standby Autonomous Data Guard tra più aree

Quando aggiungi un database di standby Autonomous Data Guard tra più aree, puoi abilitare la replica di backup tra più aree in modo che i backup automatici dal database primario siano disponibili anche in un'area remota.

Per impostazione predefinita, i backup eseguiti sul database primario non vengono replicati in un database di standby tra più aree. Quando abiliti la replica di backup tra più aree, fino a 7 giorni di backup automatici per il database primario vengono replicati in un database di standby tra più aree. Quando questa funzione è abilitata, i backup automatici sono disponibili nell'area remota come indicato di seguito.

  • Dopo uno switchover o un failover, è possibile ripristinare o duplicare qualsiasi indicatore orario negli ultimi sette (7) giorni o qualsiasi indicatore orario nel periodo di conservazione specificato quando il periodo di conservazione è impostato su meno di sette giorni.

  • Tutti i backup per il primario replicati nell'area remota vengono eliminati nel peer dell'area remota dopo sette giorni o dopo il numero di giorni del periodo di conservazione quando il periodo di conservazione è impostato su meno di sette giorni.

  • Non puoi modificare il periodo di conservazione dei backup per i backup replicati, tranne se modifichi il periodo di conservazione dei backup nel database primario per specificare un valore inferiore a sette giorni. In questo caso, il periodo retention per i backup replicati nell'area remota corrisponde al periodo retention backup automatico impostato nel database primario.

La replica del backup tra più aree comporta un costo aggiuntivo. Per ulteriori informazioni, consulta Oracle Autonomous Database Serverless Features Billing.

Per ulteriori informazioni, vedere Aggiungere un database in standby tra più aree e Abilitare o disabilitare la replica di backup per un database in standby tra più aree esistente.

Tenere presente quanto riportato di seguito per la replica di backup automatico tra più aree.

  • Dopo uno switchover o un failover, mentre il database tra più aree si trova nel ruolo primario, i backup vengono eseguiti sul database primario corrente e vengono replicati nel database di standby (remoto) corrente.

  • In un'area remota è possibile creare una copia da un backup replicato mentre il database si trova nel ruolo In standby.

Licenza BYOL per Autonomous Data Guard tra più aree

Il limite ECPU BYOL impostato su un database primario Autonomous Data Guard non si applica a un database in standby Autonomous Data Guard tra più aree o tra più tenancy.

In uno standby tra più aree o cross-tenancy puoi impostare in modo indipendente il limite ECPU BYOL, a seconda delle esigenze. L'impostazione di un valore per il limite di licenze BYOL limita il numero di ECPU coperte dalle licenze BYOL.

Ad esempio, prendi in considerazione un database primario Autonomous Data Guard da 8 ECPU che utilizza la licenza BYOL. Quando aggiungi un database in standby tra più aree o tenancy, il database in standby acquisisce la relativa licenza dal database primario (utilizzando la licenza BYOL).

In questo esempio, se si imposta il limite di licenza BYOL su 4 (ECPU) nel database primario, 4 delle 8 ECPU utilizzano la licenza BYOL. Tuttavia, il limite di licenza BYOL impostato sul database primario non si applica in standby tra più aree o tra tenancy. La licenza Bring Your Own License (BYOL) (senza un limite di licenza BYOL). Se si imposta separatamente un limite di licenza BYOL per lo standby, ad esempio se si imposta il valore Limite di licenza BYOL su 2 (ECPU), 2 ECPU nello standby vengono fatturate utilizzando la licenza BYOL e 6 ECPU. Analogamente, il limite ECPU BYOL impostato in Standby non ha effetto sul limite ECPU BYOL del database primario.

Per ulteriori informazioni, consulta Scegli l'opzione Bring Your Own License durante il provisioning o la clonazione e Scegli il modello di computazione ECPU (Bring Your Own License on Autonomous Database).

Obiettivo RTO (Autonomous Data Guard Recovery Time Objective) e RPO (Recovery Point Objective)

Autonomous Data Guard monitora il database primario e, se l'istanza diventa inattiva, l'istanza di standby locale assume il ruolo dell'istanza primaria, in base al Recovery Time Objective (RTO) e al Recovery Point Objective (RPO).

Se un'istanza di standby Autonomous Data Guard locale non è disponibile e hai abilitato il disaster recovery tra più aree, puoi eseguire manualmente il failover allo standby tra più aree.

Se non aggiungi uno standby Autonomous Data Guard tra più aree, hai la possibilità di aggiungere un peer Disaster Recovery basato su backup tra più aree. Vedere RTO (Backup-Based Disaster Recovery Time Objective) e RPO (Recovery Point Objective) per dettagli su RTO e RPO con Disaster Recovery basato su backup.

L'RTO è il tempo massimo necessario per ripristinare la connettività del database a un database in standby dopo l'avvio di un failover manuale o automatico. L'RPO è la durata massima della potenziale perdita di dati nel database primario.

Standby Autonomous Data Guard locale

Quando si aggiunge un database di standby locale, Autonomous Data Guard fornisce le opzioni riportate di seguito per il failover o lo switchover.

  • Failover o switchover automatici:

    Quando abiliti Autonomous Data Guard, puoi selezionare un limite di perdita di dati. Il limite di perdita di dati predefinito per il failover automatico è 0 (i valori validi sono compresi tra 0 e 3600 secondi). Ad esempio, un limite di perdita di dati pari a 0 significa che Autonomous Data Guard esegue il failover automatico solo quando non si verifica alcuna perdita di dati. Ciò significa che se Autonomous Data Guard è in grado di verificare che non vi sia alcuna perdita di dati, non riesce automaticamente in caso di problema. Quando si verifica un problema e Autonomous Data Guard determina che la possibile perdita di dati è maggiore del limite di perdita di dati, il failover automatico non si verifica e hai la possibilità di eseguire un failover manuale.

  • Failover manuale: l'RTO è di due (2) minuti e l'RPO di 10 secondi

Standby Autonomous Data Guard tra più aree

Quando aggiungi un database di standby tra più aree, i numeri RTO e RPO per il failover al database di standby tra più aree di Autonomous Data Guard sono i seguenti:

  • Switchover: l'RTO è inferiore a dieci (10) minuti e l'RPO è zero (0).

  • Failover automatico: non disponibile

  • Failover manuale: l'RTO è inferiore a dieci (10) minuti e l'RPO è fino a un (1) minuto.

Per ulteriori informazioni, vedere gli argomenti riportati di seguito.

Operazioni di Autonomous Data Guard

Autonomous Data Guard fornisce un set di operazioni per gestire un database in standby, tra cui: abilitare, eseguire lo switchover, disconnettere o arrestare un database in standby.

Operation Descrizione
Converti in standby istantanea

La conversione di un peer di disaster recovery in uno standby snapshot apre il database in modalità di lettura-scrittura e il peer di disaster recovery tra più aree interrompe temporaneamente l'aggiornamento dei dati dal database di origine.

Per ulteriori informazioni, vedere Converti peer tra più aree in standby snapshot.

Disabilita Autonomous Data Guard

Se disponi di un database in standby locale o di un database in standby tra più aree, puoi modificare il tipo di disaster recovery in Backup-Based Disaster Recovery per lo standby locale o puoi interrompere uno standby tra più aree. In entrambi i casi, la disabilitazione di Autonomous Data Guard termina il database di standby.

Per i dettagli, vedere Aggiorna standby per utilizzare un peer di copia di backup o Disabilita un database in standby tra più aree.

Disconnetti in standby

Quando si disconnette un database in standby tra più aree, l'associazione del database in standby viene annullata dal database primario. In questo modo il database viene convertito da un database peer a un database standalone. Dopo l'operazione di disconnessione non è consentito riconnettersi al primario.

Per ulteriori informazioni, vedere Disconnetti database peer e Disconnetti database snapshot in standby.

Abilita Autonomous Data Guard

Se stai utilizzando il disaster recovery basato su backup, puoi aggiornare il tuo tipo di disaster recovery in Autonomous Data Guard locale (area corrente) oppure puoi aggiungere uno standby tra più aree di Autonomous Data Guard.

Per i dettagli, vedere Abilita Autonomous Data Guard e Aggiungi un database in standby tra più aree.

Failover - Automatico

Dopo aver aggiunto un database di standby Autonomous Data Guard locale, il sistema monitora l'istanza primaria e esegue automaticamente il failover in un database di standby locale in determinati scenari.

Per ulteriori informazioni, vedere Failover automatico con un database in standby.

Failover - Manuale

Se il database primario non è disponibile, è possibile eseguire un failover manuale per modificare i ruoli in modo da rendere un database di standby il database primario:

  • Se è disponibile uno standby locale, è possibile eseguire manualmente il failover allo standby locale (non si dispone dell'opzione per eseguire il failover a uno standby remoto se è disponibile uno standby locale).
  • Se uno standby locale non è disponibile, hai la possibilità di eseguire manualmente il failover in uno standby remoto.

Per informazioni dettagliate, vedere Eseguire un failover manuale.

Switchover

Quando Autonomous Data Guard è abilitato, lo switchover modifica i ruoli del database primario e dello standby, il database di standby diventa il database primario e il database primario diventa lo standby. Se hai sia un database di standby locale (current region) che un database di standby tra più aree (remote), puoi scegliere di eseguire lo switchover allo standby locale o allo standby remoto.

Per informazioni dettagliate, vedere Eseguire uno switchover.

Termina

Se si desidera arrestare l'istanza primaria, selezionare Altre azioni e Termina. L'arresto dell'istanza primaria termina anche un database di standby locale.

Se disponi sia di un database di standby locale (area corrente) che di un database di standby tra più aree, devi arrestare il database di standby tra più aree prima di arrestare il database primario.

Per informazioni dettagliate, vedere Terminare un database in standby tra più aree.

Stato Disaster Recovery di Autonomous Database

Autonomous Database fornisce informazioni sullo stato di disaster recovery nella pagina Dettagli di Autonomous Database.

Nell'area Disaster recovery:

Il campo Ruolo mostra il ruolo del database corrente, come indicato di seguito.

  • Quando si dispone di un peer di copia di backup locale o di uno standby Autonomous Data Guard locale, nella console di Oracle Cloud Infrastructure viene visualizzato il valore del campo Ruolo Principale. Autonomous Database non fornisce l'accesso a un database di standby locale (o a un peer di copia di backup locale).

  • Quando si utilizza un peer di copia di backup tra più aree o uno standby Autonomous Data Guard tra più aree, la console di Oracle Cloud Infrastructure mostra il valore del campo Ruolo Principale se si sta visualizzando il database primario e mostra In standby se si stanno visualizzando i dettagli per un database in standby.

  • Switchover: fornisce un collegamento che consente di eseguire un'operazione di switchover.

  • Failover: quando il database primario non è disponibile e si dispone di uno standby locale e di un failover automatico non riusciti, il collegamento di failover consente di avviare un failover manuale.

    Quando il database primario non è disponibile e non è possibile eseguire il failover in standby tra più aree e in standby locale, il collegamento di failover consente di avviare un failover manuale nel database di standby remoto.

Per visualizzare le informazioni sull'Autonomous Database peer, nella pagina dei dettagli di Autonomous Database selezionare la scheda Disaster recovery. Mostra le informazioni sull'Autonomous Database peer. La colonna Stato mostra lo stato di un database in standby, come indicato di seguito.

  • Provisioning

    • Questo stato mostra quando si abilita Autonomous Data Guard e indica che viene eseguito il provisioning di un database di standby (fino a quando lo stato del database di standby non viene modificato in Standby).

    • Questo stato viene visualizzato dopo un failover in standby locale durante la ricreazione di un database di standby locale.

    • Questo stato mostra se viene eseguita un'operazione di ripristino dal backup nel database primario, lo standby locale viene ricreato e la colonna Stato mostra il provisioning.

  • Standby: indica che un database in standby è disponibile e pronto per un'operazione di switchover o di failover.

    Nota

    Quando un database in standby viene arrestato, lo stato in standby mostra In standby. Un database in standby non mostra mai lo stato Arrestato.

  • Modifica del ruolo in corso: indica che è stata avviata un'operazione di failover o switchover.

Eventi Autonomous Data Guard

Puoi utilizzare gli eventi di Oracle Cloud Infrastructure per rispondere quando Autonomous Database cambia il suo stato a causa di un evento correlato ad Autonomous Data Guard, come un'operazione di failover o switchover.

Gli eventi di Autonomous Database includono quanto segue:

  • Avvia failover automatico
  • Termina failover automatico
  • Inizia a disabilitare Autonomous Data Guard
  • Avvia abilitazione di Autonomous Data Guard
  • Avvia failover
  • Avvia switchover
  • Termina disabilitazione di Autonomous Data Guard
  • Termina abilitazione di Autonomous Data Guard
  • Terminare il failover con il risultato del failover di operazione riuscita o non riuscita.
  • Terminare lo switchover con il risultato dello switchover di operazione riuscita o non riuscita.

In base agli eventi è possibile eseguire azioni o inviare notifiche. Per ulteriori informazioni sull'uso degli eventi e sulla produzione delle notifiche, vedere Eventi e notifiche per un database in standby.