Informazioni sui database in standby

Fornisce informazioni sull'abilitazione e sull'uso di Autonomous Data Guard per il recupero da errori irreversibili in Autonomous Database.

Quando si utilizza Autonomous Data Guard, il sistema crea un database di standby che viene continuamente aggiornato con le modifiche apportate dal 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ù aree oppure puoi aggiungere sia un database in standby locale che uno o più database in standby remoto.

Inoltre, puoi creare uno 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 Elaborazione delle transazioni. Autonomous Data Guard non è disponibile con i tipi di carico di lavoro JSON e APEX.

Selezionando 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 il RTO (Recovery Time Objective), è possibile utilizzare un database di standby Autonomous Data Guard locale.

Per utilizzare l'opzione di disaster recovery più resiliente offerta da Autonomous Database, è possibile 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ù elevate rispetto ad Autonomous Data Guard. Vedere Usa recupero in seguito a calamità basato su backup per dettagli sul recupero in seguito a calamità basato su backup.

Temi

Autonomous Data Guard con standby locale

Quando si utilizza un database di standby Autonomous Data Guard nell'area corrente, Autonomous Database esegue il provisioning di un database di standby locale e il monitoraggio del 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 di storage con scala automatica, fatturato sul database primario stesso. Le CPU con ridimensionamento automatico del database primario non vengono fatturate in modo aggiuntivo sul 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 quanto riportato di seguito, a seconda dello stato del database primario.

  • Se il database primario diventa inattivo, Autonomous Data Guard converte il database di standby nel 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. È possibile eseguire tutte le operazioni, ad esempio eseguire lo scale-up del conteggio ECPU (conteggio OCPU se il database utilizza OCPU) e abilitare il ridimensionamento automatico della computazione nel database primario, quindi Autonomous Data Guard esegue le stesse azioni nel database di standby locale. Allo stesso modo, è possibile eseguire solo azioni come 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 di standby come indicato di seguito.

  • Nelle aree con più domini di disponibilità, il provisioning di un database di 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 di standby locale viene eseguito automaticamente in un dominio di errore diverso da quello del database primario (ovvero su un computer fisico diverso).

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

Tutte le funzioni di Autonomous Database del database primario sono disponibili quando l'istanza di standby locale diventa primaria, dopo il failover del sistema o dopo l'esecuzione di un'operazione di switchover, inclusi i seguenti:

  • Opzioni database: il conteggio ECPU (conteggio OCPU se il database utilizza OCPU), lo storage, il nome visualizzato, il nome del database, la scala automatica, le tag e le opzioni di licenza BYOL hanno gli stessi valori dopo un failover al database di standby o dopo lo switchover.

  • Notebook OML: le 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 nel database in standby.

  • ACL: la lista di controllo dell'accesso (ACL, Access Control List) del database primario viene duplicata per il database in standby.

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

    Oracle consiglia di utilizzare l'opzione Subnet regionale per la disponibilità e la 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 Autonomous Database continua a funzionare senza modifiche dopo un'operazione di failover o dopo l'esecuzione di 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 di 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 di standby o dopo aver eseguito uno switchover.

Autonomous Data Guard con standby tra più aree

Quando si aggiunge 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.

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 a basso costo 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 di storage con ridimensionamento automatico, fatturato sul database peer remoto. Le CPU con scala automatica del database primario non vengono fatturate per l'aggiunta 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) nella console di Oracle Cloud Infrastructure.

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

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

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

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

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

Dopo aver aggiunto un database di standby remoto, Autonomous Database fornisce l'accesso al database di 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 la configurazione di reti e VCN per gli endpoint privati e l'aggiunta 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 far sì che un database di standby tra più aree assuma il ruolo primario.

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

