Note di Autonomous Data Guard
Fornisce note per l'uso di Autonomous Database con un database di standby Autonomous Data Guard.
-
Non è possibile connettersi a un database in standby finché non viene reso primario da un failover o da uno switchover. Pertanto, un database in standby non può essere aperto per l'accesso in sola lettura e non può essere utilizzato per scaricare le query da un database primario.
-
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.
-
Autonomous Data Guard non è disponibile con Autonomous Database Sempre gratis.
-
Autonomous Database non fornisce l'accesso a un database di standby locale:
-
È possibile eseguire tutte le operazioni, ad esempio lo scale up del conteggio ECPU (conteggio OCIPU se il database utilizza le OCPU) abilitando la scala automatica di computazione nel database primario e Autonomous Database esegue 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 non è disponibile per l'uso come database di sola lettura.
-
-
Il numero di ECPU (OCPU se il database utilizza le OCPU) grafico allocato e il grafico di utilizzo della CPU nella scheda Dashboard del database in Azioni database visualizza le ECPU (OCPU se il database utilizza le OCPU) allocate e l'utilizzo delle CPU per il database primario. Questi grafici non includono informazioni su un database in standby locale o su un database in standby remoto.
Le metriche di utilizzo della CPU nella pagina delle metriche della console di Oracle Cloud Infrastructure visualizzano l'utilizzo della CPU per il database primario. Altre metriche in questa pagina si applicano anche al database primario. Queste metriche non includono informazioni sul database di standby locale o sul database di standby remoto.
-
Dopo uno switchover o un failover a un database peer, il database peer diventa primario e i grafici nel Dashboard del database in Database Actions e nella pagina Metriche della console di Oracle Cloud Infrastructure visualizzano informazioni sul database primario. I grafici e la metrica non contengono informazioni sul database che era primario prima dell'operazione di switchover o failover.
-
Il failover automatico in standby locale viene disabilitato durante un'operazione di ripristino in corso.
-
Failover automatico in standby locale disabilitato durante l'aggiornamento di un database.
-
Quando il campo Stato del ciclo di vita per il database primario mostra Arrestato, vengono arrestati anche i database di standby. È comunque possibile eseguire uno switchover quando il database primario è arrestato.
Note di Autonomous Data Guard tra più aree
Di seguito sono riportate limitazioni e limitazioni quando si abilita Autonomous Data Guard con un database di standby tra più aree (remote):
-
Per disabilitare Autonomous Data Guard con un database di standby tra più aree, interrompi il database di standby remoto. Per ulteriori informazioni, vedere Terminare un database in standby tra più aree.
-
Quando un endpoint privato è abilitato o disabilitato nel database primario, qualsiasi lista di controllo dell'accesso (ACL) configurata in precedenza nel database di standby viene abilitata e i valori vengono cancellati. È necessario reimpostare e verificare l'ACL nel database di standby dopo aver disabilitato un endpoint privato nel database primario.
-
È possibile eseguire la maggior parte delle 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 Database esegue le stesse azioni nel database di standby remoto. Allo stesso modo, si eseguono solo azioni quali l'arresto o il riavvio del database nel database primario.
-
È possibile eseguire determinate operazioni, ad esempio la configurazione di endpoint privati in un database di standby remoto.
-
È possibile modificare la configurazione di rete per le ACL in un database di standby remoto. Per ulteriori informazioni, vedere Gestire le ACL di rete peer remoto.
-
Un database di standby remoto non è disponibile per l'uso come database di sola lettura.
-
Oracle Data Safe può essere abilitato in un database per cui è abilitato un database in standby tra più aree, ma monitora solo il database all'interno della relativa area e non può monitorare lo standby in caso di switchover o failover.
-
Quando consenti l'autenticazione TLS per il database primario, Autonomous Data Guard abilita l'autenticazione TLS in standby tra più aree. Pertanto, quando Autonomous Data Guard è abilitato con un database di standby remoto, è possibile consentire connessioni TLS sul database primario solo se sia il database primario che il database di standby remoto sono configurati per supportare le connessioni TLS. Ciò significa che il database primario e il database di standby remoto devono essere configurati con le ACL o con un endpoint privato. Per ulteriori informazioni, vedere Network Configuration Prerequisites to Allow TLS Authentication.
-
Vedere per le seguenti informazioni sull'uso di chiavi gestite dal cliente con Autonomous Data Guard
-
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 cross-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.
See Autonomous Data Guard Cross-Region BYOL Licensing for more information.
-
Quando abiliti Autonomous Data Guard con un database di standby tra più aree, i wallet per il database primario e in standby specificano nomi host di database diversi e utilizzano stringhe di connessione diverse. Oracle consiglia alle applicazioni di utilizzare la stringa di connessione o il wallet scaricato dalla stessa area del database primario.
Se è necessario utilizzare una singola stringa di connessione o un wallet contenente sia i nomi host del database primario che quelli del database in standby, è possibile creare questa stringa manualmente.
Per creare manualmente un wallet che contiene sia le stringhe di connessione al database primario che quelle remote:
-
Dalla console di Oracle Cloud Infrastructure del database primario, fare clic su Connessione al database per scaricare il file
wallet.zip
del database primario. -
Dalla console Oracle Cloud Infrastructure del database in standby remoto, fare clic su Connessione al database per scaricare l'indirizzo
wallet.zip
del database in standby. -
Estrarre entrambi i file wallet e aprire i due file
tnsnames.ora
. -
Copiare il descrittore di connessione del database remoto nella stringa di connessione del database primario nel file
tnsnames.ora
primario utilizzando i ritardi dei nuovi tentativi preferiti. -
Comprimere la cartella del wallet del database primario aggiornata.
Con l'aggiornamento di
tnsnames.ora
, le stringhe di connessione del database primario nel filewallet.zip
aggiornato conterranno i nomi host primario e in standby per supportare il failover. Un'applicazione che utilizza il wallet aggiornato tenta di connettersi al primo nome host del database elencato e, se tale connessione non riesce a causa del database non disponibile, l'applicazione tenta automaticamente di connettersi al secondo nome host del database.Ad esempio, se Autonomous Data Guard è impostato con il database primario in Ashburn (IAD) e un database in standby tra più aree in Phoenix (PHX), Oracle consiglia di eseguire le applicazioni di livello intermedio in IAD utilizza la stringa di connessione o il wallet da quello del database primario in IAD e le applicazioni corrispondenti in esecuzione in PHX utilizzano la stringa di connessione o il wallet da quello del database di standby in PHX. Per un failover o uno switchover regionale, Oracle consiglia di eseguire il failover sia del database che dell'applicazione o di livello intermedio, per ottenere prestazioni ottimali e ridurre al minimo qualsiasi latenza tra più aree.
Ad esempio:
a6gxf2example9ep_high = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes)))) a6gxf2example9ep_low = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes)))) a6gxf2example9ep_medium = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))
-
Argomento padre: Note di Autonomous Data Guard