Proteggi i database critici da errori e disastri utilizzando Autonomous Data Guard

Informazioni su Autonomous Data Guard

Autonomous Data Guard crea e gestisce due copie completamente separate del database: un database primario a cui le applicazioni si connettono e utilizzano e un database in standby che è una copia sincronizzata del database primario. Quindi, se il database primario diventa non disponibile per qualsiasi motivo, Autonomous Data Guard può convertire il database di standby in database primario e, come tale, inizierà a servire le tue applicazioni.

I database primari e in standby sono spesso chiamati database peer l'uno dell'altro. Puoi avere fino a due database di standby per Autonomous Container Database.

Nota

Le applicazioni devono essere configurate in modo da utilizzare la continuità di applicazione trasparente (TAC) per ottenere tutti i vantaggi delle funzioni di disponibilità del database fornite da Autonomous Data Guard.

Il diagramma riportato di seguito mostra in che modo ogni database di standby viene sincronizzato con il database primario.

Di seguito la descrizione dei dati autonomi guard.eps

Descrizione dell'immagine autonomous-data-guard.eps

Le modifiche apportate al database primario vengono registrate nel redo log del database primario. Autonomous Data Guard trasmette questi redo record sotto forma di flusso sulla rete al redo log del database in standby. Quindi, il database in standby applica questi record al database in standby. In questo modo, il database di standby viene mantenuto sincronizzato con il database primario.

La sincronizzazione è quasi istantanea, ma, come suggerisce il processo appena descritto, ci sono due operazioni che consumano tempo: il trasporto dei redo record al database in standby e l'applicazione dei redo record al database in standby. Il primo si chiama ritardo trasporto e l'altro si chiama ritardo applicazione. È possibile visualizzare i valori di ritardo correnti per un Autonomous Database dalla pagina Dettagli del database in Autonomous Data Guard in Risorse. nel menu laterale Risorse. È possibile visualizzare i valori di ritardo correnti in tutti gli Autonomous Database in un container database utilizzando una modalità simile nella pagina Dettagli del container database.

Nota

Con più database in standby, il trasporto di redo in cascata non è supportato.

Configurazione di Autonomous Data Guard

In Autonomous Database su un'infrastruttura Exadata dedicata, puoi configurare e gestire Autonomous Data Guard a livello di Autonomous Container Database (ACD). Puoi abilitare Autonomous Data Guard per gli ACD già di cui è stato eseguito il provisioning e aggiungere fino a due ACD in standby dalla relativa pagina Dettagli utilizzando la console di Oracle Cloud Infrastructure. Per istruzioni, vedere Abilita Autonomous Data Guard su un Autonomous Container Database e Aggiungi un secondo Autonomous Container Database di standby.

Prima di configurare Autonomous Data Guard, tenere presente quanto riportato di seguito.

Gli Autonomous Database distribuiti su Exadata Cloud@Customer devono avere la Porta 1522 aperta per consentire il traffico TCP tra il database primario e il database di standby in un'impostazione di Autonomous Data Guard.
Impossibile abilitare Autonomous Data Guard in un ACD con un'esecuzione di manutenzione attiva pianificata entro i tre giorni successivi. È possibile eseguire prima la manutenzione attiva, quindi abilitare Autonomous Data Guard o modificare la pianificazione dell'esecuzione della manutenzione in modo che non venga avviata fino all'aggiunta del secondo database di standby.
L'aggiunta di un secondo database di standby richiede un riavvio automatico non in sequenza per il primo database di standby. Questo riavvio non in sequenza non ha effetto sul database primario.

Configura Autonomous Data Guard con chiavi gestite dal cliente

