Gestisci configurazione Autonomous Data Guard

La funzione Autonomous Data Guard di Autonomous AI Database on Dedicated Exadata Infrastructure ti consente di mantenere i database di produzione critici disponibili per le applicazioni mission critical nonostante errori, disastri, errori umani o danneggiamento dei dati. Questo tipo di funzionalità è spesso chiamato disaster recovery.

Abilita Autonomous Data Guard in un Autonomous Container Database

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

Nota: non è possibile abilitare Autonomous Data Guard in un ACD con un'esecuzione di manutenzione attiva pianificata entro i tre giorni successivi.

Autorizzazioni IAM richieste

inspect cloud-autonomous-vmclusters

use autonomous-container-databases

Procedura

Nota: quando è in corso un'operazione di aggiunta ACD in standby, qualsiasi manutenzione pianificata su tale ACD inizierà solo dopo il completamento dell'operazione di aggiunta in standby.

1. Andare alla pagina Dettagli di Autonomous Container Database per il quale si desidera abilitare Autonomous Data Guard.

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

2. Fare clic su Abilita in Autonomous Data Guard in Informazioni su Autonomous Container Database.

3. In alternativa, puoi anche fare clic su Aggiungi standby nei gruppi di Autonomous Data Guard.

4. Compilare la finestra di dialogo Aggiungi standby con le seguenti informazioni:

   Impostazione	Descrizione	Note
   Compartimento di Autonomous Container Database pari livello	Selezionare il compartimento Autonomous Container Database di standby.
   Nome Autonomous Container Database peer	Immettere un nome per l'ACD in standby.	Puoi aggiungere un ACD in standby dall'area AWS all'ACD di cui è già stato eseguito il provisioning nell'area OCI. In alternativa, puoi aggiungere un ACD in standby nell'area OCI a un ACD già di cui è stato eseguito il provisioning nell'area AWS.
   Area peer	Selezionare un'area per l'ACD in standby.	Gli ACD primari e secondari possono anche essere distribuiti in aree diverse (cross-region).
   Infrastruttura Exadata peer	Selezionare la risorsa dell'infrastruttura Exadata di base per l'ACD in standby.
   Cluster VM Autonomous Exadata peer (AVMC)	Selezionare l'AVMC padre per l'ACD in standby.	Nelle distribuzioni Exadata Cloud@Customer, se per l'AVMC padre è abilitata la 3a NIC, tutte le operazioni di Data Guard verranno eseguite solo su questa 3a NIC.
   Modalità di protezione	Selezionare Prestazioni massime o Disponibilità massima dall'elenco a discesa.	Le prestazioni massime sono selezionate per impostazione predefinita. Per informazioni su Autonomous Data Guard e indicazioni nella scelta di dove posizionare il container database autonomo in standby e quale modalità di protezione utilizzare, vedere Informazioni su Autonomous Data Guard e Opzioni di configurazione di Autonomous Data Guard.
   Configurazione backup del database peer	Selezionare un tipo di destinazione backup dall'elenco a discesa. Nelle distribuzioni di Oracle Public Cloud di Autonomous AI Database, puoi scegliere Autonomous Recovery Service o Object Storage come destinazione di backup. L'impostazione predefinita è Storage degli oggetti e l'opzione consigliata è Autonomous Recovery Service. Per Autonomous AI Database su Oracle Database@AWS, puoi scegliere Autonomous Recovery Service, OCI Object Storage o Amazon Simple Storage ( AWS S3). L'impostazione predefinita è AWS S3 e l'opzione consigliata è Autonomous Recovery Service.
   Preferenza per la manutenzione del database peer	Selezionare il numero di giorni per 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.

5. Confermare l'aggiunta del database in standby.

   Nota: una volta abilitato, Autonomous Data Guard può essere disabilitato solo interrompendo l'ACD in standby.

