Informazioni sull'Autonomous Container Database

Autonomous Container Database (ACD) è uno dei quattro componenti del modello di architettura di database a quattro livelli, che è la base per un Autonomous AI Database sull'infrastruttura Exadata dedicata. Il provisioning degli ACD viene eseguito all'interno di un cluster VM Autonomous Exadata (AVMC) e funge da container per uno o più database AI autonomi.

Puoi creare più risorse ACD in una singola risorsa AVMC, ma devi crearne almeno una prima di poter creare qualsiasi database AI autonomo. Per ottenere una comprensione completa dell'architettura a quattro livelli utilizzata con Autonomous AI Database on Dedicated Exadata Infrastructure e per comprendere il posizionamento di ACD all'interno di questa architettura, fare riferimento AI componenti di per ulteriori informazioni.

Requisiti dell'Autonomous Container Database

Requisiti dei criteri IAM

Devi disporre di un account Oracle Cloud Infrastructure con privilegi concessi tramite i criteri IAM richiesti. I criteri richiesti dipendono dall'operazione che si sta eseguendo. Per una lista di criteri IAM relativi agli Autonomous Container Database, vedere Criteri per la gestione degli Autonomous Container Database.

Requisiti minimi risorse

Per creare un Autonomous Container Database, è necessario almeno:

8 ECPU o 2 OCPU per nodo
Storage locale da 50 GB per nodo

Funzioni del database gestite da Autonomous Container Database

Le funzioni di Autonomous AI Database riportate di seguito possono essere definite e gestite a livello di Autonomous Container Database (ACD).