In Autonomous Database sull'infrastruttura Exadata dedicata, puoi configurare e gestire Autonomous Data Guard con chiavi gestite dal cliente a livello di Autonomous Container Database (ACD). Puoi abilitare Autonomous Data Guard per gli ACD già di cui è stato eseguito il provisioning e aggiungere fino a due ACD in standby dalla pagina Dettagli utilizzando la console di Oracle Cloud Infrastructure. Per istruzioni, vedere Abilita Autonomous Data Guard su un Autonomous Container Database e Aggiungi un secondo Autonomous Container Database in standby.

Tenere presente quanto riportato di seguito prima di configurare Autonomous Data Guard con chiavi gestite dal cliente.

Se stai utilizzando il sistema Oracle Cloud Infrastructure Key Management System (OCI KMS) e desideri abilitare Autonomous Data Guard tra più aree, devi prima replicare il vault OCI nell'area in cui desideri aggiungere il database di standby. Per ulteriori dettagli, vedere Replica di vault e chiavi.

Nota
I vault virtuali creati prima dell'introduzione della funzione di replica del vault tra più aree non possono essere replicati in più aree. Creare un nuovo vault e nuove chiavi se si dispone di un vault che è necessario replicare in un'altra area e la replica non è supportata per tale vault. Tuttavia, tutti i vault privati supportano la replica tra più aree. Per i dettagli, vedere Replica del vault virtuale tra più aree.
Se si utilizza Oracle Key Vault (OKV) e si desidera abilitare Autonomous Data Guard tra più aree, assicurarsi di aver aggiunto gli indirizzi IP di connessione per il cluster OKV nel keystore.

Modelli Autonomous Data Guard

A partire da marzo 2025, gli Autonomous Container Database (ACD) possono abilitare Autonomous Data Guard dalla pagina Dettagli e creare fino a due ACD in standby. Con questa release, il modello precedente Autonomous Data Guard Associations e le API associate non saranno più valide e verranno sostituite con il nuovo modello e le API Autonomous Data Guard Groups. Tutti i nuovi ACD di cui è stato eseguito il provisioning dopo marzo 2025 dalla console Oracle Cloud Infrastructure (OCI) utilizzeranno automaticamente il nuovo modello di gruppi Autonomous Data Guard.

Per eseguire la transizione degli ACD esistenti, i clienti possono eseguire la migrazione al nuovo modello facendo clic su Aggiorna a gruppi Autonomous Data Guard dalla pagina Dettagli ACD nella console OCI o utilizzando l'API MigrateAutonomousContainerDatabaseDataguardAssociation.

Durante l'aggiornamento:

Si passerà alla nuova esperienza utente in cui le operazioni di Autonomous Data Guard vengono eseguite sulla risorsa Autonomous Container Database anziché sulla risorsa Autonomous Container Database Data Guard Association.
La risorsa Autonomous Data Guard Associations viene convertita in una risorsa gruppi Autonomous Data Guard con più supporto in standby. Non vi è alcun impatto sull'impostazione di Autonomous Database o Data Guard esistente.
È necessario abilitare Autonomous Data Guard dalla pagina Dettagli dell'ACD dopo averne eseguito il provisioning per utilizzare la funzione Autonomous Data Guard.
È necessario avviare le operazioni di switchover e failover dall'ACD in standby a cui si desidera passare i ruoli che utilizzano rispettivamente l'ACD primario o il failover.
Passerai alle nuove API Gruppi Autonomous Data Guard elencate come API di sostituzione in API per gestire la configurazione Autonomous Data Guard. L'API Autonomous Data Guard Associations esistente non è più valida e non sarà disponibile a partire da marzo 2026.
È necessario eseguire la sottoscrizione ai nuovi eventi gruppi Autonomous Data Guard elencati in Tipi di eventi Autonomous Data Guard. Gli eventi esistenti delle associazioni Autonomous Data Guard funzioneranno solo con la vecchia API delle associazioni Autonomous Data Guard e non saranno più validi insieme a queste API.

Transizioni e operazioni del ruolo

