Gestisci configurazione Autonomous Data Guard

Abilitare Autonomous Data Guard su un Autonomous Container Database

Puoi abilitare Autonomous Data Guard dalla pagina Dettagli di un Autonomous Container Database.

Nota

Non è possibile abilitare Autonomous Data Guard su un ACD con un'esecuzione di manutenzione attiva pianificata entro i tre giorni successivi.

Autorizzazioni IAM necessarie

inspect cloud-autonomous-vmclusters

use autonomous-container-databases

Procedura

Nota

Quando è in corso un'operazione di aggiunta ACD in standby, qualsiasi manutenzione pianificata in tale ACD non inizierà fino al completamento dell'operazione di aggiunta in standby.

Andare alla pagina Dettagli dell'Autonomous Container Database per il quale si desidera abilitare Autonomous Data Guard.
Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Abilita nella sezione Autonomous Data Guard nelle informazioni su Autonomous Container Database.
In alternativa, puoi anche fare clic su Aggiungi standby nei gruppi Autonomous Data Guard o sulle associazioni Autonomous Data Guard.

Compilare la finestra di dialogo Aggiungi standby con le informazioni riportate di seguito.

Impostazione	Descrizione	Note
Autonomous Container Database peer	Selezionare il compartimento di Autonomous Container Database di standby.
Nome Autonomous Container Database peer	Immettere un nome per l'ACD in standby.
Area peer	Selezionare un'area per l'ACD in standby.	Gli ACD primari e secondari possono anche essere distribuiti in diverse aree (tra più aree).
Infrastruttura Exadata peer	Selezionare la risorsa dell'infrastruttura Exadata di base per l'ACD di standby.
Cluster VM Autonomous Exadata peer (AVMC)	Selezionare l'AVMC padre per l'ACD in standby.
Modalità di protezione	Selezionare Prestazioni massime o Disponibilità massima dall'elenco a discesa.	Per impostazione predefinita, è selezionata l'opzione Prestazioni massime. Per informazioni su Autonomous Data Guard e indicazioni per scegliere dove posizionare il container database autonomo in standby e quale modalità di protezione utilizzare, vedere Informazioni su Autonomous Data Guard e Opzioni di configurazione Autonomous Data Guard.
Configurazione backup database peer	Selezionare un tipo di destinazione di backup dall'elenco a discesa.	SI APPLICA A: solo Exadata Cloud@Customer È necessaria una destinazione di backup nelle distribuzioni di Exadata Cloud@Customer.
Preferenza per la manutenzione del database peer	Selezionare il numero di giorni durante i quali la manutenzione ACD in standby verrà pianificata prima della manutenzione ACD primaria perché le patch ACD in standby vengono sempre applicate prima dell'ACD primario.	Questa opzione è disponibile solo quando l'ACD principale ha definito una pianificazione di manutenzione personalizzata.

Confermare l'aggiunta del database in standby.

Nota
Una volta abilitato, Autonomous Data Guard può essere disabilitato solo terminando l'ACD di standby.

Visualizza lo stato di una configurazione di Autonomous Data Guard

È possibile visualizzare lo stato di una configurazione Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database primario o in standby nella configurazione.

Criteri IAM necessari

inspect autonomous-container-databases

Procedura

Andare alla pagina Dettagli dell'Autonomous Container Database primario o in standby nella configurazione Autonomous Data Guard.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.

È possibile visualizzare i dettagli di Autonomous Data Guard, ad esempio stato, ruolo peer, stato peer, modalità di protezione e impostazione di failover automatico in Autonomous Data Guard nelle informazioni su Autonomous Container Database.
Puoi anche visualizzare i dettagli di Autonomous Data Guard facendo clic su gruppi Autonomous Data Guard o su associazioni Autonomous Data Guard.
La tabella Autonomous Data Guard visualizza informazioni sul container database peer, il ritardo di applicazione e il ritardo di trasporto correnti, lo stato e le date di modifica e creazione dell'ultimo ruolo.

Aggiungi un secondo Autonomous Container Database di standby

In un'impostazione di Autonomous Data Guard, puoi aggiungere un secondo Autonomous Container Database (ACD) di standby all'ACD primario. Il secondo ACD in standby deve trovarsi nella stessa tenancy dell'ACD primario.

Prerequisiti

