Backup automatici: lo storage per i backup viene fatturato, per GB, in aggiunta allo storage di 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 storage del database). Per ulteriori informazioni sulle SKU fatturate per i backup, vedere Informazioni sulla fatturazione del modello di calcolo ECPU.

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

Ad esempio, se i backup automatici occupano attualmente 200 GB e i backup a lungo termine occupano 600 GB di storage, ti verranno addebitati 800 GB di storage di backup, oltre all'uso fatturato per le ECPU e lo storage del database selezionati. Per ulteriori informazioni sulle SKU fatturate per ciascun tipo di carico di lavoro e i backup, vedere Informazioni sulla fatturazione del modello di calcolo ECPU.

Scalatura automatica della computazione: quando la scala automatica della computazione è abilitata, è possibile che il database venga utilizzato e che venga fatturato il consumo aggiuntivo di ECPU 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 fatturato all'ora durante l'esecuzione del database si basa sul numero base di ECPU selezionate per il database, oltre a qualsiasi uso aggiuntivo di ECPU a causa della scala automatica.

• Un'istanza di Autonomous Database arrestata non utilizza ECPU.

• L'utilizzo dell'ECPU viene misurato ogni secondo, in unità di ECPU intere e calcolato in media su 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, sulle 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 la ridimensionamento automatico della computazione:

• Si supponga che il database sia disponibile per l'intera ora e che l'utilizzo dell'ECPU sia inferiore a 4 ECPU. Il costo per 4 ECPU verrà fatturato al database.

• Si supponga che il database sia disponibile per l'intera ora e che l'utilizzo dell'ECPU sia inferiore a 4 ECPU per 30 minuti, il 50% dell'ora e si adatti 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).

Scalatura automatica dello storage:

• Per l'utilizzo dello storage al di sotto dello storage di base riservato, viene 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, la fatturazione verrà eseguita in base allo storage di base (4 TB). Dopo aver superato i 4 TB, la fatturazione dello storage viene eseguita in base allo storage allocato arrotondato per eccesso al TB più vicino, in un'ora specifica. In questo esempio, se lo storage allocato cresce di oltre 4 TB in un'ora specifica, ad esempio fino a 4,9 TB, a partire da quell'ora in poi verrà fatturato il costo di 5 TB di storage.

Se poi elimini 1 TB di dati, lo storage allocato rimarrà a 4,9 TB e ti verranno addebitati 5 TB fino a quando non esegui un'operazione di riduzione. Quando esegui un'operazione di riduzione, potrebbe essere possibile ridurre/ridurre lo storage allocato a 3,9 TB. Al termine dell'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à nuovamente addebitato il costo per lo storage di base riservato di 4 TB. Per ulteriori informazioni, vedere Ridurre lo storage.

Autonomous Data Guard - Standby - 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 di storage con scala automatica, fatturato sul database primario stesso. Le ECPU con scala automatica del database primario non vengono fatturate in aggiunta al database peer Autonomous Data Guard locale. Il numero di ECPU di base viene specificato dal numero di ECPU, come mostrato nel conteggio di 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 (di base) con ridimensionamento automatico della computazione abilitato e che consumano circa 4 ECPU all'ora
• 1 TB di storage (di base) con ridimensionamento automatico dello storage, che utilizza un totale di 2 TB di storage del database

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

Quando il database primario viene arrestato, l'ECPU non verrà fatturato né al database primario né al database peer.

Autonomous Data Guard - Standby - 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 di storage con scala automatica, fatturato sul database peer remoto. Le ECPU con scala automatica del database primario non vengono fatturate per l'aggiunta nel database peer remoto. Il numero di ECPU di base viene specificato dal numero di ECPU, come mostrato nel conteggio di 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 (di base) con ridimensionamento automatico della computazione abilitato e che consumano circa 4 ECPU all'ora
• 1 TB di storage (di base) con ridimensionamento automatico dello storage, che utilizza un totale di 2 TB di storage del database

Per il peer Autonomous Data Guard tra più aree vengono fatturati 2 ECPU aggiuntive (selezione ECPU di base), oltre a 4 TB di storage (ovvero 2x lo storage riservato per il database primario di origine con scala automatica, fatturato sul database peer remoto).