Funzione Autonomous AI Database	Note	Ulteriori riferimenti
Versione software di Oracle Database È possibile impostare la versione software del container database durante il provisioning di un ACD.	È possibile scegliere la versione software di Oracle Database da una versione dell'immagine di base o da un'immagine software di Autonomous AI Database creata da un altro ACD. Durante la selezione della versione dall'immagine di base, è possibile scegliere la versione più recente del software Oracle Database o quella immediatamente precedente. Ad esempio: supponiamo che la versione più recente di Oracle Database supportata da Autonomous AI Database sia la 19.26.0.1.0. Quindi, l'elenco a discesa Seleziona immagine di base elenca 19.26.0.1.0 e 19.25.0.1.0. da scegliere.	-
Autonomous Data Guard La configurazione di Autonomous Data Guard consente di mantenere i database di produzione critici disponibili per le applicazioni mission critical nonostante gli errori.	Puoi abilitare Autonomous Data Guard dalla pagina Dettagli di un ACD e creare fino a due ACD in standby. Gli ACD primari e secondari possono anche essere distribuiti in aree diverse (cross-region). In un'impostazione di Autonomous Data Guard tra più aree che utilizza chiavi gestite dal cliente o KMS, a seconda del numero di database AI autonomi nell'ACD primario, verranno generate automaticamente nuove versioni delle chiavi per i database di standby nel vault tra più aree.	Proteggi i database critici da errori e disastri utilizzando Autonomous Data Guard
Pianificazione manutenzione In generale, Oracle pianifica ed esegue l'intera distribuzione della manutenzione della flotta per ogni trimestre e correzioni mensili della sicurezza dell'infrastruttura per le vulnerabilità con punteggi CVSS superiori o uguali a 7. È possibile consentire a Oracle di gestire la pianificazione della manutenzione oppure impostare una finestra di manutenzione specifica quando Oracle può iniziare le operazioni di manutenzione.	È possibile scegliere tra i metodi di manutenzione in sequenza o non in sequenza per un ACD. Se scegli un metodo di manutenzione non in sequenza in una configurazione Autonomous Data Guard, ci sarà un tempo di inattività per ACD e per tutti i database Autonomous AI associati fino al completamento dell'applicazione delle patch. Facoltativamente, è anche possibile selezionare Abilita aggiornamento fuso orario. I file dei fusi orari possono essere aggiornati solo utilizzando il metodo di configurazione non in sequenza. È possibile definire o modificare le impostazioni della pianificazione della manutenzione affinché un ACD venga gestito da Oracle oppure è possibile impostare una pianificazione di manutenzione personalizzata. Durante la personalizzazione della pianificazione di manutenzione di un ACD, è possibile scegliere di saltare l'applicazione delle patch per un trimestre. Tuttavia, non è possibile saltare l'applicazione delle patch per due trimestri consecutivi. Quando si sceglie di saltare l'applicazione delle patch per un trimestre, è necessario selezionare almeno un mese da tale trimestre. Questo funge da fallback nel caso in cui la manutenzione non si sia verificata nel precedente trimestre non saltato. In questo scenario, Oracle eseguirà automaticamente la manutenzione nel mese selezionato, anche se per tale trimestre viene scelto di saltare. È possibile visualizzare il numero di patch singole disponibili per un ACD nella relativa pagina Dettagli. Facendo clic sul collegamento Copia accanto a esso vengono copiati tutti i numeri di patch una tantum. Quando si ripianifica un evento di manutenzione ACD già pianificato, Oracle può metterlo in coda se la risorsa dell'infrastruttura Exadata o la risorsa del cluster VM Autonomous Exadata sono le seguenti: È già in corso un aggiornamento della manutenzione oppure Pianificato per un'attività di manutenzione contemporaneamente come ACD. È possibile pianificare una manutenzione su richiesta per aggiornare l'aggiornamento dell'aggiornamento release (Release Update) insieme al file del fuso orario o solo al file del fuso orario per un ACD. È inoltre possibile scegliere di eseguire l'aggiornamento utilizzando un'immagine software del database personalizzata esistente. Potresti riscontrare tempi di inattività per l'ACD e i database AI autonomi associati a seconda della configurazione della pianificazione di manutenzione dell'ACD.	Manutenzione servizio Pianifica aggiornamento manutenzione trimestrale
Backup e ripristino Per supportare l'alta disponibilità, Autonomous AI Database esegue automaticamente il backup del database. Il periodo di conservazione per i backup è fino a 95 giorni a seconda del criterio o del periodo di conservazione dei backup scelto per l'ACD. Puoi ripristinare e ripristinare il database in qualsiasi point-in-time in questo periodo di conservazione.	Una volta abilitato, i backup automatici non possono essere disabilitati per un ACD. Con i backup automatici abilitati, hai la possibilità di eseguire anche backup tra più aree, backup a lungo termine e backup manuali. Puoi definire il criterio o il periodo di conservazione dei backup durante il provisioning di un ACD o modificarlo in un secondo momento dalla relativa pagina dei dettagli sulla console di Oracle Cloud Infrastructure. Puoi conservare i backup di un ACD terminato per un massimo di 72 ore o fino alla fine del periodo di conservazione dei backup. Puoi abilitare il lock di conservazione dei backup per impedire qualsiasi eliminazione indesiderata dei backup ACD e Autonomous AI Database prima del relativo periodo di conservazione. È possibile abilitare il blocco di conservazione durante il provisioning dell'ACD o in un secondo momento. Una volta abilitato, è possibile disabilitare il blocco di conservazione entro 14 giorni, oltre i quali l'impostazione diventa permanente. Una volta abilitato il blocco di conservazione, è possibile solo aumentare il valore del periodo di conservazione e non ridurlo. Anche tutti i backup a lungo termine verranno bloccati e non potranno essere eliminati quando il lock di conservazione è abilitato. I backup a lungo termine vengono eliminati automaticamente alla scadenza. Tuttavia, nel caso delle distribuzioni Exadata Cloud@Customer, se la destinazione di backup è NFS, nessuno dei backup viene eliminato automaticamente quando viene terminato un ACD. È necessario eliminare manualmente tutti i backup automatici, manuali e a lungo termine dopo che l'ACD è stato terminato e la data di scadenza è trascorsa. Per ulteriori dettagli sui valori dei criteri di conservazione dei backup per diverse distribuzioni di Autonomous AI Database, vedere Criterio di conservazione dei backup.	Esegui il backup e il ripristino dei database AI autonomi.
Destinazione backup Una destinazione di backup definisce le proprietà necessarie per connettersi a una posizione di backup e ogni destinazione di backup deve essere accessibile nel data center dai nodi del cluster VM.	La possibilità di scegliere una destinazione di backup durante il provisioning di un ACD e le destinazioni di backup supportate variano a seconda della piattaforma di distribuzione. Per ulteriori dettagli sui diversi tipi di destinazione di backup, vedere Destinazione di backup.	Per ulteriori informazioni sulla configurazione della destinazione di backup NFS per Cloud@Customer, vedere Prerequisiti per le destinazioni di backup per Exadata Cloud@Customer. Fare riferimento alla sezione Modifica impostazioni di backup di Autonomous Container Database per istruzioni sulla modifica del tipo di destinazione di backup dopo il provisioning di ACD.
Utilizzo dello spazio NFS	SI APPLICA A: Solo Exadata Cloud@Customer Se il tipo di destinazione di backup corrente è NFS, l'utilizzo dello spazio NFS corrente viene visualizzato come percentuale insieme a un'icona di stato.	Per ulteriori informazioni, vedere Visualizza utilizzo spazio NFS.
Attributi di Resource Management Gli attributi di gestione delle risorse influiscono sul modo in cui le risorse vengono gestite per consolidare più database o avere la maggiore disponibilità del database.	Facoltativamente, durante il provisioning di un ACD, è possibile definire un valore adatto per i seguenti attributi di gestione delle risorse in base alle proprie esigenze: Soglia di suddivisione del database (CPU): il valore della CPU oltre il quale verrà aperto un Autonomous AI Database su più nodi. Il valore predefinito di questo attributo è 16 per le OCPU e 64 per le ECPU. Riserva di failover del nodo (%): determina la percentuale di CPU riservate tra i nodi per supportare il failover del nodo. I valori consentiti sono 0%, 25% e 50%, con l'opzione predefinita 50%. Affinità di distribuzione: determina se un Autonomous AI Database deve essere aperto su un numero minimo o massimo di nodi. Per impostazione predefinita, è selezionato Numero minimo di nodi.	Per ulteriori informazioni su come questi attributi ACD influiscono sulle prestazioni dei database, vedere Dettagli di fatturazione CPU.
Connessioni al server condiviso Attraverso l'architettura del server condiviso, un database server consente a molti processi client per condividere molto pochi processi server, in modo da aumentarne il numero di utenti che possono essere supportati.	Durante il provisioning di un ACD, è possibile facoltativamente abilitare le connessioni al server condiviso. Non è possibile disabilitare l'architettura del server condiviso dopo il provisioning di ACD.	Funzioni di connessione speciali
Chiave di cifratura Per impostazione predefinita, Autonomous AI Database crea e gestisce tutte le chiavi di cifratura master utilizzate per proteggere i dati, memorizzandole in un keystore PKCS 12 sicuro negli stessi sistemi Exadata in cui risiedono i database. Se i criteri di sicurezza della tua azienda lo richiedono, Autonomous AI Database può invece utilizzare le chiavi che crei e gestisci.	Durante il provisioning di un ACD, è possibile facoltativamente configurare l'ACD in modo che utilizzi chiavi di cifratura gestite dal cliente anziché chiavi di cifratura gestite da Oracle. È possibile scegliere tra le seguenti opzioni quando si utilizzano chiavi di cifratura gestite dal cliente: Servizio vault OCI: con questa opzione si selezionano un vault e una chiave di cifratura master. Questa opzione è disponibile solo su Oracle Public Cloud. Oracle Key Vault: selezionare un keystore con questa opzione e immettere un nome di gruppo di endpoint OKV. Servizio AWS KMS: in Autonomous AI Database su Oracle Database@AWS, puoi utilizzare AWS Key Management Service (AWS KMS) per gestire le chiavi di cifratura master. Puoi utilizzare le chiavi di cifratura gestite dal cliente con ACD abilitati per Autonomous Data Guard con i database primari e in standby che si trovano in domini di disponibilità diversi all'interno della stessa area.	Informazioni sulle chiavi di cifratura primarie Usa BYOK (Bring Your Own Keys) nel servizio vault Usa chiavi gestite dal cliente in Oracle Key Vault Ruotare la chiave di cifratura di un Autonomous Container Database
Posta elettronica contatto È possibile fornire e-mail di contatto in cui è possibile ricevere notifiche operative, annunci e notifiche di manutenzione non pianificate relative all'Autonomous Container Database.	Oracle consiglia di utilizzare l'indirizzo di posta elettronica di un gruppo di amministratori anziché quello di una persona, ove possibile, per assicurarsi che non vengano perse notifiche o annunci importanti.
Full Stack Disaster Recovery Full Stack DR è un servizio di orchestrazione e gestione di disaster recovery Oracle Cloud Infrastructure (OCI) che fornisce funzionalità complete di disaster recovery per tutti i livelli di uno stack di applicazioni, tra cui infrastruttura, middleware, database e applicazione.	Puoi abilitare OCI Full Stack Disaster Recovery e usarlo per eseguire operazioni di switchover/failover o, facoltativamente, eseguire solo operazioni di switchover/failover di Autonomous AI Database.	Utilizza OCI Full Stack Disaster Recovery su Autonomous AI Database su un'infrastruttura Exadata dedicata
Copia di backup tra più aree È possibile selezionare un'area secondaria per una copia dei backup. In caso di errore dell'area, è possibile duplicare il backup remoto di ACD per ripristinare i dati. Il backup di un ACD può essere duplicato solo in un cluster VM Autonomous Exadata (AVMC) diverso dall'AVMC di origine.	SI APPLICA A: Solo Oracle Public Cloud La copia di backup tra più aree può essere abilitata durante il provisioning di un ACD o dalla pagina dei dettagli di un ACD esistente. Non è possibile abilitare il backup tra più aree se Autonomous Data Guard è abilitato.	Informazioni sulla duplicazione di Autonomous Container Database sull'infrastruttura Exadata dedicata Duplica un Autonomous Container database