Visualizza lo stato di una configurazione 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

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

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

   Puoi visualizzare i dettagli di Autonomous Data Guard, ad esempio lo stato, il ruolo peer, lo stato peer, la modalità di protezione e l'impostazione di failover automatico in Autonomous Data Guard nelle informazioni di Autonomous Container Database.

2. Puoi anche visualizzare i dettagli di Autonomous Data Guard facendo clic su Gruppi di Autonomous Data Guard.

   La tabella Autonomous Data Guard visualizza informazioni sul container database peer, sul ritardo di applicazione e di trasporto corrente, sullo stato e sulle date di modifica e creazione dell'ultimo ruolo.

Aggiungi un secondo Autonomous Container Database in standby

In un'impostazione di Autonomous Data Guard, puoi aggiungere un secondo Autonomous Container Database (ACD) in 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 primo ACD in standby non deve avere il failover automatico abilitato. È necessario disabilitare il failover automatico nel primo standby prima di aggiungere il secondo standby e riattivarlo 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 su tale ACD inizierà solo dopo il 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. Il database primario non è interessato da questo riavvio non in sequenza.

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

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

2. Fare clic su Aggiungi standby nei gruppi di Autonomous Data Guard.

3. Compila Aggiungi standby con le seguenti informazioni:

   Impostazione	Descrizione
   Compartimento di Autonomous Container Database pari livello	Selezionare il compartimento Autonomous Container Database di standby.
   Nome Autonomous Container Database peer	Immettere un nome per l'ACD in standby. Nota: puoi aggiungere un ACD in standby dall'area AWS all'ACD di cui è stato già eseguito il provisioning nell'area OCI. In alternativa, puoi aggiungere un ACD in standby nell'area OCI a un ACD già di cui è stato eseguito il provisioning nell'area AWS.
   Area peer	Selezionare un'area per l'ACD in standby.
   Infrastruttura Exadata peer	Selezionare la risorsa dell'infrastruttura Exadata di base per l'ACD in standby.
   Cluster VM Autonomous Exadata peer (AVMC)	Selezionare l'AVMC padre per l'ACD in standby.
   Configurazione backup database peer	Selezionare il tipo di destinazione di backup per il secondo database di standby dall'elenco a discesa. Nelle distribuzioni di Oracle Public Cloud di Autonomous AI Database, puoi scegliere Autonomous Recovery Service o Object Storage come destinazione di backup. L'impostazione predefinita è Storage degli oggetti e l'opzione consigliata è Autonomous Recovery Service. Per Autonomous AI Database su Oracle Database@AWS, puoi scegliere Autonomous Recovery Service, OCI Object Storage o Amazon Simple Storage ( AWS S3). L'impostazione predefinita è AWS S3 e l'opzione consigliata è Autonomous Recovery Service.

   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.

4. Fare clic su Aggiungi database di standby.

Cambia ruoli in una configurazione Autonomous Data Guard

Puoi cambiare i ruoli degli Autonomous Container Database primari e in standby in una configurazione di Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database primario o in standby.

Criteri IAM necessari

use autonomous-container-databases

Procedura

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

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

   Nota: non è possibile cambiare i ruoli degli ACD primari e in standby in una configurazione Autonomous Data Guard in cui lo standby si trova nel ruolo standby snapshot.

2. In Azioni fare clic su Switchover.

3. Immettere il nome ACD nella finestra di dialogo di conferma e fare clic su Switchover.

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

Failover in standby in una configurazione Autonomous Data Guard

Si esegue il failover sugli Autonomous Container Database in standby in una configurazione di Autonomous Data Guard dalla pagina Dettagli dell'Autonomous Container Database in standby.

Criteri IAM necessari

use autonomous-container-databases

Procedura

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

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

2. In Azioni, fare clic su Failover.

3. 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 applicato i dati dal database primario. Fare clic su Failover per continuare.

4. Immettere il nome ACD nella finestra di dialogo di conferma e fare clic su Errore.

   Oracle Autonomous AI Database on Dedicated Exadata Infrastructure imposta lo stato del container database di standby su Modifica del ruolo 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.

