Gestire i database primari e in standby in una configurazione Autonomous Data Guard
Scopri come gestire i database primari e in standby in una configurazione Data Guard autonoma.
Quando crei un Autonomous Database in un Autonomous Container Database con Autonomous Data Guard abilitato, vengono create due copie completamente separate del database: una in un container database primario e una (copia sincronizzata) in un container database in standby. Quindi, in caso di indisponibilità del container database primario, Autonomous Data Guard converte automaticamente il container database di standby in container database primario e, come tale, inizia a servire le connessioni delle applicazioni all'Autonomous Database.
Nota
Poiché vengono creati due database autonomi quando si utilizza Autonomous Data Guard, viene utilizzato il doppio del numero di risorse CPU e storage, metà per il database primario e metà per il database in standby.Questi due database, spesso denominati peer, sono identificati dalle etichette Primary e Standby nella lista dei database autonomi e nella pagina Dettagli per il database.
Per informazioni sul modo in cui gli amministratori della flotta creano e gestiscono gli Autonomous Container Database con Autonomous Data Guard abilitato, vedere Gestire Autonomous Data Guard.
Operazioni di gestione su database primari e in standby
Poiché i due database sono collegati e sincronizzati, alcune delle operazioni di gestione eseguite sui database autonomi funzionano in modo diverso sui database primari e in standby in una configurazione Autonomous Data Guard rispetto ai database standard. L'elenco seguente descrive queste differenze.
- Scale up, scale down e scalabilità automatica
I due database peer devono avere lo stesso conteggio CPU, la stessa dimensione di storage e la stessa impostazione di ridimensionamento automatico. Pertanto, è possibile eseguire lo scale-up, lo scale-down e modificare le impostazioni di scala automatica solo dalla pagina Dettagli del database primario. Le modifiche apportate influiscono sia sul database primario che sul database di standby.
- Arresta, avvia e riavvia
Lo stato del ciclo di vita dei due database peer viene mantenuto sincronizzato. Pertanto, è possibile solo arrestare, avviare e riavviare il database dalla pagina Dettagli del database primario. L'operazione eseguita influisce sia sul database primario che su quello in standby.
- Backup manuale
È possibile eseguire manualmente il backup dei database primari e in standby separatamente e in modo indipendente, proprio come se fossero database standard.
- Ripristina
È possibile ripristinare e recuperare il database solo dalla pagina Dettagli del database primario.
- Clone
È possibile duplicare il database solo dalla pagina Dettagli del database primario.
- Ruota la chiave di cifratura
Puoi ruotare le chiavi di cifratura dei database primari e in standby separatamente e in modo indipendente, proprio come se fossero database standard.
- Sposta in un altro compartimento
Puoi spostare i database primari e in standby in compartimenti diversi separatamente e in modo indipendente, proprio come se fossero database standard.
- Termina
È possibile arrestare il database solo dalla pagina Dettagli del database primario.
Accesso ai database in standby dalle applicazioni client
Quando si utilizza Autonomous Data Guard, le applicazioni client in genere si connettono ed eseguono operazioni sul database primario.
Oltre a questa normale connettività, Autonomous Data Guard offre la possibilità di connettere le applicazioni client che eseguono solo operazioni di sola lettura al 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.
Tempi di ritardo monitoraggio
Man mano che i database che utilizzano Autonomous Data Guard sono in esecuzione, puoi monitorare i ritardi di trasporto e applicare i tempi di ritardo dalla pagina Dettagli del database primario o in standby facendo clic su Autonomous Data Guard.
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 CPU del database, come descritto nella sezione 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 desideri, puoi portare la situazione al personale operativo inviando una richiesta di servizio.