Le aree riportate di seguito presentano differenze per il failover o lo switchover dal database primario a un database in standby remoto, rispetto al failover o allo switchover a un database in standby locale.

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

    Se è stato creato il peer tra più aree prima dell'introduzione del supporto per più peer 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 cui failover non è riuscito 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 in 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 di uno switchover. Autonomous Database non mantiene sincronizzata la configurazione di rete dal database primario al database in standby remoto.

    Il peering VCN e l'inoltro del dominio sono necessari affinché i wallet funzionino tra le region, con database autonomi con un endpoint privato con un database di standby Autonomous Data Guard, in cui il database primario e il database di standby si trovano in VCN diverse. Per informazioni sul peering VCN e sull'inoltro dei domini, consulta la sezione relativa al peering VCN remoto tramite RPC e al DNS nella tua rete cloud virtuale.

  • Lista 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, Access Control List). Se si desidera, è possibile modificare in modo indipendente le ACL di rete in un database peer remoto. Ciò consente di utilizzare ACL diverse in un database peer remoto.

    Per ulteriori informazioni, vedere Gestione delle 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 in un peer remoto, la modifica si applica solo al database peer remoto.

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

  • API o script: qualsiasi API o script utilizzato per gestire Autonomous Database deve essere aggiornato per chiamare le API nel database primario, il database primario corrente, dopo un failover o dopo aver eseguito uno switchover.

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

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

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

  • Autonomous Database Strumenti: gli strumenti hanno URL diversi nel database primario, nel database primario corrente, dopo un failover o dopo aver eseguito uno switchover (gli URL degli strumenti non cambiano per uno switchover o un failover in uno standby locale):

    • Database Actions

    • Oracle APEX

    • Oracle REST Data Services (ORDINI)

    • Graph Studio

    • Oracle Machine Learning Notebooks

    • Trasformazioni dati

    • API MongoDB

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

    • Tabella esterna

    • Tabella partizionata esterna

    • Tabelle con partizione ibrida esterna

    Nota

    Questa condizione si applica quando lo storage degli oggetti è disponibile. Per gli scenari rari in cui lo storage degli oggetti non è disponibile, Oracle consiglia di disporre di backup o replica dello storage degli oggetti in un'area diversa. Se lo storage degli oggetti non è disponibile (ossia la risorsa di storage degli oggetti utilizzata con il database 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 più tenancy con standby tra più aree

Puoi abilitare Autonomous Data Guard tra più tenancy con un standby tra più aree. Quando aggiungi un database di standby Autonomous Data Guard tra più 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 più 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 a una tenancy diversa.

Per ulteriori informazioni, vedere Usa un database di standby Autonomous Data Guard tra più tenancy.

OCI Full Stack Disaster Recovery con un standby tra più aree di Autonomous Data Guard

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



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

Argomenti

Ruolo Autonomous Data Guard Database

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

Il ruolo specifica lo stato corrente di un database, di un database primario, di uno standby o di uno standby snapshot e questo valore cambia dopo aver eseguito uno switchover o un failover oppure dopo aver convertito un database di standby in uno standby snapshot. È possibile visualizzare il ruolo Autonomous Database nell'icona che mostra accanto al nome visualizzato nella pagina Informazioni di 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 della pagina dei dettagli. Il ruolo è uno dei seguenti:

  • Nel Ruolo viene visualizzato Principale nel database primario.

  • Dopo uno switchover o un failover, nello stesso database il ruolo mostra In 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. Nella colonna Area viene visualizzato 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. Nella colonna Area viene visualizzato il nome dell'area remota.

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

  • Snapshot standby: la colonna Ruolo peer mostra Snapshot standby. Nella colonna Area viene visualizzato il nome dell'area remota.

Failover e switchover tra aree di Autonomous Data Guard

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

Sia con un'area corrente che con 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 non è possibile eseguire il failover automatico, è possibile scegliere di eseguire il failover manuale.

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

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

    In questo caso, al termine del failover, Autonomous Data Guard non crea un nuovo database di standby locale (per impostazione predefinita è disponibile un peer di copia di backup).

  • È possibile eseguire un'operazione di switchover in cui il database primario diventa il database in standby locale e il database in 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 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 di Autonomous Data Guard, il backup e il ripristino dal backup vengono gestiti come riportato 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 nel database primario (il database che mostra 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 accetta più i backup. Se si esegue di nuovo lo switchover, il database che diventa il database del ruolo 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 nel database nel ruolo Principale e l'operazione di ripristino non è disponibile dalla console di Oracle Cloud Infrastructure in un database in standby.

Stringhe e wallet di connessione per il disaster recovery tra più aree