Per poter aggiungere un secondo ACD in standby:

Il provisioning dell'ACD primario deve essere stato eseguito a partire da marzo 2025 o è stata eseguita la migrazione al modello Gruppi Autonomous Data Guard descritto in Configura e gestisci Autonomous Data Guard.
Per il primo ACD in standby non deve essere abilitato il failover automatico. È necessario disabilitare il failover automatico nel primo standby prima di aggiungere il secondo standby e riabilitarlo in un secondo momento.

Autorizzazioni IAM richieste

use autonomous-container-databases

Procedura

Nota

Quando è in corso un'operazione di aggiunta ACD in standby, qualsiasi manutenzione pianificata in tale ACD non inizierà fino al completamento dell'operazione di aggiunta in standby.
L'aggiunta di un 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.

Andare alla pagina Dettagli dell'Autonomous Container Database per il quale si desidera aggiungere un secondo database di standby.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Aggiungi standby nei gruppi di Autonomous Data Guard.

Compilare Aggiungi standby con le informazioni riportate di seguito.

Impostazione	Descrizione
Autonomous Container Database peer	Selezionare il compartimento Autonomous Container Database di standby.
Nome Autonomous Container Database peer	Immettere un nome per l'ACD in standby.
Area peer	Selezionare un'area per l'ACD in standby.
Infrastruttura Exadata peer	Selezionare la risorsa dell'infrastruttura Exadata di base per l'ACD di standby.
Cluster VM Autonomous Exadata peer (AVMC)	Selezionare l'AVMC padre per l'ACD in standby.
Configurazione backup database peer	SI APPLICA A: solo Exadata Cloud@Customer Selezionare il tipo di destinazione di backup per il secondo database di standby dall'elenco a discesa.

Nota

Non è possibile impostare in modo esplicito le preferenze di manutenzione per il secondo ACD in standby poiché eredita queste preferenze dal primo ACD in standby dell'ACD primario.

Fare clic su Aggiungi standby.

Cambia ruoli in una configurazione Autonomous Data Guard

I ruoli degli Autonomous Container Database primario e di standby in una configurazione Autonomous Data Guard vengono commutati dalla pagina Dettagli dell'Autonomous Container Database primario o di standby.

Criteri IAM necessari

use autonomous-container-databases

Procedura

A seconda del modello Autonomous Data Guard di ACD, seguire le istruzioni di una delle seguenti schede. Per ulteriori informazioni sui modelli Autonomous Data Guard, vedere Configura e gestisci Autonomous Data Guard.

Gruppi Autonomous Data Guard
Associazioni di Autonomous Data Guard

Andare alla pagina Dettagli dell'ACD in standby che si desidera cambiare ruolo con l'ACD primario nella configurazione Autonomous Data Guard.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.

Nota
Non è possibile cambiare i ruoli degli ACD primari e di standby in una configurazione Autonomous Data Guard in cui lo standby si trova nel ruolo snapshot standby.
In Azioni fare clic su Switchover.
Immettere il nome ACD nella finestra di dialogo di conferma e fare clic su Switchover.

Oracle Autonomous Database on Dedicated Exadata Infrastructure imposta lo stato del database in standby e dei relativi container database primari su Modifica dei ruoli in corso e avvia l'operazione di switchover, che induce il container database primario ad assumere il ruolo in standby e il container database in standby ad assumere il ruolo primario. Al termine, lo stato di entrambi i container database torna a Attivo.

Andare alla pagina Dettagli dell'Autonomous Container Database primario o in standby nella configurazione Autonomous Data Guard.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.

Nota
Non è possibile scambiare i ruoli degli Autonomous Container Database primario e di standby in una configurazione Autonomous Data Guard in cui lo standby si trova nel ruolo snapshot standby.
Fare clic su Associazioni Autonomous Data Guard per elencare il database peer in una colonna tabulare. Fare clic sui puntini di sospensione (tre punti verticali) nella riga del database in cui si desidera cambiare ruolo e fare clic su Switchover.
Immettere il nome ACD nella finestra di dialogo di conferma e fare clic su Switchover.

Oracle Autonomous Database on Dedicated Exadata Infrastructure imposta lo stato di entrambi i container database su Modifica dei ruoli in corso e avvia l'operazione di switchover, che induce il container database primario ad assumere il ruolo di standby e il container database di standby ad assumere il ruolo primario. Al termine, lo stato di entrambi i container database torna a Attivo.