Dopo aver creato un Autonomous Container Database (ACD), è possibile modificare il ruolo dei database peer utilizzando uno switchover o un'operazione di failover. Se il failover automatico è abilitato, Autonomous Data Guard esegue automaticamente un'operazione di failover ogni volta che il database primario diventa non disponibile, per qualsiasi motivo.

Uno switchover è uno storno di ruolo tra il database primario e il relativo database di standby. Uno switchover garantisce l'assenza di perdita di dati. Durante uno switchover, il database primario passa al ruolo di standby e il database di standby passa al ruolo primario. Per eseguire un'operazione di switchover, vedere Switch Roles in an Autonomous Data Guard Configuration.

Un failover si verifica quando il database primario non è disponibile. Il failover determina la transizione del database di standby al ruolo primario. Se il failover automatico non è abilitato, è possibile eseguire un failover manuale come descritto nella sezione Fail Over to the Standby in an Autonomous Data Guard Configuration.

La disponibilità e lo stato del database dopo un'operazione di failover sono caratterizzati da due obiettivi di recupero:

Recovery Time Objective (RTO). L'RTO indica il periodo di tempo massimo necessario affinché il database diventi disponibile per le applicazioni dopo un failover ed è correlato in qualche misura al ritardo di applicazione al momento dell'errore. Per Autonomous Data Guard, l'RTO è di secondi fino a due minuti.
Recovery Point Objective (RPO). L'RPO è la durata massima della potenziale perdita di dati dal database primario non riuscito ed è correlato in qualche misura al ritardo di trasporto al momento dell'errore. Per Autonomous Data Guard, l'RPO è quasi zero.

Dopo un failover, il database primario non riuscito diventa un standby disabilitato e rimane non disponibile per qualsiasi connessione al database. È possibile riabilitarla e trasformarla in uno standby in buono stato eseguendo un'operazione di reintegrazione. Una volta ripristinato un database primario non riuscito come standby, è possibile eseguire uno switchover per riportarlo al ruolo primario originale. Per eseguire un'operazione di ripristino, vedere Reintegrare il database di standby disabilitato in una configurazione di Autonomous Data Guard.

Failover automatico o Fast-Start Failover

Con il failover automatico, ogni volta che l'ACD primario diventa non disponibile a causa di un errore dell'area, di un errore del dominio di disponibilità, di un errore dell'infrastruttura Exadata o del cluster VM Autonomous Exadata (AVMC) o dell'errore dell'ACD stesso, viene eseguito automaticamente il failover sull'ACD di standby. Questo è anche noto come Fast-Start Failover.

Non è possibile abilitare il failover automatico durante la configurazione di Autonomous Data Guard in un ACD. Il failover automatico può essere abilitato o disabilitato solo durante l'aggiornamento delle impostazioni di Autonomous Data Guard dalla pagina Dettagli ACD.

Nota

Impossibile abilitare il failover automatico per gli Autonomous Database distribuiti in Exadata Cloud@Customer con l'impostazione di Autonomous Data Guard tra più aree.

Non è possibile aggiungere un secondo ACD in standby con failover automatico abilitato per il primo ACD in standby. Pertanto, disabilitare il failover automatico utilizzando Aggiorna impostazioni Autonomous Data Guard prima di creare il secondo ACD di standby e riabilitarlo in un secondo momento, se necessario.

Entrambe le modalità di protezione delle prestazioni massime e della disponibilità massima supportano il failover automatico:

In modalità Maximum availability, il failover automatico garantisce zero perdite di dati.
Nella modalità Prestazioni massime, il failover automatico garantisce che il database di standby non sia in ritardo rispetto al database primario oltre il valore specificato per il limite di ritardo del failover Fast Start. Per impostazione predefinita, l'opzione Limite ritardo failover avvio rapido è impostata su 30 secondi ed è applicabile solo alla modalità Prestazioni massime. In questo caso, il failover automatico è possibile solo quando il ritardo di applicazione (potenziale perdita di dati) dello standby non supera il limite di ritardo configurato. È possibile modificare il limite di ritardo Fast Start failover impostandolo su qualsiasi valore compreso tra 5 e 3600.