Funzione Autonomous AI Database

Note

Ulteriori riferimenti

Versione software di Oracle Database

È possibile impostare la versione software del container database durante il provisioning di un ACD.

È possibile scegliere la versione software di Oracle Database da una versione dell'immagine di base o da un'immagine software di Autonomous AI Database creata da un altro ACD.

Durante la selezione della versione dall'immagine di base, è possibile scegliere la versione più recente del software Oracle Database o quella immediatamente precedente. Ad esempio: supponiamo che la versione più recente di Oracle Database supportata da Autonomous AI Database sia la 19.26.0.1.0. Quindi, l'elenco a discesa Seleziona immagine di base elenca 19.26.0.1.0 e 19.25.0.1.0. da scegliere.

Autonomous Data Guard

La configurazione di Autonomous Data Guard consente di mantenere i database di produzione critici disponibili per le applicazioni mission critical nonostante gli errori.

Puoi abilitare Autonomous Data Guard dalla pagina Dettagli di un ACD e creare fino a due ACD in standby.

Gli ACD primari e secondari possono anche essere distribuiti in aree diverse (cross-region). In un'impostazione di Autonomous Data Guard tra più aree che utilizza chiavi gestite dal cliente o KMS, a seconda del numero di database AI autonomi nell'ACD primario, verranno generate automaticamente nuove versioni delle chiavi per i database di standby nel vault tra più aree.

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

