Gestione della computazione in Autonomous AI Database su un'infrastruttura Exadata dedicata

Autonomous AI Database on Dedicated Exadata Infrastructure offre due modelli di computazione durante la configurazione delle risorse del database AI autonomo. Sono:

  • ECPU: un'ECPU è una misura astratta delle risorse di computazione. Le ECPU si basano sul numero di memorie Centrali allocate in modo elastico da un pool di server di computazione e storage. Hai bisogno di almeno 2 ECPU per eseguire il provisioning di un database AI autonomo.

    Durante il provisioning di un nuovo database, la duplicazione di un database esistente e lo scale-up o lo scale-down delle risorse CPU di un database esistente, il conteggio delle CPU viene impostato automaticamente su 2 ECPU, con incrementi di 1. Ad esempio, il successivo numero di ECPU disponibili sopra 2 è 3.

    Puoi creare istanze di Autonomous AI Database for Developers su container database basati su ECPU. Sono database AI autonomi gratuiti che gli sviluppatori possono utilizzare per creare e testare nuove applicazioni. Per ulteriori dettagli, consulta l'Autonomous AI Database for Developers.

  • OCPU: una OCPU è una misura fisica delle risorse di calcolo. Le OCPU si basano sulla memoria centrale fisica di un processore con hyperthreading abilitato.

    Nota

    OCPU è una metrica di fatturazione legacy ed è stata ritirata per Autonomous AI Database on Dedicated Exadata Infrastructure. Oracle consiglia di utilizzare le ECPU per tutte le distribuzioni Autonomous AI Database nuove ed esistenti. Per ulteriori informazioni, consultare il documento di supporto Oracle 2998755.1.

    Durante il provisioning di un nuovo database, la duplicazione di un database esistente e lo scale-up o lo scale-down delle risorse CPU di un database esistente:

    • Il conteggio CPU viene impostato automaticamente su 1 OCPU con incrementi di 1. Ad esempio, il successivo numero disponibile di OCPU sopra 1 è 2.
    • Per i database che non richiedono un'intera OCPU, puoi assegnare OCPU da 0,1 a 0,9 con incrementi di 0,1 OCPU. Ciò consente di eseguire il provisioning eccessivo della CPU ed eseguire più database su ogni istanza dell'infrastruttura. Per ulteriori dettagli, vedere Provisioning in eccesso della CPU.

Il tipo di computazione del cluster VM Autonomous Exadata si applica a tutte le istanze Autonomous Container Database e Autonomous AI Database.

Argomenti correlati

Gestione computazione

Le istanze di Autonomous AI Database vengono distribuite in un cluster VM Autonomous Exadata (AVMC) e in uno degli Autonomous Container Database (ACD) figlio. Le infrastrutture Exadata sono in grado di eseguire più AVMC. Le CPU allocate durante il provisioning di una risorsa AVMC saranno le totali CPU disponibili per i relativi database AI autonomi. Quando si creano più AVMC, ogni AVMC può avere il proprio valore per il totale delle CPU.

Più cluster VM Autonomous Exadata VM non è disponibile in alcuna distribuzione Oracle Public Cloud di risorse Exadata Infrastructure (EI) create prima dell'avvio della funzione Autonomous AI Database di più VM. Per le risorse dell'infrastruttura Exadata di generazione X8M e successive create dopo l'avvio della funzione AVMC multipla, ogni AVMC viene creato con un nodo cluster per ciascuno dei server della forma del sistema Exadata scelta. Per informazioni sulla limitazione di queste CPU totali tra gruppi diversi di utenti, vedere In che modo le quote compartimento influiscono sulla gestione della CPU.

Nota

Il numero massimo di risorse AVMC e ACD che è possibile creare su una determinata infrastruttura Exadata varia in base alla generazione di hardware. Per informazioni dettagliate sui vincoli per ogni generazione, vedere Limiti delle risorse e Caratteristiche delle forme dell'infrastruttura.

A livello AVMC o ACD, il numero totale di CPU disponibili per la creazione dei database è denominato CPU disponibili. A livello di risorsa AVMC, le CPU disponibili saranno uguali al totale delle CPU fino a quando non si crea il primo ACD. Dopo aver creato un ACD, 8 ECPU o 2 OCPU per nodo vengono allocate al nuovo ACD dalle CPU disponibili di AVMC. Pertanto, le CPU disponibili a livello di risorsa AVMC si riducono di conseguenza. Quando crei il primo database AI autonomo in tale ACD, il nuovo database utilizza le CPU inizialmente allocate (8 ECPU o 2 OCPU per nodo). Se il nuovo database richiede più di 8 ECPU o 2 OCPU, viene assegnato dalle CPU disponibili dell'AVMC padre, riducendo le CPU disponibili a livello di AVMC padre. Quando crei più ACD ed esegui il provisioning dei database AI autonoma all'interno di ogni ACD, il valore della CPU disponibile cambia di conseguenza.