Per ulteriori dettagli, vedere Aggiorna impostazioni di Autonomous Data Guard.

Oltre agli errori hardware, alle interruzioni del dominio di disponibilità e alle interruzioni regionali, esistono alcune altre condizioni di integrità del database che possono attivare un Fast-Start Failover, come elencato di seguito:

Condizione di stato del database	Descrizione
Control file danneggiato	Il file di controllo è stato permanentemente danneggiato a causa di un errore del disco.
Dizionario danneggiato	Danneggiamento del dizionario di un database critico. Attualmente, questo stato può essere rilevato solo quando il database è aperto.
Errori di scrittura del file di dati	Si verificano errori di scrittura in qualsiasi file di dati, inclusi file temporanei, file di dati di sistema e file di annullamento.

A seguito del failover automatico, il ruolo del database primario non riuscito diventa Disabled Standby e, dopo un breve periodo, il database in standby assume il ruolo di database primario. Dopo la conclusione del failover automatico, nella pagina dei dettagli del database in standby disabilitato viene visualizzato un messaggio che avvisa dell'avvenuta esecuzione del failover.

Dopo aver risolto i problemi precedenti di Autonomous Container Database primario, il servizio può eseguire uno switchover manuale per restituire entrambi i database ai ruoli iniziali. Dopo aver eseguito il provisioning del database di standby, è possibile eseguire vari task di gestione correlati al database di standby, tra cui:

Esegue lo switchover manuale di un database primario in un database in standby.
Esecuzione manuale del failover di un database primario in un database di standby.
Ricreazione dell'istanza di un database primario nel ruolo di standby dopo il failover.
Arresto di un database in standby.

In un'impostazione di Autonomous Data Guard con più database in standby e failover automatico:

I failover manuali richiedono di ripristinare manualmente il database primario originale, che diventa il nuovo database di standby.
Ogni volta che si verifica un failover automatico, Autonomous Database sull'infrastruttura Exadata dedicata tenta di ricreare un'istanza del database primario precedente come database in standby. Tuttavia, se il tentativo non riesce, è necessario ripristinarlo manualmente.

Database in standby snapshot

Un database di standby snapshot è un database di standby completamente aggiornabile creato convertendo un Autonomous Container Database (ACD) di standby in un ACD di standby snapshot. Per istruzioni dettagliate, vedere Converti standby fisico in standby snapshot.

Un database di standby snapshot riceve e archivia, ma non si applica, i dati di redo dal database primario. Tuttavia, aumenta l'obiettivo RTO (Recovery Time Objective) poiché le modifiche in tempo reale dal database primario non vengono applicate.

La funzione standby snapshot supporta vari casi d'uso, ma di seguito sono riportati i casi d'uso principali.

Connettere le istanze dell'applicazione primaria e in standby ai database primari e in standby in modalità di lettura-scrittura per eseguire le configurazioni iniziali.
Applicare prima una patch al database di standby snapshot ed eseguire il test con l'istanza dell'applicazione di standby per confermare la stabilità delle patch. Ciò richiede prima la conversione dello standby fisico in uno standby snapshot, in modo che la patch possa essere applicata nello standby snapshot.

Nota

Non è possibile convertire un Autonomous Container Database in standby fisico in uno standby snapshot con failover automatico abilitato.

Durante la conversione in standby snapshot, è possibile attivare nuovi servizi di database attivi solo in modalità snapshot oppure utilizzare lo stesso set di servizi utilizzato con il database primario. Tuttavia, l'attivazione dei servizi del database primario nel database di standby snapshot può causare l'inoltro di richieste di connessione di standby snapshot al database primario o viceversa se si utilizzano stringhe di connessione del database errate. Pertanto, è necessario fare attenzione a utilizzare la stringa di connessione appropriata durante la connessione al database di standby primario e snapshot.