Quando si aggiunge un database di standby tra più aree (remoti) 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 dal 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 di istanza 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 scaricata dal database primario. Per le applicazioni eseguite su un database remoto, utilizzare il wallet o la stringa di connessione scaricata dal database remoto (in cui il database remoto è il database primario corrente dopo un failover o dopo l'esecuzione di uno switchover). Per ottenere queste stringhe di connessione o il wallet, fare clic su Connessione al database nella console di Oracle Cloud Infrastructure.

Ad esempio, se l'Autonomous Data Guard tra più aree è impostato con il database primario in Ashburn (IAD) e un database in standby tra più aree in Phoenix (PHX), Oracle consiglia alle applicazioni di livello medio in esecuzione in IAD di utilizzare il stringa 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 sia del database che delle applicazioni di livello medio nel nuovo database dei ruoli primari 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 di database primari e remoti per supportare la connessione a un'istanza disponibile e aperta automaticamente per le connessioni, 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 si aggiunge uno standby tra più aree di Autonomous Data Guard, ci sono considerazioni speciali quando il database primario utilizza chiavi gestite dal cliente o se si desidera 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é un database in 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 database di standby Autonomous Data Guard tra più aree. I database di 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 uno 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 uno standby tra più aree di Autonomous Data Guard, la lista Region nella finestra di dialogo Aggiungi database peer mostra solo le aree che contengono il vault e le chiavi replicati. Se non viene elencata alcuna region remota, devi replicare il vault e le chiavi nell'area in cui desideri il tuo database di standby (questa deve essere un'area associata).

  • Il passaggio alle chiavi gestite dal cliente è consentito sul database primario quando si dispone di uno 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 nella region primaria che in quella standby. La lista Gestisci chiave di cifratura Vault e Chiave di cifratura master mostra solo i vault e le chiavi replicati sia nella region primaria che in quella standby. Se una chiave non viene visualizzata nell'elenco, replica 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 dei 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 si abilita 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 database primario replicato nell'area remota vengono eliminati nel peer dell'area remota dopo sette giorni o dopo il numero di giorni del periodo di conservazione in cui il periodo di conservazione è impostato su meno di sette giorni.

  • Non è possibile modificare il periodo di conservazione del backup per i backup replicati, tranne se si modifica il periodo di conservazione del backup sul database primario per specificare un valore inferiore a sette giorni. In questo caso, il periodo di conservazione per i backup replicati nell'area remota corrisponde al periodo di conservazione del backup automatico impostato sul database primario.

La replica di 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 di standby tra più aree e Abilitare o disabilitare la replica di backup per un database di 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 è nel ruolo primario, i backup vengono eseguiti sul database primario corrente e vengono replicati nel database di standby corrente (remoto).

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

Licenze BYOL Autonomous Data Guard per più aree

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

In un database di standby tra più aree o più tenancy è possibile impostare in modo indipendente il limite ECPU BYOL, a seconda delle esigenze. L'impostazione di un valore per Limite di licenza 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 una licenza BYOL. Quando si aggiunge un standby tra più aree o tra più tenancy, il database di standby acquisisce le proprie licenze dal database primario (utilizzando le licenze BYOL).

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

Per ulteriori informazioni, consulta la sezione relativa all'opzione Bring Your Own License durante il provisioning o la clonazione e scegliere Bring Your Own License su Autonomous Database (ECPU Compute Model).

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

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 a Recovery Time Objective (RTO) e Recovery Point Objective (RPO).

Se un'istanza di standby Autonomous Data Guard locale non è disponibile ed è stato abilitato il disaster recovery tra più aree, è possibile eseguire manualmente il failover nel database di standby tra più aree.

Se non si aggiunge un database di standby Autonomous Data Guard tra più aree, è possibile aggiungere un peer di disaster recovery basato su backup tra più aree. Per informazioni dettagliate su RTO e RPO con disaster recovery basato su backup, vedere Router Recovery Time Objective (RTO) e Recovery Point Objective (RPO).

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