Ripristinare il standby disabilitato in una configurazione Autonomous Data Guard

Dopo che si è verificato un failover e l'istanza di Autonomous Container Database primario non riuscito assume un ruolo di standby disabilitato, è possibile ripristinare il database non riuscito a un ruolo di standby abilitato dalla 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 in standby.

• Ogni volta che si verifica un failover automatico, Autonomous AI Database on Dedicated Exadata Infrastructure tenta di ripristinare il vecchio database primario come standby. Tuttavia, se il tentativo non riesce, deve essere ripristinato manualmente.

Criteri IAM necessari

use autonomous-container-databases

Procedura

1. Andare alla pagina Dettagli dell'ACD Standard disabilitato che si desidera ripristinare.

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

   Suggerimento

   Il database primario di cui non si è riusciti a eseguire il failover è etichettato come "Standby disabilitato" nella lista di Autonomous Container Database per un compartimento.

2. In Azioni, fare clic su Ripristina.

3. Fornire una conferma per procedere con il ripristino dell'ACD in standby disabilitato.

   Gli stati dei database peer diventano Modifica del ruolo 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 diventa Disponibile.

Aggiorna impostazioni di Autonomous Data Guard

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

Criteri IAM necessari

use autonomous-container-databases

Procedura

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

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

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

3. È possibile effettuare i seguenti aggiornamenti da questa finestra di dialogo:

   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, puoi deselezionare Abilita failover automatico per disabilitare il failover automatico per questa impostazione di Autonomous Data Guard. Se uno dei database in standby si trova nella stessa area del database primario e il secondo si trova in un'area diversa, al database in standby locale verrà assegnata la priorità rispetto allo standby remoto come destinazione di failover automatico. Quando si abilita il failover automatico, uno qualsiasi dei database di standby verrà preso in considerazione per la destinazione di failover automatico.

      Nota: non è possibile abilitare il failover automatico per i database con impostazione di Autonomous Data Guard tra più aree nelle distribuzioni di Exadata Cloud@Customer.

   3. Limite di ritardo del failover di avvio rapido: se il failover automatico è abilitato e la modalità di protezione è Prestazioni massime, il valore del limite di ritardo del failover di avvio 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.

4. Salvare le modifiche.

Nella console di Oracle Cloud Infrastructure, lo stato di Autonomous Container Database mostra UPDATING fino a quando non vengono applicate le impostazioni di Autonomous Data Guard aggiornate.

Converti standby fisico in standby snapshot

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

Criteri IAM necessari

use autonomous-container-databases

Procedura

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

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

2. 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 Autonomous Data Guard.

3. Viene visualizzata la finestra di dialogo Converti in standby snapshot con le opzioni per utilizzare nuovi servizi di database o 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 nella 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 di database primario nel database di standby snapshot può comportare l'inoltro delle 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 quando si sceglie di utilizzare i servizi di database primario.

4. Fare clic su Converti.

   Nella console di Oracle Cloud Infrastructure, lo stato di Autonomous Container Database mostra AGGIORNAMENTO fino a quando il standby non cambia in standby snapshot.

Converti snapshot in standby fisico

È possibile convertire un Autonomous Container Database di standby snapshot in 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

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

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

2. Fare clic su Converti in standby fisico in Azioni.

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

4. Fare clic su Converti.

   Nella console di Oracle Cloud Infrastructure, lo stato di Autonomous Container Database mostra UPDATINGfino a quando lo standby non passa allo standby fisico.

Aggiungi database in standby cross-tenancy

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

SI APPLICA A: Solo Oracle Public Cloud

Criteri IAM necessari

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

• Eseguire i comandi CLI o API per aggiungere il database di standby tra tenancy nella tenancy di destinazione.