Nota

Quando si creano nuovi servizi con standby snapshot, i wallet per tutti gli Autonomous Database nell'ACD di standby snapshot vengono aggiornati. Per accedere al database, ricaricare i wallet dagli Autonomous Database di standby e utilizzare le stringhe di connessione di standby snapshot.

È possibile convertire manualmente l'ACD di standby snapshot in un ACD di standby fisico da Oracle Cloud Infrastructure (OCI). Per istruzioni dettagliate, vedere Converti snapshot in standby in standby fisico. Se uno standby snapshot non viene convertito manualmente in uno standby fisico, verrà automaticamente convertito in uno standby fisico dopo 7 giorni dalla sua creazione. In ogni caso, la conversione dello standby snapshot in standby fisico eliminerà tutti gli aggiornamenti locali ai database di standby snapshot e applicherà i dati di redo ricevuti dai database primari.

Quando un ACD in standby è in modalità standby snapshot, non è possibile eseguire le operazioni riportate di seguito sull'ACD primario.

Creare o arrestare Autonomous Database
Eseguire lo scale up o scale down dei database autonomi
Ripristina database autonomi

Se la situazione lo richiede, puoi failover manualmente in uno standby snapshot dal database primario. In questo caso, il failover converte il database di standby snapshot in un database di standby fisico eliminando tutti gli aggiornamenti locali apportati allo standby snapshot e applicando i dati dal database primario. Per istruzioni dettagliate, vedere Fail Over to the Standby in an Autonomous Data Guard Configuration.

Non è consentito uno switchover tra il database primario e il relativo database di standby snapshot. È necessario convertire manualmente lo standby snapshot in uno standby fisico prima di tentare uno switchover.

Accesso ai database in standby dalle applicazioni client

In una configurazione Autonomous Data Guard, le applicazioni client in genere si connettono ed eseguono operazioni sul database primario.

Connessione al database in standby fisico

Oltre a questa normale connettività, Autonomous Data Guard offre la possibilità di connettere le applicazioni client che eseguono operazioni di sola lettura sul database di standby. Per usufruire di questa opzione, le applicazioni client si connettono al database utilizzando i nomi dei servizi di database che includono "_RO" (per "sola lettura"), come descritto nella sezione Nomi predefiniti dei servizi di database per database autonomi.

Connessione al database in standby snapshot

Autonomous Data Guard consente inoltre di connettere le applicazioni client che eseguono operazioni di lettura-scrittura al database di standby snapshot. Queste operazioni sono locali nel database di standby snapshot e non modificano il relativo database primario. Per connettersi a un database di standby snapshot, le applicazioni client possono utilizzare i nomi dei servizi di database che includono "_SS" (per "snapshot standby"), come descritto nella sezione Nomi predefiniti dei servizi di database per i database autonomi.

Nota

Quando il database di standby si trova in modalità standby snapshot, tutti i servizi di database che includono i servizi "_RO" nel nome sono inattivi e non possono essere utilizzati per le connessioni.

Tempi di ritardo monitoraggio

Mentre i database che utilizzano Autonomous Data Guard sono in esecuzione, puoi monitorare il ritardo del trasporto e applicare i tempi di ritardo dalla pagina Dettagli del database (o del container database) scegliendo Associazioni Autonomous Data Guard in Risorse nel menu laterale. Puoi anche utilizzare la console OCI o le API di osservabilità per monitorare il ritardo del trasporto e configurare allarmi e notifiche. Per ulteriori informazioni, consulta la sezione relativa all'osservabilità del database con le metriche di Autonomous Database.

Dovresti aspettarti di vedere fluttuazioni minori nel tempo come il carico di lavoro sui flussi e riflussi del database. Tuttavia, se si nota una tendenza al rialzo continua nel tempo di ritardo, è possibile eseguire le azioni riportate di seguito per risolvere la situazione.

