Informazioni sulla fatturazione Elastic Pool con Autonomous Data Guard abilitata
Un database primario Autonomous Data Guard può utilizzare uno standby locale o tra più aree che fa parte di un pool elastico, come leader o membro.
- Informazioni sulla fatturazione Elastic Pool con Autonomous Data Guard abilitata con un standby locale
Quando un leader del pool elastico o un membro del pool elastico abilita un standby Autonomous Data Guard locale, il database di standby fa parte del pool elastico e ti viene fatturato di conseguenza. - Informazioni sulla fatturazione Elastic Pool con un standby tra più aree
Descrive i dettagli della capacità di fatturazione ed elastica del pool per un standby Autonomous Data Guard tra più aree quando il standby tra più aree viene aggiunto a un pool elastico.
Argomento padre: Usa e gestisci pool elastici su Autonomous AI Database
Informazioni sulla fatturazione Elastic Pool con Autonomous Data Guard abilitata con uno standby locale
Quando un leader del pool elastico o un membro del pool elastico abilita un standby Autonomous Data Guard locale, il database di standby fa parte del pool elastico e ti viene fatturato di conseguenza.
Quando si aggiunge uno standby locale, un totale di due volte (2 x) l'allocazione ECPU del database primario viene conteggiata per la capacità del pool (1 x per il database primario e 1 x per lo standby).
Ad esempio, se si crea un pool elastico con una dimensione pool di 128 ECPU, con una capacità pool di 512 ECPU, l'aggiunta della seguente istanza di Autonomous AI Database utilizza la capacità del pool elastico:
-
1 istanza con 256 ECPU con Autonomous Data Guard locale abilitato, per un totale di 512 ECPU di allocazione dal pool.
Quando si utilizza questa istanza, se l'utilizzo di ECPU di picco è di 256 ECPU per un'ora di fatturazione specifica, l'utilizzo complessivo di ECPU di picco verrà segnalato come 256 ECPU per i database primari e 256 ECPU per i database di standby. La fatturazione per quell'ora sarà di 512 ECPU (dimensione pool 4x).
-
128 istanze con 2 ECPU ciascuna, con Autonomous Data Guard locale abilitato, per un totale di 512 ECPU di allocazione dal pool.
Quando si utilizzano tutte queste istanze, se l'utilizzo massimo di ECPU è di 256 ECPU, 128 *2 ECPU per istanza, per un'ora di fatturazione specifica, l'utilizzo complessivo di ECPU di picco sarà segnalato come 256 ECPU per i database primari e 256 ECPU per i database di standby. La fatturazione per quell'ora sarà di 512 ECPU (dimensione pool 4x).
In alcuni casi, il picco aggregato dei database di standby ADG locali nel pool elastico fa sì che il picco orario del pool elastico rientri nel livello di fatturazione successivo. Quando ciò si verifica, il picco aggregato dei membri del pool e il picco aggregato per gli standby ADG locali vengono calcolati separatamente per fornire un vantaggio in termini di costi.
Ad esempio, si crea un pool elastico con una dimensione pool di 128 ECPU, con una capacità pool di 512 ECPU. Il pool ha 3 membri (incluso il leader). DB1 è allocato a 20 ECPU e ha standby ADG locale, DB2 è allocato a 25 ECPU e ha standby ADG locale, e DB3 è allocato a 30 ECPU e ha standby ADG locale. Se il picco di utilizzo dell'ECPU di questi database è rispettivamente di 18 ECPU, 22 ECPU e 30 ECPU per un'ora di fatturazione specifica, il picco di utilizzo orario aggregato dell'ECPU sarà di 70 ECPU * 2 (dal momento che ciascuno dispone di uno standby ADG locale). In questo caso, invece di fatturare il pool elastico per 256 ECPU (dal picco salta a 140 ECPU a causa della presenza di standby ADG locali e 140 > 128), il pool orario l'addebito viene calcolato semplicemente esaminando i picchi di ECPU orari delle istanze primarie per determinare il livello di fatturazione del pool e aggiungendo i picchi aggregati derivanti da standby ADG locali configurati all'addebito del pool. In altre parole, l'addebito del pool per l'ora di fatturazione menzionata in questo esempio sarà di 198 ECPU (128 ECPU + 70 ECPU) invece di 256 ECPU.
In questo esempio si risparmiano 58 ECPU di costo di fatturazione quando il picco aggregato dei membri del pool e il picco aggregato per gli standby ADG locali vengono determinati separatamente.
Per ulteriori informazioni, vedere Abilita Autonomous Data Guard.
Informazioni sulla fatturazione Elastic Pool con un standby tra più aree
Descrive i dettagli della capacità del pool elastico e di fatturazione per uno standby Autonomous Data Guard tra più aree quando lo standby tra più aree viene aggiunto a un pool elastico.
I database in un pool elastico devono trovarsi nella stessa area. Se disponi di uno standby Autonomous Data Guard tra più aree, puoi posizionarlo in un pool elastico nell'area di standby.
-
Se aumenti le risorse di computazione del database primario, il pool elastico remoto in cui vengono eseguite le esecuzioni in standby tra più aree deve avere una capacità disponibile sufficiente per soddisfare l'aumento.
Per ulteriori informazioni sulla capacità elastica del pool, vedere Informazioni sui pool elastici.
-
Non è possibile arrestare un database primario quando il relativo standby Autonomous Data Guard tra più aree è un leader del pool. In questo caso, è necessario terminare il pool elastico prima di terminare il database primario."
Per ulteriori informazioni, vedere Terminare un pool elastico.
-
Un standby Autonomous Data Guard tra più aree che si trova in un pool elastico viene fatturato in base al picco di utilizzo del database primario. Ciò si applica indipendentemente dal fatto che il primario si trovi in un pool elastico.
Ad esempio, in una determinata ora di fatturazione da 1pm a 2pm in cui il picco di utilizzo del database primario è di 30 ECPU, il database di standby Autonomous Data Guard tra più aree mostra anche il picco di utilizzo di ECPU come 30 ECPU e questo utilizzo viene segnalato al leader del pool elastico dell'area remota.
-
Uno standby Autonomous Data Guard tra più aree che non si trova in un pool elastico, né come leader del pool né come membro del pool, viene fatturato come un normale standby tra più aree.
Per ulteriori informazioni, consulta la fatturazione delle funzionalità serverless di Oracle Autonomous AI Database.