Esecuzione del failover al database in standby in una configurazione Autonomous Data Guard

È possibile eseguire il failover sugli Autonomous Container Database di standby in una configurazione Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database di standby.

Criteri IAM necessari

use autonomous-container-databases

Procedura

A seconda del modello Autonomous Data Guard di ACD, seguire le istruzioni di una delle seguenti schede. Per ulteriori informazioni sui modelli Autonomous Data Guard, vedere Configura e gestisci Autonomous Data Guard.

Gruppi Autonomous Data Guard
Associazioni di Autonomous Data Guard

Andare alla pagina Dettagli dell'ACD in standby in cui si desidera eseguire il failover nella configurazione di Autonomous Data Guard.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
In Azioni, fare clic su Failover.
Nel caso di un Autonomous Container Database di standby snapshot, viene visualizzato un messaggio che avvisa che lo standby snapshot verrà convertito in standby fisico dopo aver eliminato tutti gli aggiornamenti locali e aver applicato i dati dal database primario. Fare clic su Failover per continuare.
Immettere il nome ACD nella finestra di dialogo di conferma e fare clic su Fail over.

Oracle Autonomous Database on Dedicated Exadata Infrastructure imposta lo stato del container database in standby su Modifica dei ruoli in corso e avvia l'operazione di failover. Al termine, il ruolo del container database in standby diventa Principale e il ruolo del container database primario diventa Standby disabilitato con lo stato Non disponibile.

Andare alla pagina Dettagli dell'Autonomous Container Database di standby nella configurazione Autonomous Data Guard.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Associazioni Autonomous Data Guard per elencare il database peer in una colonna tabulare. Fare clic sui puntini di sospensione (tre punti verticali) nella riga del database in cui si desidera cambiare ruolo e fare clic su Failover.
Nel caso di un Autonomous Container Database di standby snapshot, viene visualizzato un messaggio che avvisa che lo standby snapshot verrà convertito in standby fisico dopo aver eliminato tutti gli aggiornamenti locali e aver applicato i dati dal database primario. Fare clic su Failover per continuare.

Oracle Autonomous Database on Dedicated Exadata Infrastructure imposta lo stato del container database in standby su Modifica dei ruoli in corso e avvia l'operazione di failover. Al termine, il ruolo del container database in standby diventa Principale e il ruolo del container database primario diventa Standby disabilitato con lo stato Non disponibile.

Reintegra il database di standby disabilitato in una configurazione Autonomous Data Guard

Dopo che si è verificato un failover e l'Autonomous Container Database primario non riuscito assume un ruolo disabilitato e in standby, è possibile ricreare un'istanza del database non riuscito in un ruolo abilitato e in standby dalla relativa pagina Dettagli.

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.

Criteri IAM necessari

use autonomous-container-databases

Procedura

A seconda del modello Autonomous Data Guard di ACD, seguire le istruzioni di una delle seguenti schede. Per ulteriori informazioni sui modelli Autonomous Data Guard, vedere Configura e gestisci Autonomous Data Guard.

Gruppi Autonomous Data Guard
Associazioni di Autonomous Data Guard

Andare alla pagina Dettagli dell'ACD in standby disabilitato che si desidera ripristinare.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.

Suggerimento
Il database primario di cui si è verificato l'errore è etichettato come "In standby disabilitato" nella lista di Autonomous Container Database per un compartimento.
In Azioni, fare clic su Ripristina.
Fornire una conferma per procedere con il ripristino dell'ACD in standby disabilitato.

Gli stati dei database peer diventano Modifica dei ruoli in corso fino al completamento dell'azione di ripristino. Al termine, il ruolo del container database in standby disabilitato diventa In standby e il relativo stato cambia in Disponibile.

Andare alla pagina Dettagli dell'Autonomous Container Database di standby disabilitato che si desidera ripristinare.