Autonomous Data Guard locale - In standby

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 automatico:

    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 indica 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 si verifichi alcuna perdita di dati, il failover viene eseguito automaticamente in caso di problemi. 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 si ha 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 si aggiunge un database di standby tra più aree, i numeri RTO e RPO per il failover nel database di standby tra più aree di Autonomous Data Guard sono i seguenti:

  • Switchover: l'RTO è inferiore a dieci (10) minuti e l'RPO è pari a 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 di standby, tra cui: abilitare, eseguire lo switchover, disconnettere o arrestare un database di standby.

Operation descrizione;
Converti in standby snapshot

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 arresta 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 si dispone di un database di standby locale o di un database di standby tra più aree, è possibile modificare il tipo di disaster recovery in Backup-Based Disaster Recovery per il database di standby locale oppure arrestare un database di 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 di standby tra più aree.

Disconnetti in standby

Quando disconnetti uno standby tra più aree, l'associazione dello standby al database primario viene annullata. Questo converte il database da un database peer a un database standalone. Dopo l'operazione di disconnessione non è consentito riconnettersi al database primario.

Per ulteriori informazioni, vedere Disconnettere un database peer e Disconnettere uno snapshot in standby.

Abilita Autonomous Data Guard

Se si utilizza il disaster recovery basato su backup, è possibile aggiornare il tipo di disaster recovery in Autonomous Data Guard locale (area corrente) oppure è possibile aggiungere un database di standby tra più aree di Autonomous Data Guard.

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

Failover - Automatico

Dopo aver aggiunto un database di standby Autonomous Data Guard locale, il sistema monitora l'istanza primaria ed esegue automaticamente il failover su 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 e rendere un database di standby il database primario.

  • Se è disponibile un database in standby locale, è possibile eseguire manualmente il failover sul database in standby locale (non è possibile eseguire il failover su un database in standby remoto se è disponibile un database in standby locale).
  • Se non è disponibile uno standby locale, è possibile eseguire manualmente il failover in uno standby remoto.

Per ulteriori informazioni, vedere Eseguire un failover manuale.

Switchover

Quando Autonomous Data Guard è abilitato, lo switchover modifica i ruoli del database primario e del database in standby, il database in standby diventa il database primario e il database primario diventa il database in standby. Se si dispone sia di un database di standby locale (area corrente) che di un database di standby tra più aree (remoto), è possibile scegliere di eseguire lo switchover al database di standby locale o al database di standby remoto.

Per ulteriori informazioni, vedere Eseguire uno switchover.

Arresta

Se si desidera terminare l'istanza primaria, selezionare Altre azioni e Arresta. L'arresto dell'istanza primaria comporta anche l'interruzione di un database di standby locale.

Se si dispone sia di un database di standby locale (area corrente) che di un database di standby tra più aree, è necessario arrestare il database di standby tra più aree prima di arrestare il database primario.

Per i dettagli, vedere Terminare un database di standby tra più aree.

Stato di 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, la console di Oracle Cloud Infrastructure mostra 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 un database di 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 di un database di standby.

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

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

    Quando il database primario non è disponibile e si dispone di uno standby tra più aree e non è possibile eseguire il failover in uno standby locale, il collegamento di failover consente di avviare un failover manuale al 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 in corso
    • Questo stato viene visualizzato quando si abilita Autonomous Data Guard e indica che è in corso il provisioning di un database in standby (fino a quando lo stato del database in standby non viene modificato in In standby).

    • Questo stato viene visualizzato dopo un failover in uno standby locale quando viene ricreato un database di standby locale.

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

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

    Nota

    Quando un database di standby viene arrestato, lo stato di standby mostra In standby. Un database in standby non mostra mai lo stato Interrotto.
  • Modifica del ruolo in corso: indica che è stata avviata un'operazione di failover o switchover.

Eventi Autonomous Data Guard

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

Gli eventi di Autonomous Database includono i seguenti:

  • Avvia failover automatico
  • Termina failover automatico
  • Iniziare a disabilitare Autonomous Data Guard
  • Inizia ad abilitare Autonomous Data Guard
  • Avvia failover
  • Avvia switchover
  • Termina disabilitazione di Autonomous Data Guard
  • Termina abilitazione di Autonomous Data Guard
  • Fine del failover con risultato di failover di operazione riuscita o non riuscita.
  • Fine dello switchover con risultato di switchover riuscito o non riuscito.

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