Informazioni su 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 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ù Autonomous Database.

È possibile creare più risorse ACD in una singola risorsa AVMC, ma è necessario crearne almeno una prima di poter creare qualsiasi Autonomous Database. Per una comprensione completa dell'architettura a quattro livelli utilizzata con un'infrastruttura Autonomous Database on Dedicated Exadata e per comprendere il posizionamento di ACD all'interno di questa architettura, fare riferimento a Components of Autonomous Database on Dedicated Exadata Infrastructure.

Gli ACD offrono il vantaggio di operare in isolamento l'uno dall'altro, consentendoti di separare gli Autonomous Database in base agli usi previsti. Ad esempio, è possibile creare ACD diversi per scopi quali produzione e test oppure disporre di più ACD utilizzando versioni di database diverse.

Sebbene gli amministratori della flotta creino, monitorino e gestiscano gli ACD, i DBA delle applicazioni li utilizzano principalmente per creare gli Autonomous Database. Per ulteriori informazioni, consulta la sezione relativa ai ruoli utente associati ad Autonomous Database sull'infrastruttura Exadata dedicata.

Argomenti correlati

Requisiti di Autonomous Container Database

Requisiti dei criteri IAM

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

Requisiti risorse minimi

Per creare un Autonomous Container Database, sono necessari almeno:

8 ECPU o 2 OCPU per nodo
50 GB di storage locale per nodo

Requisiti di versione del software Oracle Database

Per eseguire il provisioning di un ACD con la versione del software Oracle Database impostata su 23ai, è necessario scegliere un cluster VM Autonomous Exadata (AVMC) basato su ECPU creato con il tag DatabaseVersion impostato su 23ai.
Analogamente, per eseguire il provisioning di un ACD con la versione del software Oracle Database impostata su 19c, è necessario scegliere un cluster VM Autonomous Exadata (AVMC) la cui tag DatabaseVersion non è impostata su 23ai.
Non è possibile eseguire il provisioning di ACD 19c e 23ai all'interno dello stesso AVMC.

Nota

Le distribuzioni multicloud non richiedono un tag speciale e supporteranno automaticamente sia i database 19c che i database 23ai.

Funzioni del database gestite da Autonomous Container Database

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