Suggerimento
Il database primario di cui si è verificato l'errore è etichettato come "In standby disabilitato" nella lista di Autonomous Container Database per un compartimento.

Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Associazioni Autonomous Data Guard. La lista dei database peer è elencata in una colonna tabulare. Fare clic sui puntini di sospensione (tre punti verticali) nella riga del database in cui si desidera cambiare ruolo e fare clic su Ripristina.
Gli stati dei database peer diventano Modifica dei ruoli in corso fino al completamento dell'azione di ripristino. Al termine, il ruolo del container database in standby disabilitato diventa In standby e il relativo stato cambia in Disponibile.

Aggiorna impostazioni di Autonomous Data Guard

È possibile aggiornare le impostazioni di un Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database primario nella configurazione.

Criteri IAM necessari

use autonomous-container-databases

Procedura

Vai alla pagina Dettagli dell'Autonomous Container Database primario nella configurazione Autonomous Data Guard.
Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Aggiorna Autonomous Data Guard in Azioni.
Nella finestra di dialogo Aggiorna Autonomous Data Guard vengono visualizzate le impostazioni correnti per Modalità di protezione e Failover automatico.
Questa finestra di dialogo consente di effettuare i seguenti aggiornamenti:
1. Modalità di protezione: selezionare Prestazioni massime o Disponibilità massima dall'elenco a discesa.
2. Failover automatico: se il failover automatico non è già abilitato, è possibile abilitarlo selezionando Abilita failover automatico. Analogamente, è possibile deselezionare Abilita failover automatico per disabilitare il failover automatico per questa impostazione di Autonomous Data Guard. Se uno dei database di standby si trova nella stessa area del database primario e il secondo si trova in un'altra area, la priorità del database di standby locale verrà assegnata al database di standby remoto come destinazione di failover automatico. Quando si abilita il failover automatico, per la destinazione di failover automatico verrà preso in considerazione uno qualsiasi dei database di standby.
  
  Nota
  Non è possibile abilitare il failover automatico per i database con impostazione di Autonomous Data Guard tra più aree nelle distribuzioni Exadata Cloud@Customer.
3. Limite di ritardo del failover rapido: se il failover automatico è abilitato e la modalità di protezione è Prestazioni massime, il valore del limite di ritardo del failover rapido viene visualizzato in secondi. Per impostazione predefinita, questo valore è impostato su 30 secondi, ma è possibile modificarlo in qualsiasi valore compreso tra 5 e 3600 secondi.
Salvare le modifiche.

Sulla console di Oracle Cloud Infrastructure, lo stato di Autonomous Container Database mostra AGGIORNAMENTO fino all'applicazione delle impostazioni aggiornate di Autonomous Data Guard.

Conversione in standby fisico in standby snapshot

È possibile convertire un Autonomous Container Database di standby in uno standby snapshot in un'impostazione di Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database di standby nella configurazione.

Criteri IAM necessari

use autonomous-container-databases

Procedura

Vai alla pagina Dettagli dell'Autonomous Container Database di standby nella configurazione Autonomous Data Guard.
Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Converti in standby snapshot in Azioni.

Nota
La conversione in standby snapshot non è supportata quando è abilitato il failover automatico. È necessario disabilitare il failover automatico prima di eseguire la conversione in standby snapshot. Per istruzioni su come disabilitare il failover automatico in un'impostazione di Autonomous Data Guard, vedere Aggiorna impostazioni di Autonomous Data Guard.
Viene visualizzata la finestra di dialogo Converti in standby snapshot con le opzioni per utilizzare i nuovi servizi di database o i servizi di database primario per le connessioni al database di standby snapshot.
- Usa nuovi servizi di database: fare clic su questa opzione per connettersi allo standby snapshot utilizzando nuovi servizi attivi solo in modalità standby snapshot.
- Usa servizi di database primario: fare clic su questa opzione se si desidera connettersi al database di standby snapshot utilizzando gli stessi servizi del database primario.
  
  Nota
  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 errate del database. Pertanto, quando si sceglie di utilizzare i servizi di database primario, è necessario fare attenzione a utilizzare la stringa di connessione appropriata durante la connessione al database primario e al database di standby snapshot.
Fare clic su Converti.
Sulla console di Oracle Cloud Infrastructure lo stato di Autonomous Container Database mostra AGGIORNAMENTO fino a quando lo standby non cambia in standby snapshot.

Conversione in standby snapshot in standby fisico

È possibile convertire un Autonomous Container Database di standby snapshot in uno standby fisico in un'impostazione di Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database di standby nella configurazione.

Criteri IAM necessari