Pianificazione manutenzione

In generale, Oracle pianifica ed esegue l'intera distribuzione della manutenzione della flotta per ogni trimestre e correzioni mensili della sicurezza dell'infrastruttura per le vulnerabilità con punteggi CVSS superiori o uguali a 7.

È possibile consentire a Oracle di gestire la pianificazione della manutenzione oppure impostare una finestra di manutenzione specifica quando Oracle può iniziare le operazioni di manutenzione.

È possibile scegliere tra i metodi di manutenzione in sequenza o non in sequenza per un ACD. Se scegli un metodo di manutenzione non in sequenza in una configurazione Autonomous Data Guard, ci sarà un tempo di inattività per ACD e per tutti i database Autonomous AI associati fino al completamento dell'applicazione delle patch. Facoltativamente, è anche possibile selezionare Abilita aggiornamento fuso orario. I file dei fusi orari possono essere aggiornati solo utilizzando il metodo di configurazione non in sequenza.

È possibile definire o modificare le impostazioni della pianificazione della manutenzione affinché un ACD venga gestito da Oracle oppure è possibile impostare una pianificazione di manutenzione personalizzata.

Durante la personalizzazione della pianificazione di manutenzione di un ACD, è possibile scegliere di saltare l'applicazione delle patch per un trimestre. Tuttavia, non è possibile saltare l'applicazione delle patch per due trimestri consecutivi. Quando si sceglie di saltare l'applicazione delle patch per un trimestre, è necessario selezionare almeno un mese da tale trimestre. Questo funge da fallback nel caso in cui la manutenzione non si sia verificata nel precedente trimestre non saltato. In questo scenario, Oracle eseguirà automaticamente la manutenzione nel mese selezionato, anche se per tale trimestre viene scelto di saltare.