Le CPU disponibili a livello di cluster VM Autonomous Exadata si applicano a tutti i relativi Autonomous Container Database. Questo conteggio delle CPU disponibili per il container database diventa importante se si utilizza la funzione di scala automatica, come descritto in Allocazione CPU durante la scala automatica.

Analogamente, quando esegui manualmente la scalabilità delle CPU di un database AI autonomo, le CPU vengono consumate dalle CPU disponibili a livello di AVMC padre e il loro valore cambia di conseguenza.

Quando crei un Autonomous AI Database, per impostazione predefinita Oracle riserva CPU aggiuntive per garantire che il database possa essere eseguito con almeno il 50% di capacità anche in caso di errori dei nodi. Durante il provisioning di un ACD, puoi modificare la percentuale di CPU riservate tra i nodi allo 0% o al 25%. Per istruzioni, vedere Prenotazione del failover del nodo in Creare un Autonomous Container Database. Queste CPU aggiuntive non sono incluse nella fatturazione.

Quando un database AI autonomo è in esecuzione, ti verrà fatturato il numero di CPU attualmente allocate al database, specificate durante la creazione iniziale o in seguito da un'operazione di ridimensionamento manuale. Inoltre, se il ridimensionamento automatico è abilitato per il database, viene fatturato ogni secondo per eventuali CPU aggiuntive utilizzate dal database come risultato del ridimensionamento automatico. Per ulteriori informazioni su come viene misurata e calcolata la fatturazione, vedere Dettagli fatturazione CPU.

Quando si arresta un Autonomous AI Database, non viene fatturato alcun importo. Tuttavia, il numero di CPU ad esso allocate non viene restituito alle CPU disponibili al livello AVMC padre per la distribuzione complessiva.

Quando un Autonomous AI Database viene arrestato o ridimensionato, il numero di CPU ad esso allocate non viene immediatamente restituito alle CPU disponibili al livello AVMC padre per la distribuzione complessiva. Continuano a essere incluse nel conteggio delle CPU disponibili per il container database padre fino al riavvio del container database padre. Queste CPU sono denominate CPU recuperabili. Le CPU recuperabili a livello di AVMC padre sono la somma delle CPU recuperabili di tutti i relativi ACD. Quando un ACD viene riavviato, restituisce tutte le relative CPU recuperabili alle CPU disponibili a livello di AVMC padre.

Il riavvio di un Autonomous Container Database (ACD) è un'operazione in linea, eseguita in sequenza nel cluster e non comporta tempi di inattività delle applicazioni se configurata in base alle procedure ottimali per l'uso della continuità di applicazione trasparente.

Suggerimento

Puoi tenere traccia dei diversi attributi di computazione (CPU) descritti in questo articolo dalla pagina Dettagli di un cluster VM Autonomous Exadata (AVMC) o Autonomous Container Database (ACD). Per istruzioni, fare riferimento a Registrazione uso risorse.

Allocazione CPU durante il ridimensionamento automatico

La funzione di scala automatica consente a un Autonomous AI Database di utilizzare fino a tre volte più risorse CPU e I/O rispetto al conteggio di CPU allocato. In caso di overprovisioning della CPU, se tre volte il conteggio della CPU risulta in un valore inferiore a 1, verrà arrotondato al numero intero successivo. L'overprovisioning della CPU è supportato solo con OCPU. Per ulteriori dettagli, vedere Overprovisioning CPU.

Per garantire che nessun singolo Autonomous AI Database possa eseguire automaticamente la scalabilità fino al consumo di tutte le CPU disponibili nel pool per la distribuzione complessiva, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata utilizza Autonomous Container Database come controllo limitante.

Durante il provisioning di un database AI autonomo abilitato per la scala automatica in un ACD, se le CPU disponibili in tale ACD sono inferiori al valore CPU 3X del nuovo database, verranno prenotate altre CPU in tale ACD. Queste CPU sono denominate CPU riservate. Le CPU riservate garantiscono che le CPU disponibili a livello di ACD siano sempre maggiori o uguali al valore della CPU 3x del database abilitato per la scala automatica più grande in tale ACD. Queste CPU riservate possono comunque essere utilizzate per creare o ridimensionare manualmente i database AI autonomi in questo ACD.