• Definire i gruppi e i criteri di OCI Identity and Access Management nelle tenancy di origine e di destinazione in modo da poter eseguire comandi per aggiungere il database di standby tra 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 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 tenancy a questo gruppo. Per istruzioni, vedere Uso della console per creare 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 dalla tenancy di origine. Per istruzioni, vedere Uso della console per creare un criterio.

    Ad esempio, è possibile definire un criterio per consentire a un utente nel file DestinationGroup della lettura DestinationTenancy da un'istanza di Autonomous AI Database specifica 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 **read autonomous-database-family** in
        tenancy
    

    Nota: il criterio deve solo consentire l'accesso in lettura sull'istanza di Autonomous AI Database di origine per creare uno standby tra tenancy.

    Il criterio sopra riportato specifica quanto segue:

    • Riga 1: OCID della tenancy di destinazione in cui si desidera 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: specifica il gruppo di destinazione a cui è possibile consentire la lettura dei database AI autonomi nella tenancy di origine.

  • Nella tenancy di destinazione, creare criteri IAM per approvare un gruppo per gestire l'origine del database primario nella tenancy di origine. Per istruzioni, vedere Uso della console per creare 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 sopra riportato specifica quanto segue:

    • Riga 1: OCID dell'OCID tenancy di origine in cui risiede il database primario.

    • Riga 2: specifica il gruppo di destinazione a cui è consentito gestire i database AI autonomi nella tenancy di origine.

    Questo criterio discusso nell'esempio precedente consente a DestinationGroup di creare database AI autonomi e database di standby tra tenancy nella tenancy di origine. Per ulteriori informazioni ed esempi, vedere Autorizzazioni IAM e operazioni API per Autonomous AI Database.

Aggiungi un database in standby tra tenancy nella stessa area

CLI API REST

È possibile creare un ACD standalone nella tenancy di origine utilizzando l'interfaccia CLI, come mostrato di seguito.

oci --debug db autonomous-container-database create
--cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID
--compartment-id ocid1.compartment.oc1.unique_ID --display-name clicrosdg
--patch-model RELEASE_UPDATES --service-level-agreement-type STANDARD

dove:

• --cloud-autonomous-vm-cluster-id: l'OCID del cluster VM Autonomous Exadata di destinazione in cui verrà eseguito il provisioning del nuovo Autonomous Container Database (ACD).

In alternativa, puoi anche utilizzare un ACD standalone esistente e aggiungere direttamente il database in standby come mostrato di seguito.

Nella tenancy in cui si desidera aggiungere il database in standby, ovvero nella tenancy di destinazione, utilizzare l'interfaccia CLI per aggiungere un database in standby, come mostrato di seguito.

oci --debug db autonomous-container-database add
--autonomous-container-database-id ocid1.autonomouscontainerdatabase.oc1.<region-name>.unique_ID
--peer-autonomous-container-database-display-name clisecdg
--peer-cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID
--protection-mode MAXIMUM_PERFORMANCE
--peer-autonomous-container-database-compartment-id "ocid1.compartment.oc1.unique_ID"

dove:

• --autonomous-container-database-id: l'OCID dell'Autonomous Container Database primario al quale si sta aggiungendo uno standby.

• --peer-autonomous-container-database-display-name: nome riconoscibile dall'utente per il nuovo Autonomous Container Database di standby nella tenancy di destinazione.

• --peer-autonomous-vm-cluster-id: l'OCID del cluster VM Autonomous cloud nella tenancy di destinazione in cui verrà creato il database di standby.

• --peer-autonomous-container-database-compartment-id: OCID del compartimento in cui risiederà l'Autonomous Container Database in standby.

• --protection-mode: definisce la modalità di protezione che verrà utilizzata una volta che ACD è abilitato Data Guard.

Una volta che il comando riesce, verrà restituito un work-request-id che può essere utilizzato per tenere traccia dello stato di avanzamento del database in standby. Per ulteriori informazioni, vedere autonomous-container-database. Nota: se si desidera che il comando venga eseguito in un'area non elencata nel file di configurazione, è necessario impostare l'area richiesta nel prompt dei comandi prima di eseguire il comando oci.