È possibile visualizzare il numero di patch singole disponibili per un ACD nella relativa pagina Dettagli. Facendo clic sul collegamento Copia accanto a esso vengono copiati tutti i numeri di patch una tantum.

Quando si ripianifica un evento di manutenzione ACD già pianificato, Oracle può metterlo in coda se la risorsa dell'infrastruttura Exadata o la risorsa del cluster VM Autonomous Exadata sono le seguenti:

È già in corso un aggiornamento della manutenzione oppure
Pianificato per un'attività di manutenzione contemporaneamente come ACD.

È possibile pianificare una manutenzione su richiesta per aggiornare l'aggiornamento dell'aggiornamento release (Release Update) insieme al file del fuso orario o solo al file del fuso orario per un ACD. È inoltre possibile scegliere di eseguire l'aggiornamento utilizzando un'immagine software del database personalizzata esistente.

Potresti riscontrare tempi di inattività per l'ACD e i database AI autonomi associati a seconda della configurazione della pianificazione di manutenzione dell'ACD.

Manutenzione servizio

Pianifica aggiornamento manutenzione trimestrale

Backup e ripristino

Per supportare l'alta disponibilità, Autonomous AI Database esegue automaticamente il backup del database. Il periodo di conservazione per i backup è fino a 95 giorni a seconda del criterio o del periodo di conservazione dei backup scelto per l'ACD. Puoi ripristinare e ripristinare il database in qualsiasi point-in-time in questo periodo di conservazione.

Una volta abilitato, i backup automatici non possono essere disabilitati per un ACD. Con i backup automatici abilitati, hai la possibilità di eseguire anche backup tra più aree, backup a lungo termine e backup manuali.

Puoi definire il criterio o il periodo di conservazione dei backup durante il provisioning di un ACD o modificarlo in un secondo momento dalla relativa pagina dei dettagli sulla console di Oracle Cloud Infrastructure.

Puoi conservare i backup di un ACD terminato per un massimo di 72 ore o fino alla fine del periodo di conservazione dei backup.
Puoi abilitare il lock di conservazione dei backup per impedire qualsiasi eliminazione indesiderata dei backup ACD e Autonomous AI Database prima del relativo periodo di conservazione.
È possibile abilitare il blocco di conservazione durante il provisioning dell'ACD o in un secondo momento.
Una volta abilitato, è possibile disabilitare il blocco di conservazione entro 14 giorni, oltre i quali l'impostazione diventa permanente.
Una volta abilitato il blocco di conservazione, è possibile solo aumentare il valore del periodo di conservazione e non ridurlo.
Anche tutti i backup a lungo termine verranno bloccati e non potranno essere eliminati quando il lock di conservazione è abilitato.

I backup a lungo termine vengono eliminati automaticamente alla scadenza. Tuttavia, nel caso delle distribuzioni Exadata Cloud@Customer, se la destinazione di backup è NFS, nessuno dei backup viene eliminato automaticamente quando viene terminato un ACD. È necessario eliminare manualmente tutti i backup automatici, manuali e a lungo termine dopo che l'ACD è stato terminato e la data di scadenza è trascorsa.

Per ulteriori dettagli sui valori dei criteri di conservazione dei backup per diverse distribuzioni di Autonomous AI Database, vedere Criterio di conservazione dei backup.

Esegui il backup e il ripristino dei database AI autonomi.

Destinazione backup

Una destinazione di backup definisce le proprietà necessarie per connettersi a una posizione di backup e ogni destinazione di backup deve essere accessibile nel data center dai nodi del cluster VM.

