Oracle Cloud Infrastructure Documentation

Manage CPU or Storage Resources of an Autonomous Database

You can manage CPU or storage resources of an Autonomous Database from its Details page.

Note

In an Autonomous Data Guard setup, you can not scale an Autonomous Database whose standby database is in snapshot standby role. You must convert the standby Autonomous Container Database (ACD) to physical standby role to scale this database. See Convert Snapshot Standby to Physical Standby for instructions.

Add CPU or Storage Resources to an Autonomous Database

Required IAM Policies

use autonomous-databases

Related Live Labs

For a "try it out" alternative that demonstrates these instructions, see Lab 11: Zero Downtime Scaling in Oracle Autonomous Database Dedicated for Developers and Database Users Workshop.

Procedure

  1. Go to the Details page of the Autonomous Database you want to add CPU or storage resources to.
    Note

    For databases that use Autonomous Data Guard, go to the Details page of the primary database.

    For instructions, see View Details of an Autonomous Database on Dedicated Exadata Infrastructure.

  2. For Autonomous Database on Oracle Public Cloud, select Manage Scaling on the Details page. For Autonomous Database on Exadata Cloud@Customer, select Scale Up/Down on the Details page.

    Not Applicable This option is not enabled for an Autonomous Database for Developers instance.

  3. Select the change in resources for your scale request:
    • Click the up arrow to select a value for OCPU count or ECPU count. The default is no change.

      For databases using ECPUs, you must increment the number of assigned ECPUs to an integer. For example, you cannot assign 3.5 ECPUs to a database. The next available number of ECPUs above 3 is 4.

      For databases using OCPUs that do not need an entire OCPU, you can increment the OCPU count from 0.1 to 0.9 (in increments of 0.1). This is called CPU overprovisioning. Refer to CPU Overprovisioning for requirements and limitations of CPU overprovisioning.
      Note

      Scaling up a database with CPU overprovisioning to use a full OCPU does not impact the predefined database services that you can connect to. That is, you can only connect to the tp and low services for the Autonomous Transaction Processing workloads and to the low services for the Autonomous Data Warehouse workloads. See Predefined Database Service Names for Autonomous Databases to view a list of predefined services supported by an Autonomous Database.

      For databases using 1 or more OCPUs, you must increment the number of assigned OCPUs by an integer. For example, you cannot assign 3.5 OCPUs to a database. The next available number of OCPUs above 3 is 4.

      The selected CPU count is validated against a list of provisionable CPUs, and if the database can not be scaled up to the chosen CPU count, you will be provided with the two nearest provisionable CPU values. For more details about provisionable CPUs, see How VM Cluster Nodes Affect CPU Management.

      Tip:

      You can use the GetAutonomousDatabase API to get a complete list of provisionable CPU values.
    • Click up arrow to select a value for Storage (GB). Alternatively, you can also enter the value directly. The default is no change.
  4. Click Update to change your resources.

Remove CPU or Storage Resources from an Autonomous Database

Required IAM Policies

use autonomous-databases

Procedure

  1. Go to the Details page of the Autonomous Database you want to remove CPU or storage resources from.
    Note

    For databases that use Autonomous Data Guard, go to the Details page of the primary database.

    For instructions, see View Details of an Autonomous Database on Dedicated Exadata Infrastructure.

  2. On the Details page, select Manage Scaling.

    Availability This option is not enabled for an Autonomous Database for Developers instance.

  3. On the Manage Scaling page, select the change in resources for your scale request:
    • Click the down arrow to select a value for OCPU count or ECPU count. The default is no change.

      For databases using ECPUs, you must decrement the number of assigned ECPUs to an integer. For example, you cannot assign 3.5 ECPUs to a database. The next available number of ECPUs below 4 is 3. You can not scale down the ECPUs to a value less than 2.

      For databases using less than 1 OCPU, you can decrement the OCPU value from 0.9 to 0.1 (in decrements of 0.1) for OCPUs. Refer to CPU Overprovisioning for requirements and limitations of CPU overprovisioning.

      Note

      Scaling down a database to use CPU over-provisioning (OCPU value less than 1) from a full CPU (positive integer) does not impact the predefined database services that you can connect to. Despite being on CPU over-provisioning, you can continue to connect to all the predefined database services, as done before scaling down. See Predefined Database Service Names for Autonomous Databases to view a list of predefined services supported by an Autonomous Database.

      For databases using more than 1 OCPU, you must decrement the number of assigned OCPUs by an integer. For example, you cannot assign 3.5 OCPUs to a database. The next available number of OCPUs below 4 is 3.

      The selected CPU count is validated against a list of provisionable CPUs, and if the database can not be scaled down to the chosen CPU count, you will be provided with the two nearest provisionable CPU values. For more details about provisionable CPUs, see How VM Cluster Nodes Affect CPU Management.

      Tip:

      You can use the GetAutonomousDatabase API to get a complete list of provisionable CPU values.
    • Click down arrow to select a value for Storage (GB). The default is no change. The minimum storage that you can specify is the source database's actual used space rounded up to the next GB.
  4. Click Update to change your resources.