Gestione della computazione in Autonomous Database on Dedicated Exadata Infrastructure

Autonomous Database sull'infrastruttura Exadata dedicata offre due modelli di computazione durante la configurazione delle risorse di Autonomous Database. Sono:

  • ECPU: un'ECPU è una misura astratta delle risorse di calcolo. Le ECPU si basano sul numero di memorie centrali allocate in modo elastico da un pool di server di calcolo e storage. Sono necessarie almeno 2 ECPU per eseguire il provisioning di un Autonomous Database.

    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.

    È possibile creare istanze di Autonomous Database per sviluppatori su container database basati su ECPU. Sono Autonomous Database gratuiti che gli sviluppatori possono utilizzare per creare e testare nuove applicazioni. Per ulteriori dettagli, consulta Autonomous Database per sviluppatori.

  • 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

    La OCPU è una metrica di fatturazione precedente ed è stata ritirata per Autonomous Database sull'infrastruttura Exadata dedicata. Oracle consiglia di utilizzare le ECPU per tutte le distribuzioni Autonomous Database nuove ed esistenti. Per ulteriori informazioni, vedere Documento 2998755.1 del Supporto Oracle.

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

Argomenti correlati

Gestione computazione

Le istanze di Autonomous Database vengono distribuite in un cluster VM Autonomous Exadata (AVMC) e in uno dei relativi 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 CPU totali disponibili per i relativi Autonomous Database. Quando si creano più AVMC, ogni AVMC può avere il proprio valore per il totale delle CPU.

Più cluster VM Autonomous Exadata non sono disponibili in alcuna distribuzione Oracle Public Cloud delle risorse dell'infrastruttura Exadata (EI) create prima dell'avvio della funzione Autonomous Database con più VM. Per le risorse dell'infrastruttura Exadata di generazione X8M e successive create dopo l'avvio di più funzioni AVMC, ogni AVMC viene creato con un nodo cluster per ciascuno dei server della forma di sistema Exadata scelta. Per informazioni su come vincolare queste CPU totali tra diversi gruppi di utenti, vedere In che modo le quote del 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 è definito CPU disponibili. A livello di risorsa AVMC, le CPU disponibili saranno uguali al totale delle CPU finché 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 dell'AVMC. Pertanto, le CPU disponibili a livello di risorsa AVMC si riducono di conseguenza. Quando crei il primo Autonomous Database 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 di Autonomous Database 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 si ridimensionano manualmente le CPU di un Autonomous Database, le CPU vengono consumate dalle CPU disponibili a livello AVMC padre e il relativo valore cambia di conseguenza.

Quando crei un Autonomous 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. Puoi modificare la percentuale di CPU riservate tra i nodi impostandola su 0% o 25% durante il provisioning di un ACD. Per istruzioni, consulta la sezione relativa all'assegnazione del failover dei nodi in Crea un Autonomous Container Database. Queste CPU aggiuntive non sono incluse nella fatturazione.

Quando è in esecuzione un Autonomous Database, viene fatturato il numero di CPU attualmente allocate al database, specificato alla creazione iniziale o in un secondo momento da un'operazione di ridimensionamento manuale. Inoltre, se la scala automatica è abilitata per il database, viene fatturato ogni secondo per eventuali CPU aggiuntive utilizzate dal database come risultato dello scale-up automatico. Per ulteriori informazioni sulle modalità di misurazione e calcolo della fatturazione, vedere Dettagli fatturazione CPU.

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

Quando un Autonomous Database viene arrestato o sottoposto a scale down, il numero di CPU allocate ad esso non viene immediatamente restituito alle CPU disponibili al livello AVMC padre per la distribuzione complessiva. Le CPU 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 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 Database di utilizzare fino a tre volte più risorse CPU e I/O rispetto al conteggio CPU allocato. In caso di overprovisioning della CPU, se tre volte il conteggio della CPU restituisce un valore inferiore a 1, verrà arrotondato al numero intero successivo. Il overprovisioning della CPU è supportato solo con le OCPU. Vedere Provisioning in eccesso della CPU per ulteriori dettagli.

Per garantire che nessun singolo Autonomous Database possa eseguire lo scale-up automatico per consumare tutte le CPU disponibili nel pool per la distribuzione complessiva, Oracle Autonomous Database on Dedicated Exadata Infrastructure utilizza l'Autonomous Container Database come controllo limitante.

Durante il provisioning di un Autonomous Database abilitato per il ridimensionamento automatico in un ACD, se le CPU disponibili in tale ACD sono inferiori al valore CPU 3X del nuovo database, le CPU aggiuntive verranno riservate in tale ACD. Queste CPU sono denominate CPU riservate. Le CPU riservate garantiscono che le CPU disponibili a livello ACD siano sempre maggiori o uguali al valore della CPU 3x del database abilitato per il ridimensionamento automatico più grande in tale ACD. Queste CPU riservate possono comunque essere utilizzate per creare o ridimensionare manualmente gli Autonomous Database in questo ACD.

