Automatic Backups: The storage for backups is billed, per GB, in addition to your selected database storage.

For example, if backups are occupying 200 GB of storage you are billed for 200 GB of backup storage (in addition to the usage billed for your selected number of ECPUs and database storage). See ECPU Compute Model Billing Information for more detail about which SKUs are billed for backups.

Long-Term Backups: The storage for long-term backups is billed, per GB, as backup storage, in addition to your database storage.

For example, if automatic backups are currently occupying 200 GB and long-term backups are occupying 600 GB of storage, you are billed for 800 GB of backup storage, in addition to the usage billed for your selected ECPUs and database storage. See ECPU Compute Model Billing Information for more detail about which SKUs are billed for each workload type and backups.

Compute Auto-Scaling: When compute auto scaling is enabled, your database may use and you may be billed for additional ECPU consumption as needed by your workload, up to three times (3x) the number of base ECPUs, as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

• Your billed ECPU usage per hour while your database is running is based on the base number of ECPUs you selected for your database, plus any additional ECPU usage due to auto-scaling.

• A stopped Autonomous Database instance has zero ECPU usage.

• ECPU usage is measured each second, in units of whole ECPUs and averaged across an hour. If your database is running for less than an hour or auto-scales for only part of an hour, it is billed per second for the average ECPU consumption, over the base ECPUs, during that hour. The minimum ECPU consumption is one minute.

For example, if your database has ECPU count 4 with Compute auto scaling enabled:

• Assume in hour one your database is Available for the entire hour and ECPU utilization is below 4 ECPUs. Your database will be billed for 4 ECPUs.

• Assume in hour two your database is Available for the entire hour and ECPU utilization is below 4 ECPUs for 30 minutes, 50% of the hour, and auto scales to 8 ECPUs for 30 minutes (the other 50% of the hour). The usage for this period, for billing, is 6 ECPUs (based on the average per-second ECPU usage for hour two).

Storage Auto-Scaling:

• For storage usage below your reserved base storage, you are billed based on your base storage.

• After your allocated storage exceeds your reserved base storage, storage usage is billed based on your allocated storage rounded up to the nearest TB, in a given hour.

For example, if your reserved base storage is 4 TB, until your allocated storage exceeds 4 TB of storage, you are billed based on your base storage (4 TB). After you exceed 4 TB, storage is billed based on the allocated storage rounded up to the nearest TB, in a given hour. In this example, if the allocated storage grows over 4 TB in a given hour, say to 4.9 TB, you are billed for 5 TB of storage from that hour onward.

If you then delete 1 TB of data, your allocated storage remains at 4.9 TB and you are billed for 5 TB until you perform a shrink operation. When you perform a shrink operation, may be able to shrink /reduce your allocated storage back to 3.9 TB. After the shrink operation completes and your allocated storage (3.9 TB) is once again below your reserved base storage (4 TB), you will once again be billed for your reserved base storage of 4 TB. See Shrink Storage for more information.

Autonomous Data Guard Standby – Local (Same-Region)

Local Autonomous Data Guard peer databases incur the additional cost of the base ECPUs and the storage of the Primary database, including any auto-scaled storage usage, billed on the Primary database itself. Auto-scaled ECPUs of the Primary database are not billed for additionally on the local Autonomous Data Guard peer database. The number of base ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

For example, if you enable a local Autonomous Data Guard peer on a source database with:

• 2 (base) ECPUs with Compute auto-scaling enabled and are consuming about 4 ECPUs per hour
• 1 TB of (base) storage with storage auto-scaling, consuming a total of 2 TB of database storage

For the local Autonomous Data Guard peer you are billed for an additional 2 ECPUs (your base ECPU selection), plus an additional 2 TB of storage (that is, the same amount of storage reserved for the source Primary with auto-scale, on the Primary database).

When the Primary database is stopped, neither the primary nor the peer database is billed for ECPU.

Autonomous Data Guard Standby – Remote (Cross-Region)

Autonomous Data Guard cross-region peer databases incur the additional cost of the base ECPUs and twice (2x) the storage of the Primary database, including any auto-scaled storage usage, billed on the remote peer database. Auto-scaled ECPUs of the Primary are not billed for additionally on the remote peer database. The number of base ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

For example, if you enable a cross-region Autonomous Data Guard peer for a source database with:

• 2 (base) ECPUs with Compute auto-scaling enabled and are consuming about 4 ECPUs per hour
• 1 TB of (base) storage with storage auto-scaling, consuming a total of 2 TB of database storage

For the cross-region Autonomous Data Guard peer you are billed an additional 2 ECPUs (your base ECPU selection), plus 4 TB of storage (that is 2x the storage reserved for the source Primary with auto-scaling, billed on the remote peer database).

When the Primary database is stopped, neither the primary nor the peer database are billed for ECPU.

When the option Enable cross-region backup replication to disaster recovery peer is selected, you are billed for twice (2x) the backup storage size required for the replicated backups, billed to the remote standby.

Backup-Based Disaster Recovery – Local (Same-Region) Backup Copies There are no additional costs for local Backup-Based Disaster Recovery, other than the cost of storage for automatic backups.

Backup-Based Disaster Recovery – Remote (Cross-Region) Backup Copies Billing for a cross-region Backup-Based Disaster Recovery is twice (2x) the amount of backup storage required for the replicated cross-region backups, billed to the remote peer.

For example, if you enable a cross-region backup copy on a source database with:

• 2 (base) ECPUs
• 2 TB of database storage

If the backups replicated to the remote region take up 1.9 TB of storage, you will be billed for 3.8 TB of backup storage on the remote backup copy peer database.