Funzione di Autonomous Database	Note	Ulteriori riferimenti
Versione software Oracle Database È possibile impostare la versione software del container database durante il provisioning di un ACD.	È possibile scegliere la versione del software Oracle Database da una versione di immagine di base o da un'immagine software di Autonomous 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 il relativo predecessore immediato. Ad esempio: si supponga che la versione più recente di Oracle Database supportata da Autonomous Database sia la 19.26.0.1.0. Quindi, nell'elenco a discesa Seleziona immagine di base sono disponibili gli elenchi 19.26.0.1.0 e 19.25.0.1.0 da scegliere. Il provisioning degli Autonomous Container Database (ACD) con la versione software del database 23ai può essere eseguito solo sui cluster VM Autonomous Exadata (AVMC) basati su ECPU creati con le tag appropriate. Per informazioni dettagliate, vedere Requisiti tag della versione del software del database 23ai. Le distribuzioni multicloud non richiedono un tag speciale e supporteranno automaticamente i database 19c e 23ai.	-
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. Tuttavia, il secondo ACD in standby deve trovarsi nella stessa tenancy dell'ACD primario. Gli ACD primari e secondari possono anche essere distribuiti in diverse aree (tra più aree). In un'impostazione di Autonomous Data Guard tra più aree che utilizza chiavi gestite dal cliente o KMS, a seconda del numero di Autonomous Database nell'ACD primario, le nuove versioni delle chiavi verranno generate automaticamente 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 manutenzione della flotta in ogni trimestre e correzioni mensili alla sicurezza dell'infrastruttura per le vulnerabilità con punteggi CVSS maggiori 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 si sceglie il metodo di manutenzione non in sequenza in una configurazione Autonomous Data Guard, si verificherà un tempo di inattività per ACD e tutti gli Autonomous Database 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 di pianificazione della manutenzione per un ACD che deve essere gestito da Oracle oppure impostare una pianificazione di manutenzione personalizzata. Durante la personalizzazione della pianificazione della 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. Questa operazione funge da fallback nel caso in cui la manutenzione non si sia verificata nel precedente trimestre non ignorato. In questo scenario, Oracle eseguirà automaticamente la manutenzione nel mese selezionato, anche se si sceglie di saltare per tale trimestre. È possibile visualizzare il numero di patch singole disponibili per un ACD nella relativa pagina Dettagli. Se si fa clic sul collegamento Copia accanto, vengono copiati tutti i numeri di patch singola. 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 è: è già in corso un aggiornamento di manutenzione oppure Pianificato per un'attività di manutenzione contemporaneamente come ACD. È possibile pianificare una manutenzione su richiesta per aggiornare l'aggiornamento dell'aggiornamento release (RU) 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 per gli Autonomous Database associati, a seconda della configurazione della pianificazione della manutenzione dell'ACD.	Manutenzione del servizio Pianificazione di un aggiornamento manutenzione trimestrale
Criterio di conservazione backup Per supportare l'alta disponibilità, Autonomous 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 abilitati, i backup automatici non possono essere disabilitati per un ACD. 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 Oracle Cloud Infrastructure. Per ulteriori dettagli sui valori dei criteri di conservazione dei backup per distribuzioni diverse di Autonomous Database, vedere Criterio di conservazione dei backup.	Eseguire il backup e il ripristino di database 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. Per istruzioni sulla modifica del tipo di destinazione del backup dopo il provisioning dell'ACD, vedere Modifica impostazioni di backup di Autonomous Container Database.
Utilizzo spazio NFS 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 dettagli, vedere View NFS Space Utilization.
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 massima 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 un Autonomous Database verrà aperto su più nodi. Il valore predefinito di questo attributo è 16 per le OCPU e 64 per le ECPU. Prenotazione failover nodi (%): determina la percentuale di CPU riservate tra i nodi per supportare il failover dei nodi. I valori consentiti sono 0%, 25% e 50%, con il 50% come opzione predefinita. Affinità di distribuzione: determina se è necessario aprire un Autonomous Database 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 server condiviso L'architettura del server condiviso consente a un server di database di consentire a molti processi client di condividere un minimo di processi server, in modo da aumentare il numero di utenti supportato.	Durante il provisioning di un ACD, è possibile abilitare facoltativamente le connessioni al server condiviso. Non è possibile disabilitare l'architettura del server condiviso dopo il provisioning dell'ACD.	Funzioni di connessione per scopi speciali.
Chiave di cifratura Per impostazione predefinita, Autonomous Database crea e gestisce tutte le chiavi di cifratura master utilizzate per proteggere i dati, memorizzandoli 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 Database può invece utilizzare le chiavi che crei e gestisci.	Durante il provisioning di un ACD, è possibile configurare facoltativamente l'ACD in modo che utilizzi chiavi di cifratura gestite dal cliente anziché chiavi di cifratura gestite da Oracle. Quando si utilizzano le chiavi di cifratura gestite dal cliente, è possibile scegliere tra le opzioni riportate di seguito. Servizio vault OCI: con questa opzione è possibile selezionare un vault e una chiave di cifratura master. Questa opzione è disponibile solo in Oracle Public Cloud. Oracle Key Vault: selezionare un keystore con questa opzione e immettere un nome di gruppo di endpoint OKV. Puoi utilizzare le chiavi di cifratura gestite dal cliente con gli ACD abilitati per Autonomous Data Guard con i database primari e in standby situati in domini di disponibilità diversi all'interno della stessa area.	Informazioni sulle chiavi di cifratura principali Usa BYOK (Bring Your Own Keys) nel servizio Vault Usa chiavi gestite dal cliente in Oracle Key Vault Ruota 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 ad Autonomous Container Database.	Oracle consiglia di utilizzare l'indirizzo di posta elettronica di un gruppo di amministratori anziché quello di una persona, se possibile, per garantire che non vengano perse notifiche o annunci importanti.
Full Stack Disaster Recovery Full Stack DR è un servizio di gestione e orchestrazione del 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.	È possibile abilitare OCI Full Stack Disaster Recovery e utilizzarlo per eseguire operazioni di switchover/failover o, facoltativamente, eseguire solo operazioni di switchover/failover di Autonomous Database del database.	Usa OCI Full Stack Disaster Recovery su Autonomous Database sull'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 di Autonomous Database

Note

Ulteriori riferimenti

Versione software Oracle Database

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

È possibile scegliere la versione del software Oracle Database da una versione di immagine di base o da un'immagine software di Autonomous 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 il relativo predecessore immediato. Ad esempio: si supponga che la versione più recente di Oracle Database supportata da Autonomous Database sia la 19.26.0.1.0. Quindi, nell'elenco a discesa Seleziona immagine di base sono disponibili gli elenchi 19.26.0.1.0 e 19.25.0.1.0 da scegliere.

Il provisioning degli Autonomous Container Database (ACD) con la versione software del database 23ai può essere eseguito solo sui cluster VM Autonomous Exadata (AVMC) basati su ECPU creati con le tag appropriate. Per informazioni dettagliate, vedere Requisiti tag della versione del software del database 23ai. Le distribuzioni multicloud non richiedono un tag speciale e supporteranno automaticamente i database 19c e 23ai.

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. Tuttavia, il secondo ACD in standby deve trovarsi nella stessa tenancy dell'ACD primario.