Andamento al rialzo in ritardo applicazione. Una tendenza al rialzo continua nel ritardo di applicazione indica che il database di standby non dispone di capacità sufficiente per tenere il passo con i redo record provenienti dal database primario. Per risolvere questa situazione, eseguire lo scale up delle OCPU del database, come descritto in Aggiungi risorse CPU o di storage a un Autonomous Database dedicato.
Andamento al rialzo nel ritardo dei trasporti. Una tendenza al rialzo continua nel ritardo dei trasporti indica un problema di prestazioni della rete. Il personale operativo di Oracle Cloud monitora costantemente le prestazioni della rete, per cui dovresti vedere la situazione risolversi da solo senza intraprendere alcuna azione. Tuttavia, se lo si desidera, è possibile portare la situazione al personale operativo inviando una richiesta di servizio, come descritto in Crea una richiesta di servizio in My Oracle Support.

Opzioni di configurazione di Autonomous Data Guard

Quando si crea un Autonomous Container Database con Autonomous Data Guard abilitato, si specificano le risorse dell'infrastruttura Exadata e del cluster VM Autonomous Exadata in cui si desidera creare il database di standby e si specifica la modalità di protezione dei dati che si desidera utilizzare.

Sono disponibili le scelte riportate di seguito quando si specificano le risorse dell'infrastruttura Exadata e del cluster VM Autonomous Exadata da utilizzare per il standby.

In un'area diversa dall'infrastruttura Exadata e dal cluster VM Autonomous Exadata del database primario:
Questa scelta offre il più alto livello di protezione contro i disastri, inclusa una perdita catastrofica della connettività di rete esterna o dell'alimentazione a un'intera area.

Per utilizzare al meglio questa protezione tra più aree, è necessario configurare anche il livello applicazione per supportare la protezione tra più aree. Pertanto, Oracle consiglia di scegliere questa opzione se il livello applicazione è già configurato in questo modo o se si è disposti a riconfigurarlo per supportare la protezione tra più aree.

Se si sceglie di individuare il database di standby in un'altra area, Oracle consiglia di utilizzare la modalità di protezione Prestazioni massime.
In un dominio di disponibilità (AD) diverso dall'infrastruttura Exadata e dal cluster VM Autonomous Exadata del database primario:
Questa scelta offre un elevato livello di protezione contro i disastri, inclusa una perdita catastrofica della connettività di rete esterna o dell'alimentazione a un dominio di disponibilità all'interno di un'area geografica.

Questa scelta offre un buon equilibrio tra protezione dei dati e semplicità di configurazione nel livello dell'applicazione.

Se si sceglie di individuare il database di standby in un dominio di disponibilità diverso, Oracle consiglia di utilizzare la modalità di protezione Disponibilità massima.
Nello stesso dominio di disponibilità (AD) dell'infrastruttura Exadata e del cluster VM Autonomous Exadata del database primario:
Questa scelta fornisce un livello minimo di protezione contro i disastri e Oracle consiglia di non sceglierla.

Se le risorse dell'infrastruttura Exadata e del cluster VM Autonomous Exadata del database primario si trovano in un'area con un solo dominio di disponibilità, Oracle consiglia di utilizzare l'opzione "in un'area diversa".

Se si sceglie di individuare il database di standby nello stesso dominio di disponibilità, Oracle consiglia di utilizzare la modalità di protezione Massima disponibilità.
In una tenancy diversa rispetto all'infrastruttura Exadata e al cluster VM Autonomous Exadata del database primario:
SI APPLICA A: solo Oracle Public Cloud

Questa scelta consente di aggiungere un database di standby da una tenancy diversa, consentendo il failover o lo switchover del database in tale database di standby cross-tenancy. È inoltre possibile creare uno standby snapshot nella tenancy remota. Avere un database di standby cross-tenancy può essere utile con la migrazione del database tra le tenancy.