Quando si esegue automaticamente lo scale-up di un Autonomous Database, Oracle Autonomous Database on Dedicated Exadata Infrastructure cerca le CPU inattive nel relativo container database padre. Se sono disponibili CPU inattive, viene eseguito lo scale up di Autonomous Database. In caso contrario, non lo è. I database hanno intrinsecamente un sacco di tempo di inattività, quindi la scalabilità automatica è 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 Database proviene da un altro Autonomous Database in esecuzione che è leggermente caricato e quindi non utilizza tutte le CPU allocate, Oracle Autonomous Database on Dedicated Exadata Infrastructure ridimensiona automaticamente il database a scala automatica in caso di aumento del carico sull'altro database e ne richiede il ripristino della CPU allocata.

Considera l'esempio di un Autonomous Container Database che ospita quattro Autonomous Database a 4 CPU in esecuzione, tutti con ridimensionamento automatico abilitato. Il conteggio delle CPU disponibili per il container database a scopo di scala automatica è 12. Se uno di questi database deve essere ridimensionato automaticamente oltre 4 CPU a causa dell'aumento del carico, Oracle Autonomous Database on Dedicated Exadata Infrastructure 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 almeno 16 CPU 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 Database a 2 CPU in esecuzione, tutti con ridimensionamento automatico abilitato e un Autonomous Database a 8 CPU arrestate. Il conteggio delle CPU disponibili per il container database a scopo di scala automatica è di nuovo pari a 16. Se uno dei database in esecuzione deve essere ridimensionato automaticamente a causa di un aumento del carico oltre 2 CPU, Oracle Autonomous Database on Dedicated Exadata Infrastructure può eseguire l'operazione utilizzando CPU allocate per il database a 8 CPU arrestato. In questo esempio, i quattro database in esecuzione possono consumare fino a un totale di 8 CPU aggiuntive contemporaneamente senza consumare le rispettive CPU allocate. Il costo di fatturazione di questo esempio è di sole 8 CPU al minimo perché solo i quattro database 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 Database, la capacità di Oracle Autonomous Database on Dedicated Exadata Infrastructure di 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 relativa alle quote del compartimento di Oracle Cloud Infrastructure per limitare ulteriormente, in base al compartimento, il numero di CPU disponibili per creare, ridimensionare manualmente e automaticamente i database autonomi di ogni tipo di carico di lavoro (Data Warehouse o 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 illustrati dettagli dettagliati su come Oracle Cloud Infrastructure posiziona gli Autonomous Database nei nodi del cluster VM e sulle conseguenze di tale posizionamento sul ridimensionamento automatico e sull'elaborazione parallela.

I seguenti attributi determinano quando e come un Autonomous Database viene posizionato su più nodi:

  • Soglia di divisione: il valore della CPU oltre il quale Oracle Cloud Infrastructure apre un Autonomous 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 conteggi dei nodi CPU al di sotto del valore predefinito, l'impostazione predefinita viene sostituita 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).

    Gli Autonomous Database 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é la dimensione di 40 è inferiore a 64, qualsiasi Autonomous Database con un requisito di CPU maggiore di 40 verrà diviso e aperto su più nodi, consentendo le richieste DML su 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 Autonomous Database 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 divisione su un valore molto più alto di quello predefinito, ad esempio 80 ECPU, in un AVMC con due nodi e 40 ECPU. Qualsiasi Autonomous Database 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 Autonomous Database, il nuovo valore della CPU verrà applicato al modello Split esistente. In altre parole, se il nuovo valore è inferiore alla soglia di divisione, verrà aperto su un nodo e se il valore è maggiore della soglia di divisione, verrà aperto su più nodi.

  • Affinità distribuzione: determina il numero di nodi su cui verrà aperto un Autonomous 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 il database Soglia frazionata impostato su 64. La creazione di un Autonomous Database con un requisito ECPU di 120 suddividerà e aprirà il database su più nodi come 120 maggiore di 64 (Soglia frazionata).

    • 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, anche l'assegnazione del failover dei nodi può essere controllata assicurando che un database sia suddiviso su più di 2 nodi, utilizzando la soglia di divisione e l'affinità di distribuzione.Si consideri uno scenario in cui un Autonomous Database è suddiviso in 4 nodi. Rimuovendo un nodo alla volta in modalità continuativa mentre è in corso un'attività di manutenzione, hai sempre 3 nodi ancora attivi e occupati del traffico, mantenendo le tue prestazioni in modo efficace al 75%, piuttosto che al solito 50%. Con i cluster più grandi, puoi aumentare ulteriormente questa riserva, ad esempio una riserva dell'87,5% su un cluster a 8 nodi.
Il modo in cui l'allocazione della CPU di Autonomous Database viene distribuita tra i nodi del 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 ciascun nodo; non è possibile utilizzare tutti i valori delle CPU disponibili per eseguire il provisioning o la scalabilità degli Autonomous Database. Si supponga, ad esempio, di disporre di 20 CPU a livello di AVMC. Non è possibile utilizzare tutti i valori compresi tra 1 e 20 CPU per eseguire il provisioning o la scalabilità di Autonomous Database a seconda della disponibilità delle risorse a livello di nodo. La lista di valori della CPU che possono essere utilizzati per eseguire il provisioning o la scalabilità di un Autonomous Database è denominata CPU con provisioning consentito.

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

  • GetAutonomousContainerDatabase restituisce una lista di valori CPU di cui è possibile eseguire il provisioning che possono essere utilizzati per creare un nuovo Autonomous Database nell'Autonomous Container Database specificato. Per ulteriori dettagli, 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 Autonomous Database. Per ulteriori dettagli, vedere GetAutonomousDatabase.