Fatturazione delle funzionalità di Oracle Autonomous Database Serverless

Backup automatici: lo storage per i backup viene fatturato, per GB, oltre allo storage del database selezionato.

Ad esempio, se i backup occupano 200 GB di storage, ti verranno addebitati 200 GB di storage di backup (oltre all'uso fatturato per il numero selezionato di ECPU e lo storage del database). Per ulteriori informazioni sulle SKU fatturate per i backup, vedere Informazioni di fatturazione del modello di computazione ECPU.

Backup a lungo termine: lo storage per i backup a lungo termine viene fatturato, per GB, come storage di backup, oltre allo storage del database.

Ad esempio, se i backup automatici occupano attualmente 200 GB e i backup a lungo termine occupano 600 GB di storage, verrà fatturato il costo di 800 GB di storage di backup, oltre all'uso fatturato per le ECPU e lo storage di database selezionati. Vedere ECPU Compute Model Billing Information per ulteriori dettagli su quali SKU vengono fatturate per ogni tipo di carico di lavoro e backup.

Scalabilità automatica computazione: quando la scala automatica di computazione è abilitata, il database può utilizzarla e potrebbe essere addebitato un consumo di ECPU aggiuntivo in base alle esigenze del carico di lavoro, fino a tre volte (3x) il numero di ECPU di base, come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

• L'uso di ECPU fatturate all'ora mentre il database è in esecuzione si basa sul numero base di ECPU selezionate per il database, oltre a qualsiasi uso aggiuntivo di ECPU dovuto al ridimensionamento automatico.

• Un'istanza di Autonomous Database arrestata non prevede l'uso di ECPU.

• L'utilizzo di ECPU viene misurato ogni secondo, in unità di ECPU intere e viene calcolato in media in un'ora. Se il database è in esecuzione per meno di un'ora o si ridimensiona automaticamente solo per una parte di un'ora, viene fatturato al secondo per il consumo medio di ECPU, nelle ECPU di base, durante quell'ora. Il consumo minimo di ECPU è di un minuto.

Ad esempio, se nel database è abilitato il conteggio ECPU 4 con Scalabilità automatica computazione:

• Si supponga che nell'ora un database sia disponibile per l'intera ora e che l'utilizzo di ECPU sia inferiore a 4 ECPU. Il database verrà fatturato per 4 ECPU.

• Si supponga che nell'ora due il database sia disponibile per l'intera ora e che l'utilizzo di ECPU sia inferiore a 4 ECPU per 30 minuti, il 50% dell'ora e si ridimensioni automaticamente a 8 ECPU per 30 minuti (l'altro 50% dell'ora). L'uso per questo periodo, per la fatturazione, è di 6 ECPU (in base all'uso medio di ECPU al secondo per l'ora due).

Scalabilità automatica storage:

• Per l'uso dello storage al di sotto dello storage di base riservato, l'importo verrà fatturato in base allo storage di base.

• Dopo che lo storage allocato ha superato lo storage di base riservato, l'uso dello storage viene fatturato in base allo storage allocato, arrotondato per eccesso al TB più vicino, in un'ora specifica.

Ad esempio, se lo storage di base riservato è di 4 TB, fino a quando lo storage allocato non supera i 4 TB di storage, ti verrà addebitato il costo in base allo storage di base (4 TB). Dopo aver superato i 4 TB, lo storage viene fatturato in base allo storage allocato arrotondato per eccesso ai TB più vicini, in un'ora specifica. In questo esempio, se lo storage allocato cresce di oltre 4 TB in un'ora specifica, ad esempio 4,9 TB, verrà fatturato il costo di 5 TB di storage da quell'ora in poi.

Se poi elimini 1 TB di dati, lo storage allocato rimane a 4,9 TB e ti verranno addebitati 5 TB fino a quando non esegui un'operazione di riduzione. Quando si esegue un'operazione di riduzione, potrebbe essere possibile ridurre/ridurre lo storage allocato a 3,9 TB. Una volta completata l'operazione di riduzione e dopo che lo storage allocato (3,9 TB) sarà di nuovo al di sotto dello storage di base riservato (4 TB), ti verrà addebitato nuovamente il costo per lo storage di base riservato di 4 TB. Per ulteriori informazioni, vedere Riduci memoria.

Standby Autonomous Data Guard - Locale (stessa area)

I database peer Autonomous Data Guard locali comportano il costo aggiuntivo delle ECPU di base e dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database primario stesso. Le ECPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer Autonomous Data Guard locale. Il numero di ECPU di base è specificato dal numero di ECPU, come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

Ad esempio, se si abilita un peer Autonomous Data Guard locale in un database di origine con:

• 2 ECPU (base) con la scala automatica del calcolo abilitata e che consumano circa 4 ECPU all'ora
• 1 TB di storage (base) con scalabilità automatica dello storage, consumando un totale di 2 TB di storage del database

Per il peer Autonomous Data Guard locale, ti verranno addebitate 2 ECPU aggiuntive (la selezione di ECPU di base) e 2 TB di storage aggiuntivi (ovvero la stessa quantità di storage riservata per il primario di origine con scala automatica, nel database primario).

Quando il database primario viene arrestato, non viene fatturato né il database primario né il database peer per ECPU.

Standby Autonomous Data Guard - Remoto (tra più aree)

I database peer tra più aree di Autonomous Data Guard comportano il costo aggiuntivo delle ECPU di base e il doppio (2x) dello storage del database primario, incluso qualsiasi uso dello storage con scala automatica, fatturato sul database peer remoto. Le ECPU con scala automatica del database primario non vengono fatturate in modo aggiuntivo nel database peer remoto. Il numero di ECPU di base è specificato dal numero di ECPU, come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

Ad esempio, se si abilita un peer Autonomous Data Guard tra più aree per un database di origine con:

• 2 ECPU (base) con la scala automatica del calcolo abilitata e che consumano circa 4 ECPU all'ora
• 1 TB di storage (base) con scalabilità automatica dello storage, consumando un totale di 2 TB di storage del database

Per il peer Autonomous Data Guard tra più aree, ti verranno addebitate 2 ECPU aggiuntive (la selezione di ECPU di base) e 4 TB di storage (ossia 2x lo storage riservato per il primario di origine con scala automatica, fatturato sul database peer remoto).

Quando il database primario viene arrestato, non viene fatturato né il database primario né quello peer per l'ECPU.

Quando l'opzione Abilita replica di backup tra più aree al peer di disaster recovery è selezionata, viene fatturato il doppio (2x) della dimensione di storage di backup richiesta per i backup replicati, fatturata allo standby remoto.

Quando un peer tra più aree opera come standby snapshot, l'uso della CPU in standby snapshot viene fatturato in base al conteggio di CPU di base e a qualsiasi uso aggiuntivo della CPU se la scala automatica di computazione è abilitata. Il numero di CPU di base viene specificato dal numero di ECPU, come mostrato nel campo Conteggio ECPU nella console di Oracle Cloud Infrastructure.

Backup-Based Disaster Recovery - Copie di backup locali (della stessa area) Non sono previsti costi aggiuntivi per il disaster recovery locale basato su backup, oltre ai costi di storage per i backup automatici.

Backup-Based Disaster Recovery - Copie di backup remoto (tra più aree) La fatturazione per un disaster recovery basato su backup tra più aree è il doppio (2x) della quantità di storage di backup necessaria per i backup tra più aree replicati, fatturata al peer remoto.

Ad esempio, se si abilita una copia di backup tra più aree in un database di origine con:

• 2 ECPU (base)
• 2 TB di storage del database

Se i backup replicati nell'area remota occupano 1,9 TB di storage, ti verrà fatturato il costo di 3,8 TB di storage di backup nel database peer della copia di backup remota.

Quando l'opzione Abilita replica di backup tra più aree al peer di disaster recovery è selezionata, viene fatturato il doppio (2x) della dimensione di storage di backup richiesta per i backup replicati aggiuntivi, fatturati al peer remoto. Questa fatturazione si basa sul numero di giorni impostato per la conservazione dei backup nel database primario, come indicato di seguito.

• Quando la conservazione automatica dei backup è impostata su 7 giorni o più, la fatturazione si basa sulla dimensione dello storage per 7 giorni di backup replicati.
• Quando la conservazione automatica dei backup è impostata su meno di 7 giorni, la fatturazione si basa sulla dimensione dello storage per il numero specificato di giorni di dati replicati nel database di standby tra più aree.

Clone locale aggiornabile (stessa area) Le copie locali aggiornabili hanno la propria selezione ECPU configurabile e pertanto vengono fatturate per l'ECPU in base al numero selezionato dall'utente di ECPU, con o senza scala automatica; non vengono fatturate in aggiunta durante la selezione dell'ECPU. Il numero di ECPU è specificato dal numero di ECPU come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

Le copie aggiornabili locali vengono fatturate per la stessa quantità di storage del database di origine.

Ad esempio, se si crea una copia aggiornabile locale di 2 ECPU da un database di origine con:

• 4 ECPU
• 1 TB di storage con scalabilità automatica dello storage e consumo di 2 TB di storage

Per la copia aggiornabile locale, verrà fatturato il costo di 2 ECPU, ovvero il valore di Conteggio ECPU della copia aggiornabile, e di 2 TB di storage, ovvero lo storage riservato per il database di origine.

Quando si avvia o si arresta il database di origine, le azioni eseguite sul database di origine non influiscono sulla copia aggiornabile. Una copia aggiornabile viene avviata o arrestata indipendentemente dal database di origine.

Copia remota aggiornabile (tra più aree) Le copie aggiornabili remote hanno la propria selezione ECPU configurabile e pertanto vengono fatturate per l'ECPU in base all'ECPU selezionata dall'utente (con o senza scala automatica). Non vengono fatturate in modo aggiuntivo durante la selezione dell'ECPU. Il numero di ECPU è specificato dal numero di ECPU come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

Le copie aggiornabili remote vengono fatturate per il doppio (2x) della quantità di storage del database di origine.

Ad esempio, se si crea una copia aggiornabile remota di 2 ECPU da un database di origine con:

• 4 ECPU
• 1 TB di storage con scalabilità automatica dello storage e consumo di 2 TB di storage

Per la copia aggiornabile remota, vengono fatturate 2 ECPU (ovvero la selezione di ECPU della copia aggiornabile) e 4 TB di storage (ossia, 2x lo storage riservato per il database di origine)

L'avvio o l'arresto del database di origine non influisce sulla copia aggiornabile. La copia aggiornabile può essere avviata o arrestata in modo indipendente.

Standby snapshot per disaster recovery remoto (tra più aree)

L'uso dell'ECPU di standby snapshot viene fatturato in base al conteggio di ECPU di base e a qualsiasi uso aggiuntivo di ECPU se la scala automatica di computazione è abilitata. Il numero di ECPU di base è specificato dal numero di ECPU, come mostrato nel conteggio ECPU nella console di Oracle Cloud Infrastructure.

L'uso dello storage di standby snapshot viene fatturato in base allo storage dello standby snapshot più (1x) lo storage del database primario di origine.

Ad esempio, se si dispone di uno standby snapshot da 2 ECPU e 3 TB da un database di origine con:

• 4 ECPU
• 1 TB di storage con scalabilità automatica dello storage e consumo di 2 TB di storage

Lo standby snapshot verrà fatturato per 2 ECPU (ossia, la selezione di ECPU dello standby snapshot) e 3 TB + 2 TB = 5 TB di storage del database (ossia, lo storage riservato nello standby snapshot + lo storage riservato nel relativo database di origine)

Pool elastici: un pool elastico consente di eseguire il provisioning 4 volte il conteggio di ECPU di cui si dispone come dimensione del pool. Ad esempio, se si dispone di un pool con dimensioni pool pari a 128 ECPU, è possibile eseguire il provisioning di un massimo di 512 ECPU in questo pool. In altre parole, quando la dimensione del pool è di 128 ECPU, la capacità del pool è quattro volte superiore alla dimensione del pool (in questo esempio, 512 ECPU).

I database che appartengono a un pool non vengono fatturati singolarmente per il calcolo. La fatturazione di calcolo per tutti i membri del pool e il leader avviene tramite il leader. In altre parole, i singoli membri di un pool elastico non vengono fatturati per il calcolo purché facciano parte del pool. Ciò si applica indipendentemente dal tipo di carico di lavoro per il membro del pool. Ad esempio, quando un membro del pool con tipo di carico di lavoro Data Warehouse viene aggiunto a un pool, l'uso della computazione viene fatturato al leader del pool in base alla tariffa di utilizzo della computazione Elaborazione delle transazioni. La fatturazione dello storage, invece, continua a essere fatturata alle singole istanze di Autonomous Database, indipendentemente dal fatto che facciano parte o meno di un pool.

Si supponga di disporre di un pool elastico con una dimensione pool di 128 ECPU. Data la dimensione del pool, la capacità del pool è di 512 ECPU (capacità pool = dimensione pool 4x). Per questo esempio, ecco alcune domande e risposte di fatturazione comuni:

• Qual è il numero massimo di istanze di Autonomous Database consentite in questo pool? Un totale di 512 istanze di Autonomous Database con 1 ECPU ciascuna (i membri del pool elastico o il leader possono avere una singola allocazione ECPU a partire da 1 ECPU).

• Cosa succede se il watermark elevato di utilizzo ECPU aggregato del pool è maggiore della dimensione del pool? Se il watermark massimo di utilizzo ECPU aggregato è inferiore o uguale alla dimensione del pool in un'ora di fatturazione specificata, l'addebito orario corrisponde alla dimensione del pool. Se il watermark massimo di utilizzo ECPU aggregato è maggiore della dimensione del pool, ma minore o uguale alla dimensione del pool 2x in un'ora di fatturazione specificata, l'addebito orario è pari alla dimensione del pool 2x. Se il watermark elevato di utilizzo ECPU aggregato è maggiore della dimensione del pool 2x in un'ora di fatturazione specificata, l'addebito orario corrisponde alla dimensione del pool 4x.

  Ad esempio, supponiamo che 512 istanze di Autonomous Database con 1 ECPU ciascuna si trovino in un pool elastico con una dimensione pool di 128 ECPU. Se l'utilizzo aggregato di ECPU ad alta filigrana di questi database è di 100 ECPU tra 1pm-2pm e 250 ECPU tra 2pm-3pm; la fatturazione è di 128 ore di ECPU tra 1pm-2pm e 256 ore di ECPU tra 2pm-3pm.

Per ulteriori informazioni, vedere Informazioni sulla fatturazione Elastic Pool.

Annulla l'eliminazione di un'istanza di Autonomous Database

Se si annulla l'eliminazione di un'istanza di Autonomous Database, nella prima ora dopo l'operazione di annullamento dell'eliminazione verrà fatturato il costo per la CPU e lo storage di base, inclusi lo storage del database e i backup a lungo termine, per il tempo totale di eliminazione del database, come se il database non fosse mai stato eliminato ed fosse in esecuzione.

Ad esempio, se interrompi un'istanza di Autonomous Database con:

• 4 ECPU con la scala automatica della computazione abilitata
• Storage da 2 TB, con 100 GB di storage di backup automatico e 20 GB di storage di backup a lungo termine

Se dopo 5 ore e 30 minuti si annulla l'eliminazione dell'istanza arrestata, nella prima ora dopo l'operazione di annullamento dell'eliminazione la fatturazione include i costi aggiuntivi come se il database non fosse mai stato eliminato e fosse in esecuzione, tra cui:

• 5 ore e 30 minuti per le 4 ECPU di base
• Storage da 2 TB
• 100 GB di storage di backup automatico
• 20 GB di storage di backup a lungo termine

Upgrade pianificato a 23ai

Quando si pianifica un upgrade per un'istanza di Autonomous Database, per il tipo di upgrade sono disponibili due opzioni:

• Pianificazione disponibile meno recente: questa opzione di aggiornamento non comporta costi aggiuntivi.

• Pianificazione futura: quando si pianifica un upgrade con una pianificazione futura, vengono immediatamente disattivate risorse aggiuntive per il database e le copie o gli standby collegati, che vengono fatturati come indicato di seguito.

  • Ti verrà fatturato il costo aggiuntivo delle ECPU di base e dello storage dell'istanza di Autonomous Database di origine.

  • Viene fatturato il costo aggiuntivo delle ECPU di base e dello storage del database per ogni copia aggiornabile locale e remota collegata.

  • Ti verrà addebitato il costo aggiuntivo delle ECPU di base e dello storage del database per ogni database di standby Autonomous Data Guard locale e remoto.

  Ad esempio, se si sceglie di eseguire l'upgrade del database e si seleziona Pianificazione futura con una pianificazione 30 giorni in futuro, su un'istanza di Autonomous Database con la configurazione seguente:

  • 4 ECPU con Scalabilità automatica computazione abilitata

  • 1 TB di storage

  • 1 copia aggiornabile

  • 1 standby Autonomous Data Guard remoto

  Il costo verrà fatturato come indicato di seguito.

  Due volte (2x) per le ECPU di base e 2x per lo storage del database per 30 giorni fino al completamento dell'upgrade:

  4 + 4 = 8 ECPU

  1 + 1 = storage del database da 2 TB

  Inoltre, ti verranno addebitate due volte (2x) le ECPU di base e lo storage sulla copia aggiornabile collegata e sullo standby Autonomous Data Guard remoto, per 30 giorni fino al completamento dell'upgrade.

  Per gli aggiornamenti che coinvolgono membri del pool elastico o un leader del pool elastico, con un upgrade di tipo Pianificazione futura:

  • Fatturazione per un membro o il leader, se uno pianifica un upgrade: l'uso della CPU di base del database viene fatturato 2x all'OCID del database leader.

  • La fatturazione per l'uso dello storage per un membro con un upgrade pianificato viene fatturata a 2x direttamente all'OCID del database del membro, separato da eventuali importi di storage segnalati per la fatturazione sul leader del pool.

  • L'uso dello storage per il leader con un upgrade pianificato viene fatturato 2x direttamente all'OCID del database leader.

  Non sono previsti addebiti per l'annullamento di un aggiornamento pianificato. Tuttavia, i costi fatturati tra il momento in cui è stato pianificato l'upgrade e il momento in cui è stato annullato l'upgrade rimangono.