Quando il database primario viene arrestato, l'ECPU non verrà fatturato né al database primario né al database peer.

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

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

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

Backup-Based Disaster Recovery - Copie di backup remote (cross-region) 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 di base
• 2 TB di storage del database

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

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

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

Copia aggiornabile locale (stessa area) Le copie aggiornabili locali dispongono di una propria selezione ECPU configurabile e pertanto vengono fatturate per l'ECPU in base al numero di ECPU selezionato dall'utente, con o senza scala automatica. Non vengono fatturate in modo aggiuntivo tramite la selezione dell'ECPU. Il numero di ECPU viene specificato dal numero di ECPU, come mostrato nel conteggio di 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 utilizzo di 2 TB di storage

Per la copia aggiornabile locale verranno fatturati 2 ECPU, ovvero il valore Conteggio ECPU della copia aggiornabile e 2 TB di storage, ovvero lo storage riservato per il database di origine.

Quando si avvia o 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 (cross-region) Le copie aggiornabili remote dispongono di una 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 tramite la selezione dell'ECPU. Il numero di ECPU viene specificato dal numero di ECPU, come mostrato nel conteggio di ECPU nella console di Oracle Cloud Infrastructure.

Le copie aggiornabili remote vengono fatturate per il doppio (2 volte) della quantità di storage come 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 utilizzo di 2 TB di storage

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

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

Snapshot in standby per disaster recovery remoto (tra più aree)

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

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

Ad esempio, se si dispone di un database di 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 utilizzo di 2 TB di storage

Lo standby snapshot verrà fatturato per 2 ECPU (ovvero, la selezione dell'ECPU dello standby snapshot) e 3 TB + 2 TB = 5 TB di storage del database (ovvero, 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 del conteggio di ECPU di cui si dispone come dimensione del pool. Ad esempio, se si dispone di un pool con dimensioni di 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 la computazione. La fatturazione della computazione per tutti i membri del pool e il leader avviene tramite il leader. In altri termini, i singoli membri di un pool elastico non vengono fatturati per la computazione finché fanno 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 il tipo di carico di lavoro Data Warehouse viene aggiunto a un pool, il relativo utilizzo della computazione viene fatturato al leader del pool al tasso di utilizzo della computazione Elaborazione transazione. 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.

Supponiamo di avere un pool elastico con dimensioni del pool di 128 ECPU. Data la dimensione del pool, la capacità del pool è di 512 ECPU (capacità pool = 4x dimensione del pool). Per questo esempio, di seguito sono riportate alcune domande e risposte più comuni sulla fatturazione.

• 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 un'allocazione ECPU individuale fino a 1 ECPU).

• Che cosa accade se la filigrana elevata di utilizzo ECPU aggregata del pool è maggiore della dimensione del pool? Se il watermark massimo di utilizzo ECPU aggregato è minore o uguale alla dimensione del pool in un'ora di fatturazione specificata, l'addebito orario sarà pari 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 di 2 volte in un'ora di fatturazione specificata, l'addebito orario sarà pari a 2 volte la dimensione del pool. Se la filigrana elevata di utilizzo dell'ECPU aggregata è superiore a 2 volte la dimensione del pool in un'ora di fatturazione specificata, l'addebito orario è pari a 4 volte la dimensione del pool.

  Si supponga, ad esempio, che 512 istanze di Autonomous Database con 1 ECPU si trovino in un pool elastico con una dimensione del pool di 128 ECPU. Se la filigrana elevata di utilizzo dell'ECPU aggregata di questi database è di 100 ECPU tra 1pm-2pm e 250 ECPU tra 2pm-3pm, la fatturazione è di 128 ECPU ore tra 1pm-2pm e 256 ECPU ore tra 2pm-3pm.

Per ulteriori informazioni, vedere Informazioni sulla fatturazione di Elastic Pool.

Annulla eliminazione di un'istanza di Autonomous Database

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

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

• 4 ECPU con la ridimensionamento automatico della computazione abilitata
• 2 TB di storage, 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 terminata, 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
• 2 TB di storage
• 100 GB di storage di backup automatico
• 20 GB di storage di backup a lungo termine