Di seguito sono riportate limitazioni quando si abilita Autonomous Data Guard con un database di standby tra più aree (remoti):

• Per disabilitare Autonomous Data Guard con un database di standby tra più aree, arrestare il database di standby remoto. Per ulteriori informazioni, vedere Terminare un database di 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 in 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 OCPU se il database utilizza OCPU) e l'abilitazione della scala automatica della computazione nel database primario, mentre Autonomous Database esegue le stesse azioni nel database di standby remoto. Allo stesso modo, è possibile eseguire solo azioni come l'arresto o il riavvio del database nel database primario.

• È possibile eseguire determinate operazioni, ad esempio configurare gli endpoint privati in un database in standby remoto.

• È possibile modificare la configurazione di rete per le ACL in un database di standby remoto. Per ulteriori informazioni, vedere Gestione delle ACL di rete peer remoto.

• Un database in standby remoto non è disponibile per l'uso come database di sola lettura.

• Oracle Data Safe può essere abilitato in un database con un database in standby tra più aree abilitato, ma monitora solo il database all'interno della propria area e non può monitorare lo standby in caso di switchover o failover.

• Quando si consente l'autenticazione TLS per il database primario, Autonomous Data Guard abilita l'autenticazione TLS nel database di standby tra più aree. Pertanto, quando Autonomous Data Guard è abilitato con un standby remoto, è possibile consentire le connessioni TLS sul database primario solo se sia il database primario che il database di standby remoto sono configurati per supportare le connessioni TLS. In altre parole, il database di standby primario e remoto deve essere configurato con le ACL o con un endpoint privato. Per ulteriori informazioni, vedere Prerequisiti della configurazione di rete per consentire l'autenticazione TLS.

• Per informazioni sull'uso di chiavi gestite dal cliente con Autonomous Data Guard, vedere:

  • Autonomous Data Guard con chiavi gestite dal cliente
  • Note per le chiavi gestite dal cliente in OCI Vault con Autonomous Data Guard

• 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.

  See Autonomous Data Guard Cross-Region BYOL Licensing for more information.

• Quando si abilita Autonomous Data Guard con un database di standby tra più aree, i wallet per il database primario e il database di 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 i nomi host del database primario e di standby, è possibile crearlo manualmente.

  Per creare manualmente un wallet contenente le stringhe delle connessioni al database primario e remoto, procedere come segue.

  1. Nella console di Oracle Cloud Infrastructure del database primario fare clic su Connessione al database per scaricare il file wallet.zip del database primario.

  2. Dalla console di Oracle Cloud Infrastructure del database di standby remoto, fare clic su Connessione al database per scaricare il file wallet.zip del database di standby.

  3. Estrarre entrambi i file wallet e aprire i due file tnsnames.ora.

  4. Copiare il descrittore di connessione del database remoto nella stringa di connessione del database primario nel file tnsnames.ora del database primario utilizzando i ritardi dei nuovi tentativi preferiti.

  5. Comprimere la cartella del wallet del database primario aggiornata.

  Con questo tnsnames.ora aggiornato, le stringhe di connessione al database primario nell'aggiornamento wallet.zip conterranno sia i nomi host primario che in standby, per supportare il failover. Un'applicazione che utilizza il wallet aggiornato tenta di connettersi e riprovare a connettersi al primo nome host del database elencato e, se la connessione non riesce a causa della mancata disponibilità del database, 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 alle applicazioni di livello medio in esecuzione 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 del 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))))