JavaScript must be enabled to correctly display this content
Manage CPU or Storage Resources of an Autonomous Database on Dedicated Exadata Infrastructure
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.
On Oracle Public Cloud, click
Edit in the Resource
Allocation section. On Exadata Cloud@Customer, click Edit in the
Resources section. The Manage scaling page
opens.
This option is not enabled for an Autonomous Database for Developers instance.
Note:
Alternatively, you can open
Manage scaling page by clicking Manage resource
allocation under More actions on Oracle Public Cloud or
Manage scaling under
Actions on Exadata Cloud@Customer.
Select the change in resources for your scale request:
Click the up arrow to select a value for ECPU count or
OCPU 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.
Click Update to change your resources.
Remove CPU or Storage Resources from an Autonomous Database
Required IAM Policies
use autonomous-databases
Procedure
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.
On Oracle Public Cloud, click
Edit in the Resource
Allocation section. On Exadata Cloud@Customer, click Edit in the
Resources section. The Manage scaling page
opens.
This option is not enabled for an Autonomous Database for Developers instance.
Note:
Alternatively, you can open
Manage scaling page by clicking Manage resource
allocation under More actions on Oracle Public Cloud or
Manage scaling under
Actions on Exadata Cloud@Customer.
Select the change in resources for your scale request:
Click the down arrow to select a value for ECPU
count or OCPU 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.