Per informazioni sugli SDK, vedere Software Development Kit and Command Line Interface (interfaccia a riga di comando e kit di sviluppo software).

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

La chiamata API per creare lo standby viene inviata a una tenancy diversa nella stessa area.

Puoi creare un ACD standalone nella tenancy di origine utilizzando l'API REST come mostrato di seguito.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases
--request-body '{
"cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID",
"compartmentId": "ocid1.compartment.oc1.unique_ID",
"displayName": "cliapcrdg",
"patchModel": "RELEASE_UPDATES",
"serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}''

dove:

• cloudAutonomousVmClusterId: l'OCID del cluster VM Autonomous Exadata di destinazione in cui verrà eseguito il provisioning del nuovo Autonomous Container Database (ACD).

In alternativa, puoi anche utilizzare un ACD standalone esistente e aggiungere direttamente il database in standby come mostrato di seguito.

Nella tenancy in cui si desidera aggiungere il database di standby, ovvero nella tenancy di destinazione, utilizzare l'API REST per aggiungere un database di standby, come mostrato di seguito:

oci raw-request --http-method POST --target-uri
https://database.<region-name>.oraclecloud.com/../../ocid1.autonomouscontainerdatabase.oc1.<region-name>../actions/addStandby
--request-body '{
  "peerCloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<region-name>.unique_ID",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1.unique_ID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapsec1",
   "protectionMode": "MAXIMUM_PERFORMANCE",
}'

dove:

• peerCloudAutonomousVmClusterId: l'OCID del cluster VM Cloud Autonomous nella tenancy di destinazione in cui verrà creato il database di standby.

• peerAutonomousContainerDatabaseCompartmentId: OCID del compartimento in cui risiederà l'Autonomous Container Database in standby.

• peerAutonomousContainerDatabaseDisplayName: nome riconoscibile dall'utente per il nuovo Autonomous Container Database di standby nella tenancy di destinazione.

• protectionMode: definisce la modalità di protezione che verrà utilizzata una volta che ACD è abilitato Data Guard.

Per ulteriori informazioni sull'API REST, vedere AutonomousContainerDatabase.

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

Creare un database in standby cross-tenancy in un'area remota

CLI API REST

È possibile creare un ACD standalone nella tenancy di origine (se non ne è già stato creato uno) utilizzando l'interfaccia CLI, come mostrato di seguito.

oci --debug db autonomous-container-database create
--cloud-autonomous-vm-cluster-id ocid1.cloudautonomousvmcluster.oc1.<sourceregion-name>.unique_ID
--compartment-id ocid1.compartment.oc1.unique_ID --display-name clicrosdg
--patch-model RELEASE_UPDATES --service-level-agreement-type STANDARD

dove:

• --cloud-autonomous-vm-cluster-id: l'OCID del cluster VM Autonomous Exadata di destinazione in cui verrà eseguito il provisioning del nuovo Autonomous Container Database (ACD).

In alternativa, puoi anche utilizzare un ACD standalone esistente e aggiungere direttamente il database in standby come mostrato di seguito.

Nella tenancy in cui si desidera aggiungere il database in standby, ovvero nella tenancy di destinazione nell'area remota, utilizzare l'interfaccia CLI per aggiungere un database in standby, come mostrato di seguito.

oci --debug db autonomous-container-database add
--autonomous-container-database-id "ocid1.autonomouscontainerdatabase.oc1.<sourceregion-name>.unique_ID"
--peer-autonomous-container-database-display-name "cliCrosstSec2"
--protection-mode "MAXIMUM_PERFORMANCE"
--peer-cloud-autonomous-vm-cluster-id "ocid1.cloudautonomousvmcluster.oc1.<remoteregion-name>.uniqueID"
--peer-autonomous-container-database-compartment-id "ocid1.compartment.oc1..uniqueID"