When the option Enable cross-region backup replication to disaster recovery peer is selected, you are billed for twice (2x) the amount of backup storage size required for the additional replicated backups, billed to the remote peer. This billing is based on the number of days set for the backup retention on the Primary, as follows:

• When automatic backup retention is set to 7 days or greater, billing is based on the storage size for 7 days of replicated backups.
• When automatic backup retention is set to less than 7 days, billing is based on the storage size for the specified number of days of data that is replicated to the cross-region standby.

Refreshable Clone Local (Same-Region) Local refreshable clones have their own configurable ECPU selection, and so they are billed for ECPU based on the user-selected number of ECPUs, with or without auto scaling; they do not get billed additionally over the ECPU selection. The number of ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

Local refreshable clones are billed for the same amount of storage as their source database.

For example, if you create a 2 ECPU local refreshable clone from a source database with:

• 4 ECPUs
• 1 TB of storage with storage auto-scaling and consuming 2 TB of storage

For the local refreshable clone you will be billed for 2 ECPUs, that is, the refreshable clone's ECPU count value, and 2 TB of storage (that is, the storage reserved for the source database).

When you start or stop the source database, your actions on the source database do not affect the refreshable clone. A refreshable clone is started or stopped independently of the source database.

Refreshable Clone Remote (Cross-Region) Remote refreshable clones have their own configurable ECPU selection, and so they are billed for ECPU based on the user-selected ECPU (with or without auto scaling); they do not get billed additionally over the ECPU selection. The number of ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

Remote refreshable clones are billed for twice (2x) the amount of storage as their source database.

For example, if you create a 2 ECPU remote refreshable clone from a source database with:

• 4 ECPUs
• 1 TB of storage with storage auto-scaling and consuming 2 TB of storage

For the remote refreshable clone you are billed for 2 ECPUs (that is, the refreshable clone's ECPU selection) and 4 TB of storage (that is, 2x the storage reserved for the source database)

Starting or stopping the source database does not affect the refreshable clone - The refreshable clone can be started or stopped independently.

Snapshot Standby for Remote (Cross-Region) Disaster Recovery

Snapshot standby ECPU usage is billed based on the base ECPU count and any additional ECPU usage if compute auto-scaling is enabled. The number of base ECPUs is specified by the number of ECPUs, as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

Snapshot standby storage usage is billed based on the storage of the snapshot standby plus (1x) the storage of the source primary database.

For example, if you have a 2 ECPU and 3 TB snapshot standby from a source database with:

• 4 ECPUs
• 1 TB of storage with storage auto-scaling and consuming 2 TB of storage

Your snapshot standby will be billed for 2 ECPUs (that is, the snapshot standby's ECPU selection) and 3 TB + 2 TB = 5 TB of database storage (that is, the storage reserved on the snapshot standby + the storage reserved on its source database)

Elastic Pools: An elastic pool allows you to provision 4 times the ECPU count that you have as your pool size. For example, if you have a pool with pool size of 128 ECPUs, you can provision up to 512 ECPUs in this pool. In other words, when your pool size is 128 ECPUs, your pool capacity is four times the pool size (in this example, 512 ECPUs).

Databases that belong to a pool are not billed individually for compute. The compute billing for all the pool members and the leader happens through the leader. In other words, individual members of an elastic pool do not get billed for compute as long as they are part of the pool. This applies no matter what the workload type is for the pool member. For example, when a pool member with workload type Data Warehouse is added to a pool, it's compute usage is billed to the pool leader at the Transaction Processing compute usage rate. The storage billing, on the other hand, continues to be billed to individual Autonomous Database instances irrespective of them being part of a pool or not.

Let’s assume you have an elastic pool with pool size of 128 ECPUs. Given the pool size, the pool capacity is 512 ECPUs (pool capacity = 4x pool size). For this sample, here are some common billing questions and answers:

• What is the maximum number of Autonomous Database instances allowed in this pool? A total of 512 Autonomous Database instances with 1 ECPU each (elastic pool members or the leader can have an individual ECPU allocation as low as 1 ECPU).

• What happens if the aggregated ECPU utilization high watermark of the pool is greater than the pool size? If the aggregated ECPU utilization high watermark is less than or equal to the pool size in a given billing hour, the hourly charge is in the amount of the pool size. If the aggregated ECPU utilization high watermark is more than the pool size but less than or equal to the 2x pool size in a given billing hour, the hourly charge is in the amount of 2x pool size. If the aggregated ECPU utilization high watermark is more than 2x pool size in a given billing hour, the hourly charge is in the amount of 4x pool size.

  For example, let’s assume 512 Autonomous Database instances with 1 ECPU each are in an elastic pool with a pool size of 128 ECPUs. If the aggregated ECPU utilization high watermark of these databases is 100 ECPUs between 1pm-2pm, and 250 ECPUs between 2pm-3pm; then the billing is 128 ECPU hours between 1pm-2pm and 256 ECPU hours between 2pm-3pm.

See About Elastic Pool Billing for more information.

Undelete an Autonomous Database Instance

If you undelete an Autonomous Database instance, in the first hour after the undelete operation you are billed for the base CPU and Storage, including database storage and long term backups, for the total time when the database was deleted, as if the database was never deleted and was running.

For example, if you terminate an Autonomous Database instance with:

• 4 ECPU with Compute auto scaling enabled
• 2 TB Storage, with 100 GB of automatic backup storage and 20 GB of long-term backup storage

If after 5 hours you undelete the terminated instance, in the first hour after the undelete operation the billing includes the additional costs as if the database was never deleted and was running, including:

• 5.5 hours for the base 4 ECPUs
• 2 TB Storage
• 100 GB of automatic backup storage
• 20 GB of long-term backup storage