La possibilità di scegliere una destinazione di backup durante il provisioning di un ACD e le destinazioni di backup supportate variano a seconda della piattaforma di distribuzione.

Per ulteriori dettagli sui diversi tipi di destinazione di backup, vedere Destinazione di backup.

Per ulteriori informazioni sulla configurazione della destinazione di backup NFS per Cloud@Customer, vedere Prerequisiti per le destinazioni di backup per Exadata Cloud@Customer.

Fare riferimento alla sezione Modifica impostazioni di backup di Autonomous Container Database per istruzioni sulla modifica del tipo di destinazione di backup dopo il provisioning di ACD.

Utilizzo dello spazio NFS

SI APPLICA A: Applicabile

Solo Exadata Cloud@Customer

Se il tipo di destinazione di backup corrente è NFS, l'utilizzo dello spazio NFS corrente viene visualizzato come percentuale insieme a un'icona di stato.

Per ulteriori informazioni, vedere Visualizza utilizzo spazio NFS.

Attributi di Resource Management

Gli attributi di gestione delle risorse influiscono sul modo in cui le risorse vengono gestite per consolidare più database o avere la maggiore disponibilità del database.

Facoltativamente, durante il provisioning di un ACD, è possibile definire un valore adatto per i seguenti attributi di gestione delle risorse in base alle proprie esigenze:

Soglia di suddivisione del database (CPU): il valore della CPU oltre il quale verrà aperto un Autonomous AI Database su più nodi. Il valore predefinito di questo attributo è 16 per le OCPU e 64 per le ECPU.
Riserva di failover del nodo (%): determina la percentuale di CPU riservate tra i nodi per supportare il failover del nodo. I valori consentiti sono 0%, 25% e 50%, con l'opzione predefinita 50%.
Affinità di distribuzione: determina se un Autonomous AI Database deve essere aperto su un numero minimo o massimo di nodi. Per impostazione predefinita, è selezionato Numero minimo di nodi.

Per ulteriori informazioni su come questi attributi ACD influiscono sulle prestazioni dei database, vedere Dettagli di fatturazione CPU.

Connessioni al server condiviso

Attraverso l'architettura del server condiviso, un database server consente a molti processi client per condividere molto pochi processi server, in modo da aumentarne il numero di utenti che possono essere supportati.

Durante il provisioning di un ACD, è possibile facoltativamente abilitare le connessioni al server condiviso. Non è possibile disabilitare l'architettura del server condiviso dopo il provisioning di ACD.

Funzioni di connessione speciali

Chiave di cifratura

Per impostazione predefinita, Autonomous AI Database crea e gestisce tutte le chiavi di cifratura master utilizzate per proteggere i dati, memorizzandole in un keystore PKCS 12 sicuro negli stessi sistemi Exadata in cui risiedono i database.

Se i criteri di sicurezza della tua azienda lo richiedono, Autonomous AI Database può invece utilizzare le chiavi che crei e gestisci.

Durante il provisioning di un ACD, è possibile facoltativamente configurare l'ACD in modo che utilizzi chiavi di cifratura gestite dal cliente anziché chiavi di cifratura gestite da Oracle.

È possibile scegliere tra le seguenti opzioni quando si utilizzano chiavi di cifratura gestite dal cliente:

Servizio vault OCI: con questa opzione si selezionano un vault e una chiave di cifratura master. Questa opzione è disponibile solo su Oracle Public Cloud.
Oracle Key Vault: selezionare un keystore con questa opzione e immettere un nome di gruppo di endpoint OKV.
Servizio AWS KMS: in Autonomous AI Database su Oracle Database@AWS, puoi utilizzare AWS Key Management Service (AWS KMS) per gestire le chiavi di cifratura master.

Puoi utilizzare le chiavi di cifratura gestite dal cliente con ACD abilitati per Autonomous Data Guard con i database primari e in standby che si trovano in domini di disponibilità diversi all'interno della stessa area.

Informazioni sulle chiavi di cifratura primarie

Usa BYOK (Bring Your Own Keys) nel servizio vault

Usa chiavi gestite dal cliente in Oracle Key Vault

Ruotare la chiave di cifratura di un Autonomous Container Database