dove:

• --autonomous-container-database-id: l'OCID dell'Autonomous Container Database primario nell'area di origine a cui si sta aggiungendo uno standby.

• --peer-autonomous-container-database-display-name: nome riconoscibile dall'utente per il nuovo Autonomous Container Database in standby nell'area di destinazione e nella tenancy di destinazione.

• --peer-autonomous-vm-cluster-id: l'OCID del cluster VM Cloud Autonomous nell'area di destinazione e nella tenancy di destinazione in cui verrà creato il database di standby.

• -peer-autonomous-container-database-compartment-id: OCID del compartimento in cui risiederà l'Autonomous Container Database in standby.

• --protection-mode: definisce la modalità di protezione che verrà utilizzata una volta che ACD è abilitato Data Guard.

Nota: se l'area remota è diversa da quella elencata nel file di configurazione predefinito, è necessario impostare l'area remota richiesta nel prompt dei comandi prima di eseguire il comando oci.

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

Per informazioni sugli SDK, vedere Software Development Kit and Command Line Interface (interfaccia a riga di comando e kit di sviluppo software).

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

Puoi creare un ACD standalone nella tenancy di origine utilizzando l'API REST come mostrato di seguito.

oci raw-request --http-method POST --target-uri https://database.us-ashburn-1.oraclecloud.com/20160918/autonomousContainerDatabases --request-body '{
  "cloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<sourceregion-name>.unique_ID",
  "compartmentId": "ocid1.compartment.oc1.unique_ID",
  "displayName": "cliapcrdg",
  "patchModel": "RELEASE_UPDATES",
   "serviceLevelAgreementType": "AUTONOMOUS_DATAGUARD",
}'

dove:

• cloudAutonomousVmClusterId: l'OCID del cluster VM Autonomous Exadata di destinazione in cui verrà eseguito il provisioning del nuovo Autonomous Container Database (ACD).

In alternativa, puoi anche utilizzare un ACD standalone esistente e aggiungere direttamente il database in standby come mostrato di seguito.

Nella tenancy in cui si desidera aggiungere il database di standby, ovvero nella tenancy di destinazione nell'area di destinazione, utilizzare l'API REST per aggiungere un database di standby, come mostrato di seguito:

oci raw-request --http-method POST --target-uri
https://database.ap-chuncheon-1.oraclecloud.com/20160918/autonomousContainerDatabases/ocid1.autonomouscontainerdatabase.oc1.<sourceregion-name>../actions/addStandby
--request-body '{
  "peerCloudAutonomousVmClusterId": "ocid1.cloudautonomousvmcluster.oc1.<remoteregion-name>.uniqueID",
  "peerAutonomousContainerDatabaseCompartmentId": "ocid1.compartment.oc1.uniqueID",
  "peerAutonomousContainerDatabaseDisplayName": "cliapsec2",
   "protectionMode": "MAXIMUM_PERFORMANCE",
}'

dove:

• peerCloudAutonomousVmClusterId: l'OCID del cluster VM Cloud Autonomous nella tenancy di destinazione in cui verrà creato il database di standby.

• peerAutonomousContainerDatabaseCompartmentId: OCID del compartimento in cui risiederà l'Autonomous Container Database in standby.

• peerAutonomousContainerDatabaseDisplayName: nome riconoscibile dall'utente per il nuovo Autonomous Container Database di standby nella tenancy di destinazione.

• protectionMode: definisce la modalità di protezione che verrà utilizzata una volta che ACD è abilitato Data Guard.

Per ulteriori informazioni sull'API REST, vedere AutonomousContainerDatabase.

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

Nota: dopo aver sottomesso una richiesta di aggiunta di un database di standby tra tenancy, lo stato del ciclo di vita del database mostra l'aggiornamento. Non è possibile arrestare, avviare, riavviare, ripristinare o spostare Autonomous AI Database in questo stato.

Contenuto correlato

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