Database di standby cross-tenancy:
- Può essere abilitato con il modello di computazione ECPU o OCPU. Il database di standby deve utilizzare lo stesso modello di computazione del database primario.
- Non supporta il failover automatico. È possibile utilizzare solo un failover manuale.
- Non può essere aggiunto utilizzando la console di Oracle Cloud Infrastructure. È possibile aggiungere un database di standby tra più tenancy solo utilizzando l'interfaccia CLI o l'API REST.

Informazioni sulle modalità di protezione

Autonomous Data Guard fornisce le seguenti modalità di protezione dei dati:

Disponibilità massima. Questa modalità di protezione fornisce il massimo livello di protezione dei dati possibile senza compromettere la disponibilità del database primario.

Il database primario non esegue il commit delle transazioni fino a quando non riceve la conferma che i dati sono stati ricevuti nel database in standby (non che è stato scritto su disco). Se il database primario non riceve questa conferma entro 30 secondi, funziona come se fosse in modalità con le massime prestazioni per mantenere la disponibilità del database primario fino a quando non riceve nuovamente conferme in modo tempestivo.

Questa modalità di protezione garantisce l'assenza di perdita di dati, tranne nel caso di determinati errori doppi, ad esempio l'errore di un database primario dopo l'errore del database in standby.
Prestazioni massime. Questa è la modalità di protezione predefinita. Fornisce il massimo livello di protezione dei dati possibile senza alcun effetto sulle prestazioni del database primario.

Il database primario esegue il commit delle transazioni non appena tutti i dati di redo generati da tali transazioni sono stati scritti nel redo log in linea. Inoltre, invia i dati di redo al database in standby, ma questa operazione viene eseguita in modo asincrono rispetto all'impegno delle transazioni, pertanto le prestazioni del database primario non vengono influenzate dai ritardi nella scrittura dei dati di redo nel database in standby.

Questa modalità di protezione offre una protezione dei dati leggermente inferiore rispetto alla modalità di massima disponibilità e ha un impatto minimo sulle prestazioni del database primario.

Puoi modificare la modalità di protezione in un'impostazione di Autonomous Data Guard dalla console di Oracle Cloud Infrastructure (OCI). Per istruzioni dettagliate, consulta la sezione relativa all'aggiornamento delle impostazioni di Autonomous Data Guard.

Per ulteriori informazioni sulle modalità di protezione in Oracle Data Guard (che è alla base della funzione Autonomous Data Guard), vedere Oracle Data Guard Protection Modes in Oracle Data Guard Concepts and Administration.

Best practice durante la configurazione di Autonomous Data Guard

Sebbene Autonomous Database ti consenta di creare fino a due ACD di standby con Autonomous Data Guard, puoi scegliere di utilizzare uno o più ACD di standby, a seconda delle tue esigenze. Tuttavia, per utilizzare l'opzione di disaster recovery più resiliente offerta da un Autonomous Database, è possibile aggiungere un ACD in standby locale e un ACD in standby remoto o tra più aree con massima disponibilità come modalità di protezione dei dati.

Scopriamo i vantaggi di questo design:

Standby locale:
- Il failover automatico su uno standby locale nella stessa area offre un isolamento dalle calamità locali significativo e una semplicità di failover delle applicazioni.
- Il valore aziendale di un database di standby locale si riscontra in un failover senza perdita di dati e in tempi di inattività delle applicazioni ridotti a secondi.
- Le applicazioni eseguono automaticamente e in modo trasparente il failover allo standby locale, mantenendo la stessa latenza tra gli application server e il database. Ciò è particolarmente importante per le applicazioni OLTP e dei package perché una latenza più elevata può influire in modo significativo sul throughput e sui tempi di risposta complessivi delle applicazioni.
Standby remoto:
- Se una calamità regionale rende inaccessibili i sistemi in standby primario e locale, l'applicazione e il database possono eseguire il failover sul database in standby remoto.
- Anche se i tempi di inattività del database sono ancora molto bassi quando si verifica una calamità regionale, il tempo di inattività dell'applicazione può essere maggiore a causa dell'orchestrazione aggiuntiva necessaria per le operazioni di failover DNS, applicazione e database nell'area secondaria.
Disponibilità massima:
- Se il failover automatico o Fast-Start Failover (FSFO) è abilitato, ogni volta che l'ACD primario non è più disponibile, Autonomous Data Guard esegue il failover sullo standby locale senza alcuna perdita di dati e senza alcuna modifica alla latenza del database nell'applicazione.
- Se il failover automatico o Fast Start Failover (FSFO) è abilitato, ogni volta che l'intera region primaria diventa inaccessibile, il sistema esegue il failover sul database in standby remoto con una potenziale perdita di dati.

In che modo Autonomous Data Guard influisce sulle operazioni di gestione standard

In alcuni casi, le operazioni di gestione standard eseguite su Autonomous Container Database funzionano in modo diverso sui container database primario e in standby in una configurazione Autonomous Data Guard rispetto ai container database standard. L'elenco seguente descrive queste differenze.

Modificare la pianificazione della manutenzione
La pianificazione della manutenzione di un container database primario e del relativo standby sono collegate: la manutenzione sul database di standby viene eseguita un certo numero di giorni prima della manutenzione sul database primario. L'impostazione predefinita è 7 giorni. È possibile scegliere tra 1 e 7 giorni quando si crea il container database primario o in un secondo momento modificandone i dettagli di manutenzione.
Modificare il tipo di manutenzione
Il tipo di manutenzione di un container database primario e il relativo standby devono essere uguali. È possibile scegliere il tipo di manutenzione sia per il database primario che per il database in standby quando si crea il container database primario o in un secondo momento modificandone i dettagli di manutenzione.
Disabilita backup automatici
Non è possibile disabilitare i backup automatici durante il provisioning di un Autonomous Container Database (ACD) con Autonomous Data Guard.
Gestione della manutenzione pianificata
Puoi gestire la manutenzione pianificata di un container database primario e del relativo database in standby separatamente. Tuttavia, poiché la manutenzione dei due componenti è collegata, è necessario eseguire la manutenzione pianificata sul database di standby prima del database primario se si sceglie di sostituire l'ora di manutenzione pianificata.
Sposta in un altro compartimento
Puoi spostare i container database primari e in standby in compartimenti diversi separatamente e in modo indipendente, proprio come se fossero container database standard. Tuttavia, come con i container database standard, dovresti prestare estrema attenzione quando sposti un container database per assicurarti che il container database rimanga accessibile ai gruppi appropriati di utenti cloud.
Riavvia
Puoi riavviare i container database primari e in standby separatamente e in modo indipendente, proprio come se fossero container database standard.
Ruota la chiave di cifratura
È possibile ruotare le chiavi di cifratura dall'ACD primario o dal database primario.
Termina
Puoi arrestare separatamente i container database primari e in standby. Tuttavia, le conseguenze dell'interruzione di un container database primario e dell'interruzione di un container database in standby sono diverse:
- L'arresto di un container database primario termina sia il container database primario che quello in standby. Non è possibile arrestare un container database primario che contiene database autonomi.
- L'arresto di un container database in standby termina il container database in standby e lo rimuove dalla configurazione di Autonomous Data Guard. Se è rimasto solo un database primario, la configurazione Autonomous Data Guard viene rimossa, trasformando il database primario in un container database standalone.

Guide dettagliate

Per istruzioni dettagliate sulla gestione della configurazione di Autonomous Data Guard in un Autonomous Container Database, vedere:

Inoltre, puoi utilizzare l'API per visualizzare e gestire la configurazione di Autonomous Data Guard. Per ulteriori dettagli, vedere API per la gestione della configurazione di Autonomous Data Guard.