Quando si esegue automaticamente lo scale-up di un Autonomous AI Database, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata cerca CPU inattive nel container database padre. Se sono disponibili CPU inattive, viene eseguito lo scale up del database AI autonomo; in caso contrario, non lo è. I database hanno intrinsecamente molto tempo di inattività, quindi il ridimensionamento automatico è un modo per massimizzare l'uso delle risorse, controllando al contempo i costi e preservando un buon isolamento dai database in altri Autonomous Container Database.

Se la CPU utilizzata per ridimensionare automaticamente un Autonomous AI Database proviene da un altro Autonomous AI Database in esecuzione che è leggermente caricato e quindi non utilizza tutte le CPU allocate, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata ridimensiona automaticamente il database con scala automatica se il carico aumenta nell'altro database e richiede la CPU allocata.

Prendi in considerazione l'esempio di un Autonomous Container Database che ospita quattro Autonomous AI Database con 4 CPU in esecuzione, il tutto con la scala automatica abilitata. Il conteggio delle CPU disponibili per il container database ai fini della scala automatica è 12. Se uno di questi database deve essere ridimensionato automaticamente oltre le 4 CPU a causa dell'aumento del carico, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata eseguirà l'operazione di ridimensionamento automatico solo se uno o più degli altri database vengono caricati leggermente e non utilizzano tutte le CPU allocate. Il costo di fatturazione di questo esempio è di 16 CPU al minimo perché tutti e quattro i database 4 CPU sono sempre in esecuzione.

Al contrario, prendi in considerazione l'esempio di un Autonomous Container Database che ospita quattro Autonomous AI Database con 2 CPU in esecuzione, il tutto con la scala automatica abilitata e un Autonomous AI Database con 8 CPU arrestate. Il conteggio delle CPU disponibili per il container database ai fini della scala automatica è di nuovo 16. Se uno dei database in esecuzione deve essere ridimensionato automaticamente a causa dell'aumento del carico oltre le 2 CPU, Oracle Autonomous AI Database sull'infrastruttura Exadata dedicata può eseguire l'operazione utilizzando le CPU allocate al database 8-CPU arrestato. In questo esempio, i quattro database in esecuzione possono utilizzare fino a un totale di 8 CPU aggiuntive contemporaneamente senza consumare le CPU allocate l'una dell'altra. Il costo di fatturazione di questo esempio è di sole 8 CPU al minimo perché solo i quattro database da 2 CPU sono sempre in esecuzione.

Per qualsiasi istanza del servizio Autonomous Data Guard, locale o tra più aree, il prezzo aggiuntivo sarà il numero di ECPU o OCPU riservate durante la creazione o il ridimensionamento esplicito dell'istanza del servizio primario, indipendentemente dal fatto che la scala automatica sia abilitata o meno. Il consumo di ECPU o OCPU correlato al ridimensionamento automatico nelle istanze del servizio primario non si verifica nelle istanze del servizio Autonomous Data Guard in standby.

In che modo le quote del compartimento influiscono sulla gestione della CPU

In genere, quando crei o esegui lo scale up di un Autonomous AI Database, la capacità di Oracle Autonomous AI Database su un'infrastruttura Exadata dedicata per soddisfare la tua richiesta dipende solo dalla disponibilità di CPU non allocate nel singolo pool di CPU nell'intera distribuzione.

Tuttavia, puoi utilizzare la funzione di quote di compartimento di Oracle Cloud Infrastructure per limitare ulteriormente, in un compartimento per compartimento, il numero di CPU disponibili per creare, ridimensionare manualmente e ridimensionare automaticamente Autonomous AI Database di ogni tipo di carico di lavoro (Autonomous AI Lakehouse o Autonomous AI Transaction Processing) singolarmente.

In breve, si utilizza la funzione Quote del compartimento creando le istruzioni dei criteri set, unset e zero per limitare la disponibilità di una determinata risorsa in un determinato compartimento. Per informazioni e istruzioni dettagliate, vedere Quota compartimento.

In che modo i nodi del cluster VM influiscono sulla gestione della CPU

Nella precedente discussione sugli stati di gestione e allocazione della CPU è possibile creare più risorse AVMC (Autonomous Exadata VM Cluster) scegliendo il conteggio CPU per nodo durante il provisioning della risorsa AVMC.

In questa sezione verranno descritti i dettagli granulari su come Oracle Cloud Infrastructure posiziona i database AI autonomi nei nodi del cluster VM e sulle conseguenze di tale posizionamento sulla scala automatica e sull'elaborazione parallela.