Gli ACD primari e secondari possono anche essere distribuiti in diverse aree (tra più aree). In un'impostazione di Autonomous Data Guard tra più aree che utilizza chiavi gestite dal cliente o KMS, a seconda del numero di Autonomous Database nell'ACD primario, le nuove versioni delle chiavi verranno generate automaticamente 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 manutenzione della flotta in ogni trimestre e correzioni mensili alla sicurezza dell'infrastruttura per le vulnerabilità con punteggi CVSS maggiori 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 si sceglie il metodo di manutenzione non in sequenza in una configurazione Autonomous Data Guard, si verificherà un tempo di inattività per ACD e tutti gli Autonomous Database 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 di pianificazione della manutenzione per un ACD che deve essere gestito da Oracle oppure impostare una pianificazione di manutenzione personalizzata.

Durante la personalizzazione della pianificazione della 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. Questa operazione funge da fallback nel caso in cui la manutenzione non si sia verificata nel precedente trimestre non ignorato. In questo scenario, Oracle eseguirà automaticamente la manutenzione nel mese selezionato, anche se si sceglie di saltare per tale trimestre.

È possibile visualizzare il numero di patch singole disponibili per un ACD nella relativa pagina Dettagli. Se si fa clic sul collegamento Copia accanto, vengono copiati tutti i numeri di patch singola.

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 è:

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

È possibile pianificare una manutenzione su richiesta per aggiornare l'aggiornamento dell'aggiornamento release (RU) 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 per gli Autonomous Database associati, a seconda della configurazione della pianificazione della manutenzione dell'ACD.

Manutenzione del servizio

Pianificazione di un aggiornamento manutenzione trimestrale

Criterio di conservazione backup

Per supportare l'alta disponibilità, Autonomous 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 abilitati, i backup automatici non possono essere disabilitati per un ACD.

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 Oracle Cloud Infrastructure.

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

Eseguire il backup e il ripristino di database 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.

Per istruzioni sulla modifica del tipo di destinazione del backup dopo il provisioning dell'ACD, vedere Modifica impostazioni di backup di Autonomous Container Database.

Utilizzo spazio NFS 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 dettagli, vedere View NFS Space Utilization.

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 massima 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 un Autonomous Database verrà aperto su più nodi. Il valore predefinito di questo attributo è 16 per le OCPU e 64 per le ECPU.
Prenotazione failover nodi (%): determina la percentuale di CPU riservate tra i nodi per supportare il failover dei nodi. I valori consentiti sono 0%, 25% e 50%, con il 50% come opzione predefinita.
Affinità di distribuzione: determina se è necessario aprire un Autonomous Database 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 server condiviso

L'architettura del server condiviso consente a un server di database di consentire a molti processi client di condividere un minimo di processi server, in modo da aumentare il numero di utenti supportato.

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

Funzioni di connessione per scopi speciali.

Chiave di cifratura

Per impostazione predefinita, Autonomous Database crea e gestisce tutte le chiavi di cifratura master utilizzate per proteggere i dati, memorizzandoli 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 Database può invece utilizzare le chiavi che crei e gestisci.

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

Quando si utilizzano le chiavi di cifratura gestite dal cliente, è possibile scegliere tra le opzioni riportate di seguito.

Servizio vault OCI: con questa opzione è possibile selezionare un vault e una chiave di cifratura master. Questa opzione è disponibile solo in Oracle Public Cloud.
Oracle Key Vault: selezionare un keystore con questa opzione e immettere un nome di gruppo di endpoint OKV.

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

Informazioni sulle chiavi di cifratura principali

Usa BYOK (Bring Your Own Keys) nel servizio Vault

Usa chiavi gestite dal cliente in Oracle Key Vault

Ruota 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 ad Autonomous Container Database.

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

Full Stack Disaster Recovery

Full Stack DR è un servizio di gestione e orchestrazione del 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.

È possibile abilitare OCI Full Stack Disaster Recovery e utilizzarlo per eseguire operazioni di switchover/failover o, facoltativamente, eseguire solo operazioni di switchover/failover di Autonomous Database del database.

Usa OCI Full Stack Disaster Recovery su Autonomous Database sull'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

Operazioni di Autonomous Container Database Management

È possibile 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 backup di un Autonomous Container Database	Modifica impostazioni di backup di Autonomous Container Database
Crea un'immagine software di Autonomous Database	Crea un'immagine software di Autonomous 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 un Autonomous Container Database in un altro compartimento	Sposta 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
Termina un Autonomous Container Database	Termina un Autonomous Container Database
Gestire i contatti dei clienti per un Autonomous Container Database	Gestire i contatti cliente 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	Visualizza i dettagli di un Autonomous Container Database
Visualizza utilizzo spazio NFS	SI APPLICA A: solo Exadata Cloud@Customer Visualizza utilizzo spazio NFS

Le operazioni elencate sopra possono essere raggiunte anche utilizzando API. Per ulteriori informazioni, vedere API per la gestione degli Autonomous Container Database.

Monitoraggio di Autonomous Container Database

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

Visualizza le 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.
Visualizza i limiti delle risorse e l'uso corrente.

Per informazioni dettagliate, vedere Viste delle prestazioni dinamiche.

Titolo e informazioni sul copyright

Oracle e/o relative consociate.