Use Auto Scaling

When you create an Autonomous Database instance, by default compute auto scaling is enabled and storage auto scaling is disabled. You can manage auto scaling from the Oracle Cloud Infrastructure Console to enable or disable compute auto scaling or storage auto scaling.

Compute Auto Scaling

With compute auto scaling enabled the database can use up to three times more CPU and IO resources than specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count or OCPU count field on the Oracle Cloud Infrastructure Console.

When auto scaling is enabled, if your workload requires additional CPU and IO resources, the database automatically uses the resources without any manual intervention required. For example:

  • In the ECPU compute model, when the ECPU count is 512, this allows the database to use up to 512 x 3 ECPUs (1536 ECPUs) when auto scaling is enabled.

    To see the average number of ECPUs used during an hour you can use the "Number of ECPUs allocated" graph on the Overview tab on the Database Dashboard card in Database Actions. See Database Dashboard Overview for more information.

  • In the OCPU compute model, when the OCPU count is 128, this allows the database to use up to 128 x 3 OCPUs (384 OCPUs) when auto scaling enabled.

    To see the average number of OCPUs used during an hour you can use the "Number of OCPUs allocated" graph on the Overview tab on the Database Dashboard card in Database Actions. See Database Dashboard Overview for more information.

Enabling compute auto scaling does not change the concurrency and parallelism settings for the predefined services. See Manage Concurrency and Priorities on Autonomous Database for more information.

Note:

Your license type determines the ECPU count maximum. For example, if your license type is Bring your own license (BYOL) with Oracle Database Standard Edition (SE), the ECPU count maximum is 32.For this license type the maximum allowed value for ECPU count is 32. With compute auto scaling enabled you can use up to ECPU count x 3 ECPUs. This license restricts the number of ECPUs you can use to a maximum of 32 ECPUs, with or without compute auto scaling enabled.

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

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

  • A stopped Autonomous Database instance has zero CPU usage.

  • CPU usage is measured each second, in units of whole CPUs 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 will be billed per second for the average CPU consumption during that hour. The minimum CPU 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 CPU utilization is below 4 ECPUs. Your database will be billed for the usage of 4 ECPUs.

  • Assume in hour two your database is Available for the entire hour and CPU 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).

See Add CPU or Storage Resources or Enable Auto Scaling for the steps to enable compute auto scaling.

Storage Auto Scaling

You can provision or scale up your Autonomous Database instance base storage to a maximum of 384 TB.

When you create an Autonomous Database instance, by default Storage auto scaling is disabled. You can manage scaling and enable storage auto scaling from the Oracle Cloud Infrastructure Console.

With Storage auto scaling enabled, the Autonomous Database can expand to use up to three times the reserved base storage, as specified by the storage shown in the Storage field on the Oracle Cloud Infrastructure Console. If you need additional storage, the database automatically uses the reserved storage without any manual intervention required.

You specify the base storage when you provision or clone your database, or you can change the storage at any time by clicking Manage resource allocation and changing the storage size. Depending on your workload type and the compute model selection, you have these options to specify the reserved base storage units:

  • Data Warehouse: Specify your storage in Terabytes (TB).

  • Transaction Processing: Specify your storage in Gigabytes (GB) or Terabytes (TB). GB units are only available when the Workload type is Transaction Processing and the Compute model is ECPU.

The maximum Autonomous Database storage is 384 TB. This means with auto scaling for storage enabled, you have access to the smaller of 3X your storage allocation, or 384 TB.

For example, if your storage is 100 TB and storage auto scaling is enabled, you have access to a maximum of 300 TB of storage and if your storage is 200 TB, you have access to a maximum of 384 TB.

As data flows in, you are billed as follows:

  • 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 4TB 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, Autonomous Database may be able to reduce your allocated storage back to 3.9TB (shrinking the data and undo tablespaces). After the shrink operation completes and your allocated storage (3.9TB) 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.

Note:

Reducing temp tablespace requires a database restart.

If you disable Storage auto scaling and the used storage is greater than the reserved base storage, as specified by the storage shown in the Storage field on the Oracle Cloud Infrastructure Console, Autonomous Database shows a warning on the disable storage auto scaling confirmation dialog. The warning lets you know that the reserved base storage value will be increased to the nearest TB greater than the actual storage usage, and shows the new reserved base storage value.

To see the Autonomous Database instance storage usage, you can view the "Storage allocated" and "Storage used" graphs on the Overview tab by clicking the Database Dashboard card in Database Actions. See Database Dashboard Overview for more information.

See Add CPU or Storage Resources or Enable Auto Scaling for the steps to enable storage auto scaling.

Shrink Storage

When the storage used in the database is significantly lower than the allocated storage, the shrink operation reduces the allocated storage.

To understand storage allocation and the shrink operation, note the following:

  • Reserved base storage: is the base amount of storage you select for the database when you provision or scale the database, excluding any auto-scaled value. The reserved base storage is shown in the Storage field on the Oracle Cloud Infrastructure Console.

  • Allocated storage: is the amount of storage physically reserved for all database tablespaces (excluding sample schema tablespaces). This number also includes the free space in these tablespaces.

  • Used storage: is the amount of storage actually used in all tablespaces (excluding the sample schema tablespaces). The used storage excludes the free space in these tablespaces. Used storage is the storage actually used by database objects, tables, indexes, and so on, including internally used temp space.

  • Maximum storage: is the maximum storage reserved. When storage auto scaling is disabled, the maximum storage equals the reserved base storage. When storage auto scaling is enabled, the maximum storage is three times the base storage (maximum = reserved base x 3).

Note:

The Shrink operation is not available with Always Free Autonomous Database.

To shrink storage:

  1. On the Details page, click Manage resource allocation.
  2. In the Manage resource allocation area, select Shrink.
  3. Click Confirm in the Shrink Database dialog.

Note:

The Shrink operation is a long running operation.

The Shrink operation requires that all of the following apply:

  • Storage auto scaling must be enabled.

  • The allocated storage must be greater than the reserved base storage.

  • The allocated storage, rounded up to the nearest 1TB, can be reduced by 1TB or more.

  • The following must be true:

    Allocated storage - Used storage > 100 GB

When you click Shrink and these conditions are not met, Autonomous Database shows the Action unavailable dialog.

Note the following for the Shrink operation:

  • The shrink operation runs an alter table... move online operation which uses the database's CPUs. In cases where the shrink operation is running slow or taking a very long time, Oracle recommends that you scale up the number of CPUs. See Add CPU or Storage Resources or Enable Auto Scaling for more information.

  • The shrink operation is not allowed if the Autonomous Database instance contains either of the following:

    • Advanced Queuing tables

    • Tables with LONG columns

  • If you have columns with the ROWID data type, the ROWIDs that these column values point to may change during the shrink operation.

  • Tables that contain the following may be moved offline during the shrink operation. DML operations on these tables may be blocked for the duration of the move and the table indexes for these tables may become unusable until the shrink operation completes:

    • Tables with bitmap join indexes

    • Nested tables

    • Object tables

    • Immutable tables

    • Blockchain tables

    • Partitioned tables with domain indexes

  • If you perform a Shrink operation very soon after a data deletion operation, the Shrink operation may fail. This can be due to the delay required for Autonomous Database to recalculate storage values. In this case, Oracle recommends that you retry the Shrink operation (that is, wait for several minutes for the storage deletion and any associated storage usage updates to complete and perform the Shrink operation again).