I seguenti attributi determinano quando e in che modo un Autonomous AI Database viene posizionato su più nodi:

  • Soglia di divisione: il valore della CPU oltre il quale Oracle Cloud Infrastructure apre un Autonomous AI Database su più nodi. La soglia di suddivisione predefinita è 64 per le ECPU e 16 per le OCPU, ma se i cluster VM vengono creati con i conteggi dei nodi CPU inferiori al valore predefinito, il valore predefinito viene sostituito dalla dimensione del conteggio dei nodi del cluster VM.È inoltre possibile impostare il valore di divisione in modo esplicito utilizzando l'attributo Soglia di divisione durante il provisioning di un Autonomous Container Database (ACD).

    I database AI autonoma creati con un valore CPU inferiore al valore di divisione verranno aperti su un nodo nel cluster e quelli creati con un valore CPU maggiore del valore di soglia di divisione verranno aperti su più nodi.

    • Si supponga di creare un ACD con una soglia di suddivisione predefinita (64 ECPU) in un AVMC con due nodi e 40 ECPU per nodo. Poiché 40 è inferiore a 64, qualsiasi database AI autonomo con un requisito CPU maggiore di 40 verrà diviso e aperto su più nodi, consentendo richieste DML in tali nodi. Tuttavia, se l'AVMC è stato creato con due nodi e 80 ECPU per nodo, qualsiasi database con un requisito ECPU maggiore di 64 verrà diviso e aperto su più nodi.

    • Si supponga di creare un ACD in un cluster VM con due nodi e 40 ECPU per nodo e di impostare esplicitamente il valore della soglia di suddivisione su un valore molto più piccolo, ad esempio 20 ECPU. Qualsiasi database AI autonoma con un requisito CPU maggiore di 20 verrà diviso e aperto su più nodi e i database con un requisito CPU minore di 20 verranno aperti su un singolo nodo.

      L'impostazione della soglia di suddivisione su un numero molto più piccolo rispetto al valore predefinito aumenta le probabilità che i database con conteggi CPU più piccoli si aprano su più nodi, a condizione che il loro conteggio di CPU sia superiore al valore di suddivisione impostato. Ogni volta che un database viene creato o ridimensionato a una dimensione maggiore di questo valore di divisione, viene aperto su più nodi. Ciò è utile quando si desidera che i database vengano aperti su più nodi per controllare il deterioramento delle prestazioni in caso di errore del nodo o manutenzione pianificata. Con i database suddivisi in più nodi in cluster RAC di dimensioni maggiori, se un nodo qualsiasi non riesce o quando si verifica la manutenzione pianificata, è possibile continuare ad avere prestazioni più elevate anziché passare a un profilo delle prestazioni del 50%.

    • Si supponga di impostare esplicitamente la soglia di suddivisione su un valore molto più alto del valore predefinito, ad esempio 80 ECPU, in un AVMC con due nodi e 40 ECPU. Qualsiasi database AI autonoma con un requisito CPU maggiore di 40 verrà diviso e aperto su più nodi e i database con un requisito CPU minore di 40 verranno aperti su un singolo nodo.

      L'impostazione della soglia di suddivisione su un valore molto superiore a quello predefinito fa sì che il DML del database rimanga su un singolo nodo RAC ed elimini la possibilità di conflitti di attesa tra cluster.

    • Quando si ridimensiona manualmente un database AI autonomo, il nuovo valore CPU verrà applicato al modello di suddivisione esistente. In altre parole, se il nuovo valore è inferiore alla soglia di frazionamento, verrà aperto su un nodo e se il valore è maggiore della soglia di frazionamento, verrà aperto su più nodi.

  • Affinità della distribuzione: determina il numero di nodi su cui verrà aperto un Autonomous AI Database una volta superata la soglia di divisione.

    Si supponga, ad esempio, di aver creato una risorsa AVMC con 4 nodi e 80 ECPU per nodo e di aver creato un ACD in questo AVMC con Soglia di divisione del database impostata su 64. La creazione di un Autonomous AI Database con un requisito ECPU pari a 120 dividerà e aprirà il database su più nodi come 120 maggiore di 64 (Soglia di divisione).

    • Se l'affinità di distribuzione è impostata su Nodi minimi, Oracle Cloud Infrastructure tenta di creare il database su 2 nodi con 60 ECPU su ciascun nodo. Se ciò non è possibile, verrà diviso su 3 nodi con 40 ECPU ciascuno. Se anche questo non è possibile, Oracle Cloud Infrastructure tenterà di aprire il database su 4 nodi con 30 ECPU ciascuna.

    • Se si specifica l'affinità di distribuzione per Numero massimo di nodi, Oracle Cloud Infrastructure tenta di creare la suddivisione del database su tutti e 4 i nodi con 30 ECPU ciascuna. Se ciò non è possibile, verrà diviso su tre nodi con 40 ECPU ciascuno. Se anche questo non è possibile, Oracle Cloud Infrastructure tenterà di aprire il database su 2 nodi con 60 ECPU ciascuna.

  • Prenotazione failover nodi (%): numero di CPU accantonate sui nodi adiacenti (nodi in cui il software del database è presente ma non aperto) in AVMC per gli eventi di errore e manutenzione localizzati. L'assegnazione del failover dei nodi si applica alle distribuzioni di database non divisi.Per impostazione predefinita, è previsto un impegno del 50%, ovvero durante un evento di errore o una manutenzione, l'esecuzione continuerà ma con il 50% della CPU allocata.

    • Per i database o i database non critici con un utilizzo molto leggero, è possibile impostare la prenotazione di failover dei nodi su un valore inferiore in modo da poter creare e consolidare un numero maggiore di database nell'infrastruttura Exadata dedicata.

    • È possibile impostare questo valore su zero per l'ambiente di sviluppo e i database in cui è accettabile un tempo di inattività durante la manutenzione.

    • In una certa misura, la riserva di failover del nodo può anche essere controllata garantendo che un database venga diviso su più di 2 nodi, utilizzando la soglia di divisione e l'affinità di distribuzione.Prendi in considerazione uno scenario in cui un Autonomous AI Database viene suddiviso in 4 nodi. Rimuovendo un nodo alla volta in sequenza mentre è in corso un'attività di manutenzione, hai sempre 3 nodi ancora attivi e prendi traffico, mantenendo la tua riserva di prestazioni in modo efficace del 75%, piuttosto che del solito 50%. Con cluster più grandi, puoi aumentare ulteriormente questa riserva, ad esempio con una riserva dell'87,5% su un cluster a 8 nodi.