Posta elettronica contatto

È possibile fornire e-mail di contatto in cui è possibile ricevere notifiche operative, annunci e notifiche di manutenzione non pianificate relative all'Autonomous Container Database.

Oracle consiglia di utilizzare l'indirizzo di posta elettronica di un gruppo di amministratori anziché quello di una persona, ove possibile, per assicurarsi che non vengano perse notifiche o annunci importanti.

Full Stack Disaster Recovery

Full Stack DR è un servizio di orchestrazione e gestione di disaster recovery Oracle Cloud Infrastructure (OCI) che fornisce funzionalità complete di disaster recovery per tutti i livelli di uno stack di applicazioni, tra cui infrastruttura, middleware, database e applicazione.

Puoi abilitare OCI Full Stack Disaster Recovery e usarlo per eseguire operazioni di switchover/failover o, facoltativamente, eseguire solo operazioni di switchover/failover di Autonomous AI Database.

Utilizza OCI Full Stack Disaster Recovery su Autonomous AI Database su un'infrastruttura Exadata dedicata

Copia di backup tra più aree

È possibile selezionare un'area secondaria per una copia dei backup. In caso di errore dell'area, è possibile duplicare il backup remoto di ACD per ripristinare i dati. Il backup di un ACD può essere duplicato solo in un cluster VM Autonomous Exadata (AVMC) diverso dall'AVMC di origine.

SI APPLICA A: Applicabile

Solo Oracle Public Cloud

La copia di backup tra più aree può essere abilitata durante il provisioning di un ACD o dalla pagina dei dettagli di un ACD esistente.

Non è possibile abilitare il backup tra più aree se Autonomous Data Guard è abilitato.

Informazioni sulla duplicazione di Autonomous Container Database sull'infrastruttura Exadata dedicata

Duplica un Autonomous Container database

Operazioni di gestione di Autonomous Container Database

Puoi eseguire le operazioni di gestione riportate di seguito su un Autonomous Container Database.

Operazione	Istruzioni task
Creare un Autonomous Container Database	Creare un Autonomous Container Database
Modificare il criterio di conservazione del backup di un Autonomous Container Database	Modifica impostazioni di backup di Autonomous Container Database
Creare un'immagine software di Autonomous AI Database	Creare un'immagine software di Autonomous AI Database
Modificare le preferenze di manutenzione di un Autonomous Container Database	Aggiorna preferenze di manutenzione di Autonomous Container database
Gestisci configurazione Autonomous Data Guard	Gestisci configurazione Autonomous Data Guard
Spostare Autonomous Container Database in un altro compartimento	Spostare un Autonomous Container Database in un altro compartimento
Ruotare una chiave di cifratura di Autonomous Container Database	Ruotare la chiave di cifratura di un Autonomous Container Database
Riavviare un Autonomous Container Database	Riavviare un Autonomous Container database
Arresta un Autonomous Container database	Arresta un Autonomous Container database
Gestire i contatti dei clienti per un Autonomous Container Database	Gestire i contatti dei clienti per un Autonomous Container Database
Visualizzare una lista di Autonomous Container Database	Visualizzare una lista di Autonomous Container Database
Visualizzare i dettagli di un Autonomous Container Database	Visualizzare i dettagli di un Autonomous Container Database
Visualizza utilizzo spazio NFS	SI APPLICA A: Exadata Cloud@Customer solo Visualizza utilizzo spazio NFS

Le operazioni sopra elencate possono essere ottenute anche utilizzando l'API. Per ulteriori informazioni, vedere API per gestire Autonomous Container Database.

Monitoraggio dell'Autonomous Container Database

È possibile utilizzare le viste delle prestazioni dinamiche per monitorare Autonomous Container Database (ACD) nei modi riportati di seguito.

Visualizza metriche in tempo reale su diversi eventi di attesa e classi di attesa.
Visualizza gli snapshot cronologici delle metriche della classe di attesa.
Visualizza i dati delle metriche delle prestazioni in tempo reale, cronologiche e di riepilogo.
Visualizzare i limiti delle risorse e l'uso corrente.

Per informazioni dettagliate, vedere Viste prestazioni dinamiche.