use autonomous-container-databases

Procedura

Vai alla pagina Dettagli dell'Autonomous Container Database di standby nella configurazione Autonomous Data Guard.
Per istruzioni, vedere Visualizza i dettagli di un Autonomous Container Database.
Fare clic su Converti in standby fisico in Azioni.
Nella finestra di dialogo Converti in standby fisico viene visualizzato un messaggio che avvisa l'utente che la conversione dello standby snapshot in standby fisico eliminerà tutti gli aggiornamenti locali e applicherà i dati dal database primario.
Fare clic su Converti.
Nella console di Oracle Cloud Infrastructure lo stato di Autonomous Container Database è AGGIORNAMENTO fino a quando lo standby non cambia in standby fisico.

Aggiungi un database in standby tra tenancy

SI APPLICA A: solo Oracle Public Cloud

Puoi aggiungere un database di standby Autonomous Data Guard che risiede in una tenancy diversa dal database primario.

Criteri IAM necessari

Per creare un database di standby tra più tenancy, è necessario assicurarsi di soddisfare i requisiti riportati di seguito.

Eseguire i comandi CLI o API per aggiungere il database di standby tra più tenancy nella tenancy di destinazione.
Definire i gruppi e i criteri di OCI Identity and Access Management nelle tenancy di origine e destinazione in modo da poter eseguire i comandi per aggiungere il database di standby tra più tenancy nella tenancy di destinazione e consentire alla tenancy di destinazione di contattare la tenancy di origine in cui risiede il database primario. Quando questi criteri vengono revocati, l'aggiunta di un database di standby tra più tenancy non sarà consentita.
- Nella tenancy di destinazione creare un gruppo (ad esempio: DestinationGroup) e aggiungere gli utenti a cui sarà consentito aggiungere un database di standby tra più tenancy a questo gruppo. Per ulteriori informazioni, vedere Utilizzo della console per la creazione di un gruppo.
- Nella tenancy di origine, creare criteri IAM per consentire al gruppo creato nella tenancy di destinazione (DestinationGroup) di aggiungere un database di standby tra tenancy utilizzando il database primario della tenancy di origine. Per ulteriori informazioni, vedere Utilizzo della console per la creazione di un criterio.
  Ad esempio, è possibile definire un criterio per consentire a un utente nella directory DestinationGroup della directory DestinationTenancy letta da un'istanza specifica di Autonomous Database nel compartimento specificato nella tenancy di origine, come mostrato di seguito:
```
define tenancy DestinationTenancy as ocid1.tenancy.oc1..unique_ID
define group DestinationGroup as ocid1.group.region1..unique_ID
admit group DestinationGroup of tenancy DestinationTenancy to manage autonomous-database-family in
    tenancy
```
  Nota
  Per creare una copia tra tenancy, il criterio deve solo consentire l'accesso in lettura nell'istanza di origine di Autonomous Database.
  Il criterio riportato sopra specifica quanto segue:
  - Riga 1: OCID della tenancy di destinazione in cui si intende aggiungere il database di standby.
  - Riga 2: OCID del gruppo di destinazione a cui appartiene l'utente che creerà il database di standby tra tenancy.
  - Riga 3: OCID del compartimento in cui risiede il database primario e l'OCID del database primario.
- Nella tenancy di destinazione, creare criteri IAM per approvare un gruppo per gestire l'origine del database primario nella tenancy di origine. Per ulteriori informazioni, vedere Utilizzo della console per la creazione di un criterio.
  Ad esempio:
```
define tenancy SourceTenancy as ocid1.tenancy.oc1..unique_ID
endorse group DestinationGroup to manage autonomous-database-family in tenancy SourceTenancy
```
  Il criterio riportato sopra specifica quanto segue:
  - Riga 1: OCID dell'OCID della tenancy di origine in cui risiede il database primario.
  - Riga 2: specifica il gruppo di destinazione che può essere autorizzato a gestire gli Autonomous Database nella tenancy di origine.
  Questo criterio descritto nell'esempio precedente consente a DestinationGroup di creare Autonomous Database e database di standby tra più tenancy nella tenancy di origine. Per ulteriori informazioni ed esempi, consulta la sezione Autorizzazioni IAM e operazioni API per Autonomous Database.