Il modo in cui l'allocazione della CPU di un database AI autonomo viene distribuita tra i nodi cluster VM influisce sulle operazioni riportate di seguito.
  • Scala automatica:
    • Il ridimensionamento automatico può verificarsi all'interno di un singolo nodo cluster VM per DML non parallelizzabile e tra i nodi cluster VM se il DML è parallelizzabile.
    • È possibile instradare più sessioni concorrenti con query non parallelizzabili a tutti i nodi del cluster, consentendo in modo efficace il ridimensionamento automatico su tutti i nodi in un database a più nodi.
  • Elaborazione parallela:
    • L'elaborazione parallela delle istruzioni SQL si verifica all'interno dei nodi del cluster VM Autonomous Exadata aperti, prima all'interno di un singolo nodo e poi nei nodi aperti adiacenti, che, come descritto in precedenza, dipenderà dalla dimensione del cluster VM Autonomous Exadata.

In base all'utilizzo delle risorse su ogni nodo; non tutti i valori delle CPU disponibili possono essere utilizzati per eseguire il provisioning o lo scale scale del database AI autonomo. Si supponga, ad esempio, di disporre di 20 CPU disponibili a livello di AVMC, che non tutti i valori compresi tra 1 e 20 CPU possano essere utilizzati per eseguire il provisioning o la scalabilità di Autonomous AI Database a seconda della disponibilità delle risorse a livello di nodo. La lista di valori CPU che è possibile utilizzare per eseguire il provisioning o ridimensionare un Autonomous AI Database è denominata CPU con provisioning consentito.

Quando provi a eseguire il provisioning o a ridimensionare un Autonomous AI Database dalla console OCI, il campo CPU ti fornirà un elenco a discesa con l'elenco di CPU di cui è possibile eseguire il provisioning. In alternativa, è possibile utilizzare le seguenti API per ottenere la lista dei valori CPU provvisori:

  • GetAutonomousContainerDatabase restituisce una lista di valori CPU di cui è possibile eseguire il provisioning che possono essere utilizzati per creare un nuovo Autonomous AI Database nell'Autonomous Container Database specificato. Per ulteriori informazioni, vedere GetAutonomousContainerDatabase.

  • GetAutonomousDatabase restituisce una lista di valori CPU di cui è possibile eseguire il provisioning che possono essere utilizzati per il ridimensionamento di un determinato database AI autonomo. Per ulteriori informazioni, vedere GetAutonomousDatabase.