Per aggiungere un database di standby tra tenancy locale (stessa area):

CLI
API REST

Nella tenancy in cui si desidera aggiungere il database di standby, ovvero nella tenancy di destinazione, utilizzare l'interfaccia CLI o chiamare l'API REST e fornire l'OCID del database primario, in cui il database primario risiede in una tenancy diversa (la tenancy di origine).

oci db autonomous-container-database create --cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.iad.unique_ID --compartment-id ocid1.compartment.oc1..unique_ID --display-name clicrosdg --patch-model RELEASE_UPDATES --peer-autonomous-container-database-compartment-id ocid1.compartment.oc1..unique_ID --peer-autonomous-container-database-display-name clisecdg --peer-cloud-autonomous-vm-cluster-id ocid1.autonomousexainfrastructure.oc1.iad.unique_ID --protection-mode MAXIMUM_PERFORMANCE --service-level-agreement-type AUTONOMOUS_DATAGUARD

Una volta eseguito il comando, verrà restituito un work-request-id che può essere utilizzato per tenere traccia dello stato di avanzamento del database in standby. Per ulteriori informazioni, consulta database-container-autonomo.

Per informazioni sugli SDK, vedere Software Development Kits and Command Line Interface.

Per aggiungere un database di standby tra più tenancy che risiede nella stessa area del database primario utilizzando l'API REST, utilizzare AutonomousContainerDatabases.

La chiamata API per creare il database in standby viene inviata alla tenancy diversa nell'area locale.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1..unique_ID",
  "compartmentId": "ocid1.compartment.oc1..unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1..unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapscdg",
  "peerCloudAutonomousVmClusterId": "ocid1.autonomousexainfrastructure.oc1.iad.unique_ID",
  "protectionMode": "MAXIMUM_PERFORMANCE",
  "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}'

Per ulteriori informazioni sull'API REST, vedere AutonomousContainerDatabase.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere API REST e Credenziali di sicurezza.

Per creare un database di standby tra tenancy remoto (tra più aree):

CLI
API REST

Nella tenancy in cui si desidera aggiungere il database di standby, ovvero nella tenancy di destinazione nell'area di destinazione, utilizzare l'interfaccia CLI o chiamare l'API REST e fornire l'OCID del database primario, in cui il database primario risiede in una tenancy e un'area diverse.

oci db autonomous-container-database create --cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.ap-chuncheon-1.unique_ID --compartment-id ocid1.compartment.oc1..unique_ID --display-name clicrosdg --patch-model RELEASE_UPDATES --peer-autonomous-container-database-compartment-id ocid1.compartment.oc1..unique_ID --peer-autonomous-container-database-display-name clisecdg --peer-cloud-autonomous-vm-cluster-id ocid1.autonomousexainfrastructure.oc1.iad.unique_ID --protection-mode MAXIMUM_PERFORMANCE --service-level-agreement-type AUTONOMOUS_DATAGUARD

Una volta eseguito il comando, verrà restituito un work-request-id che può essere utilizzato per tenere traccia dello stato di avanzamento del database in standby. Per ulteriori informazioni, consulta database-container-autonomo.

Per informazioni sugli SDK, vedere Software Development Kits and Command Line Interface.

Per aggiungere un database di standby tra più tenancy che risiede in un'area diversa dal database primario utilizzando l'API REST, utilizzare AutonomousContainerDatabases.

Chiamata API per creare le esecuzioni in standby nella tenancy diversa nell'area di origine.

oci raw-request --http-method POST --target-uri https://database.ap-chuncheon-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.ap-chuncheon-1.unique_ID",
  "compartmentId": "ocid1.compartment.oc1..unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1..unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapscdg",
  "peerCloudAutonomousVmClusterId": "ocid1.autonomousexainfrastructure.oc1.iad.unique_ID",
  "protectionMode": "MAXIMUM_PERFORMANCE",
  "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
   
}'

Per ulteriori informazioni sull'API REST, vedere AutonomousContainerDatabase.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere API REST e Credenziali di sicurezza.

Nota

Dopo aver sottomesso una richiesta di aggiunta di un database di standby tra più tenancy. Lo stato del ciclo di vita del database mostra Aggiornamento. Non è possibile arrestare, avviare, riavviare, ripristinare o spostare l'Autonomous Database in questo stato.