Managing Autonomous Databases
An Autonomous Database resource is a user database. When you create an Autonomous Database, you choose the Autonomous Container Database for it and you specify "Data Warehouse" or "Transaction Processing" as its workload type to create an Autonomous Data Warehouse database or an Autonomous Transaction Processing database.
You can create hundreds of Autonomous Databases on an Exadata Infrastructure. As described in Available Exadata Infrastructure Hardware Shapes, the maximum is determined by the capacity of your Exadata Infrastructure hardware.
- Oracle Autonomous Database for Developers
Oracle Autonomous Database for Developers instances are free Autonomous Databases that developers can use to build and test new applications. - Create an Autonomous Database
- Manage Access Control List of an Autonomous Database
- View a List of Autonomous Databases
- View Details of an Autonomous Database
- Manage Customer Contacts for an Autonomous Database
- Rotate ADB Encryption Key
- Set the Password of an Autonomous Database's ADMIN User
- Scale the CPU Core Count or Storage of an Autonomous Database, or Enable/Disable or Alter the Percentage of System Global Area (SGA) for IM Column Store
- Enable or Disable Auto Scaling for an Autonomous Database
- Move an Autonomous Database to Another Compartment
- Stop or Start an Autonomous Database
- Restart an Autonomous Database
- Back Up an Autonomous Database Manually
- Create a Long-Term Backup
- View Details and Edit Retention Period of a Long-Term Backup
- Delete a Long-Term Backup
- Restore an Autonomous Database
- Clone an Autonomous Database
- Clone an Autonomous Database Backup
- Clone a Standby Database
- Clone a Standby Database Backup
- Terminate an Autonomous Database
- API to Manage Autonomous Databases
- Monitor Performance with Autonomous Database Metrics
Related Topics
Parent topic: Autonomous Database on Exadata Cloud@Customer
Oracle Autonomous Database for Developers
Oracle Autonomous Database for Developers instances are free Autonomous Databases that developers can use to build and test new applications.
With Autonomous Database for Developers instances, you can try new Autonomous Database features for free and apply them to ongoing or new development projects. Developer databases are limited in resources, so they are not suitable for large-scale testing and production deployments. When you need more compute or storage resources, you can transition to a paid database licensing by cloning your developer database into a regular Autonomous Database.
Requirements
To create an Autonomous Database for Developers instance, you must have access to Oracle Exadata Database Service or Autonomous Database on either a Dedicated Exadata Infrastructure or Exadata Cloud@Customer. In other words, only those customers with active subscriptions to any of the following service platforms can create developer databases:
- Autonomous Database on Dedicated Exadata Infrastructure
- Exadata Database Service on Dedicated Exadata Infrastructure
- Autonomous Database on Exadata Cloud@Customer
- Exadata Database Service on Cloud@Customer
There is no limit on the number of free developer databases; it’s limited by the capacity of your Exadata infrastructure.
Provisioning Workflow
You can provision an Autonomous Database for Developers instance from the Oracle Cloud Infrastructure (OCI) console or using API. To create a developer database, you need an ACD without an Autonomous Data Guard in an ECPU-based AVMC. If you do not have these resources provisioned already, create the ECPU-based AVMC first and then create an ACD without disaster recovery (Autonomous Data Guard) using that AVMC.
After creating or identifying (if they already exist) the AVMC and ACD, you can create an Autonomous Database for Developers using them. Provisioning a developer database using the OCI console follows the same workflow as creating a regular Autonomous Database, as described in Create Autonomous Database. Once created, the Autonomous Database for Developers instances appear with a Developer label in the list of Autonomous Databases on the OCI console.
Specifications
Each developer database comes with the following specifications:
- Compute: Fixed 4 ECPUs, with no CPU scaling
- Storage: Fixed 32 GB ( ~ 20 GB of DATA)
- Session limits: 30 concurrent database sessions
- Workload Type: Data Warehouse, Transaction Processing
Excluded Features
Autonomous Database for Developers supports all the features offered by a regular Autonomous Database except those listed below. These limitations are in place to ensure that the developer databases are optimally used as a development sandbox.
Developer database instances:
- Do not support Autonomous Data Guard. Hence, they can only be provisioned in an ACD without Autonomous Data Guard.
- Support ECPU only. Therefore, you can provision them only on an ECPU based ACD.
- Come with fixed compute and storage sizing, do not support manual or auto-scaling and storage scaling.
- Can not have long-term backups.
- Do not provide Database In-memory.
Supported Features
- Cloning: Autonomous Database for Developers offers fewer resources and features than a regular autonomous database. For non-development use, such as load/stress testing and production, or to get access to all features, users can use cloning to clone from a developer database to a regular Autonomous database. You can also clone a regular database into a developer database; however, to successfully clone a regular database into a developer database, the source database's actual used space, rounded up to the next GB, must be <= 32GB.
- Backup and Recovery: You can enable automatic backups or trigger manual backups of your developer database, as needed. If the backup destination is an Object Storage and Recovery Service, the backups will be billed.
- Service Maintenance: Developer databases follow the same patching schedule as regular Autonomous Database; however, there will be no support for critical one-off patches.
- Database Application Development and Developer Tools: With Autonomous Database for Developers, you can use all the developer-related features and built-in tools an Autonomous Database offers.
Autonomous Database for Developers comes with a service level objective (SLO) of 99.5% and you can log service requests (SR) to Oracle Support for assistance. However, there is no Severity 1 SR support for developer databases. See Create a Service Request in My Oracle Support to learn how to contact Oracle Support for assistance.
Parent topic: Managing Autonomous Databases
Create an Autonomous Database
- If the standby ACD is in snapshot standby mode, then you cannot create an ADB in the primary ACD.
- For better management and sharing of the underlying SGA/memory resources, Oracle recommends that all Autonomous Databases configured for In-Memory be in the same Autonomous Container Database.
Related Topics
Parent topic: Managing Autonomous Databases
Manage Access Control List of an Autonomous Database
An access control list (ACL) provides additional protection to your database by allowing only the clients with specific IP addresses to connect to the database. You can add IP addresses individually, or in CIDR blocks.
You can optionally create an ACL during database provisioning, or at any time thereafter. You can also edit an ACL at any time. Enabling an access control list with an empty list of IP addresses makes the database inaccessible.
Note the following about using an ACL with your Autonomous Database:
- The Autonomous Database Service console is not subject to ACL rules.
- Oracle Application Express (APEX), RESTful services, SQL Developer Web, and Performance Hub are not subject to ACLs.
- While creating a database, if setting ACL fails, then provisioning the database also fails.
- Updating ACL is allowed if the database is in
Available
andAvailableNeedsAttention
states. - Restoring a database does not overwrite the existing ACLs.
- Cloning a database, full and metadata, will have the same access control settings as the source database. You can make changes as necessary.
- All CDB operations are allowed during ACL update. However, ADB operations are not allowed during ACL update.
Parent topic: Managing Autonomous Databases
View a List of Autonomous Databases
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
Parent topic: Managing Autonomous Databases
View Details of an Autonomous Database
Parent topic: Managing Autonomous Databases
Manage Customer Contacts for an Autonomous Database
Parent topic: Managing Autonomous Databases
Rotate ADB Encryption Key
Follow these steps to rotate the TDE Master key. On key rotation, the ADB life cycle goes through the regular updating state and returns to available.
You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.
You can rotate both Oracle-managed and customer-managed encryption keys.
- Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to view details.
- On the Autonomous Database Details page, from the More Actions drop-down list, select Rotate Encryption Key.
- On the Rotate Encryption Key dialog, click Rotate Encryption Key.
Parent topic: Managing Autonomous Databases
Set the Password of an Autonomous Database's ADMIN User
Parent topic: Managing Autonomous Databases
Scale the CPU Core Count or Storage of an Autonomous Database, or Enable/Disable or Alter the Percentage of System Global Area (SGA) for IM Column Store
- If the standby ACD is in snapshot standby mode, then you cannot scale an ADB in the primary ACD.
- For better management and sharing of the underlying SGA/memory resources, Oracle recommends that all Autonomous Databases configured for In-Memory be in the same Autonomous Container Database.
Related Topics
Parent topic: Managing Autonomous Databases
Enable or Disable Auto Scaling for an Autonomous Database
Oracle Autonomous Database on Oracle Exadata Cloud@Customer systems provides an auto-scaling feature that automatically increases the number of CPUs in an autonomous database during periods of increased demand and, as demand returns to normal, automatically decreases the number of cores down to the databases's base number.
Note the following points regarding the auto-scaling feature:
- With auto-scaling enabled, the database can use up to three times more CPU and IO resources than specified by the number of CPUs currently shown in the Scale Up/Down dialog.
- If auto-scaling is disabled while more CPU cores are in use than the database's currently assigned number of cores, then Autonomous Database scales the number of CPU cores in use down to the assigned number.
- Enabling auto scaling does not change the concurrency and parallelism settings for the predefined services.
Follow these steps to enable or disable auto-scaling for an autonomous database.
Parent topic: Managing Autonomous Databases
Move an Autonomous Database to Another Compartment
Follow these steps to move an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system from one compartment to another compartment.
- To move an autonomous database you must have the right to manage it in its current compartment and in the compartment you are moving it to.
- As soon as you move an autonomous database to a different compartment, the policies that govern the new compartment apply immediately and affect access to the autonomous database. Therefore, both your and other Oracle Cloud users' access to it may change, depending on the policies governing the user account's access to resources. For example, a user may lose the ability to manage the autonomous databae, given its new compartment.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to move.
- From the More Actions drop-down list, select Move Resource.
- Select the new compartment.
- Click Move Resource.
Parent topic: Managing Autonomous Databases
Stop or Start an Autonomous Database
Stopping your database has the following consequences:
- On-going transactions are rolled back.
- You will not be able to connect to your database using database clients or tools.
Parent topic: Managing Autonomous Databases
Restart an Autonomous Database
To resolve some autonomous database issues with minimal downtime on Exadata Database Service on Cloud@Customer systems, you can restart the database.
Restarting an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system is equivalent to manually stopping and then starting the database. Using restart allows you to minimize downtime and requires only a single action.
Follow these steps to restart an autonomous database.
Parent topic: Managing Autonomous Databases
Back Up an Autonomous Database Manually
During the backup operation, your autonomous database remains available. However, lifecycle management operations such as stopping it, scaling it, or terminating it are disabled.
Creating
Active
Deleting
Deleted
Failed
Parent topic: Managing Autonomous Databases
Create a Long-Term Backup
Long-term backups are not available with Autonomous Database for Developers instances. See Oracle Autonomous Database for Developers for more details.
Related Topics
Parent topic: Managing Autonomous Databases
View Details and Edit Retention Period of a Long-Term Backup
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish the details of a long-term backup.
- In the resulting Autonomous Details page, under Resources, click Backups.
- In the Backups section, identify the backup, and review the details.
- To edit the retention period, click the action icon (three dots) and select Edit retention period.
- In the resulting window, set the retention period.
- Click Save.
Parent topic: Managing Autonomous Databases
Delete a Long-Term Backup
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to view the details of a long-term backup.
- In the resulting Autonomous Details page, under Resources, click Backups.
- In the Backups section, identify the backup, click the action icon (three dots), and then select Delete.
- In the resulting window, click Delete if you are sure about deleting it.
Parent topic: Managing Autonomous Databases
Restore an Autonomous Database
You can use any existing manual or automatic backup to restore and recover an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system, or you can restore and recover the database to any point in time during the retention period of its automatic backups.
- Restoring an autonomous database puts the database in an unavailable state during the restore operation. You cannot connect to a database in this state. The only lifecycle management operation supported in the unavailable state is terminate.
- You cannot perform a restore operation on a primary ADB if the standby database is in snapshot standby mode. Convert your standby ACD to physical standby mode to restore an Autonomous Database.
Restore from a Backup
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you want to clone.
- From the More Actions drop-down list, select Restore.
- Specify the date range for a list of backups to display.
- Select the backup.
- Click Restore.
Parent topic: Restore an Autonomous Database
Restore to a Point in Time
Parent topic: Restore an Autonomous Database
Clone an Autonomous Database
You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.
Autonomous Databases with 23ai software version can not be cloned into an Autonomous Database with 19c version and vice-versa.
If IM is enabled, the source In-Memory Column Store settings or parameters will not be applied to the clone. However, you can enable In-Memory Column Store like a normal ADB creation flow.
Clone Types
- The full-clone option creates a database that includes the metadata and data from the source database.
- The metadata-clone option creates a database that includes only the metadata from the source database.
Steps
The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:
- The new clone displays the Provisioning lifecycle state until the provisioning process completes.
- The source database remains in the Available lifecycle state.
- Backups associated with the source database are not cloned for either the full-clone or the metadata-clone option.
The Clone source is displayed in the General Information section of the cloned database details page. Click the name to view details of the source database. Note that if the source database is deleted, then this key/value pair is not displayed.
Related Topics
Parent topic: Managing Autonomous Databases
Clone an Autonomous Database Backup
You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.
If IM is enabled, the source In-Memory Column Store settings or parameters will not be applied to the clone. However, you can enable In-Memory Column Store like a normal ADB creation flow.
Clone Types
- The full-clone option creates a database that includes the metadata and data from the source database.
- The metadata-clone option creates a database that includes only the metadata from the source database.
Steps
The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:
- The new clone displays the Provisioning lifecycle state until the provisioning process completes.
- The source database remains in the Available lifecycle state.
Related Topics
Parent topic: Managing Autonomous Databases
Clone a Standby Database
You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics.
Clone Types: The clone feature offers the full-clone option to create a database that includes the metadata and data from the source database.
Steps
The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:
- The new clone displays the Provisioning lifecycle state until the provisioning process completes.
- The source database remains in the Available lifecycle state.
- Backups associated with the source database are not cloned for either the full-clone or the metadata-clone option.
The Clone source is displayed in the General Information section of the cloned database details page. Click the name to view details of the source database. Note that if the source database is deleted, then this key/value pair is not displayed.
Related Topics
Parent topic: Managing Autonomous Databases
Clone a Standby Database Backup
You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.
Clone Types
- The full-clone option creates a database that includes the metadata and data from the source database.
- The metadata-clone option creates a database that includes only the metadata from the source database.
Steps
The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:
- The new clone displays the Provisioning lifecycle state until the provisioning process completes.
- The source database remains in the Available lifecycle state.
Related Topics
Parent topic: Managing Autonomous Databases
Terminate an Autonomous Database
Follow these steps to terminate an Autonomous Database on an Oracle Exadata Database Service on Cloud@Customer system.
If the standby ACD is in snapshot standby mode, then you cannot delete an ADB in the primary ACD.
WARNING:
Terminating an Autonomous Database permanently deletes it. The database data will be lost when the system is terminated. However, automatic backups are not deleted if you have chosen Recovery Appliance or NFS as a backup destination. You can delete automatic backups directly from the Recovery Appliance or NFS.
- Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
- Click Autonomous Databases.
- In the list of Autonomous Databases, click the display name of the database you wish to terminate.
- From the More Actions drop-down list, select Terminate.
- Confirm that you wish to terminate your Autonomous Database in the confirmation dialog.
- Click Terminate Autonomous Database.
Parent topic: Managing Autonomous Databases
API to Manage Autonomous Databases
For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.
The following table lists the REST API endpoints to manage Autonomous Databases.
Operation | REST API Endpoint |
---|---|
Create an Autonomous Database |
|
View a list of Autonomous Databases |
|
View details of an Autonomous Database |
|
View a list of character sets supported by Autonomous Database. | ListAutonomousDatabaseCharacterSets |
Set the password of an Autonomous Database's ADMIN user |
|
Scale the CPU core count or storage of an Autonomous Database |
|
Enable or disable auto scaling for an Autonomous Database |
|
Move an Autonomous Database to another compartment |
|
Stop or start an Autonomous Database |
|
Stop or start an Autonomous Database |
|
Restart an Autonomous Database |
|
Back up an Autonomous Database manually |
|
View the list of Autonomous Database backups |
ListAutonomousDatabaseBackups |
Restore an Autonomous Database |
|
Clone an Autonomous Database |
|
Terminate an Autonomous Database |
Parent topic: Managing Autonomous Databases
Monitor Performance with Autonomous Database Metrics
You can monitor the health, capacity, and performance of your Autonomous Databases with metrics, alarms, and notifications. You can use Oracle Cloud Infrastructure console or Monitoring APIs to view metrics.
- View Top Six Metrics for an Autonomous Database
Displays the top six metrics that are available in the metrics section on the Autonomous Database details page. - View Aggregated Metrics for Autonomous Databases in a Compartment
Learn to view aggregated metrics for Autonomous Databases in a compartment. - Autonomous Database Metrics and Dimensions
You can limit the instances where you see metrics with dimensions. The available dimensions include: workload type, instance display name, region, and the instance OCID.
Parent topic: Managing Autonomous Databases
View Top Six Metrics for an Autonomous Database
Displays the top six metrics that are available in the metrics section on the Autonomous Database details page.
To view metrics you must have the required access as specified in an Oracle Cloud Infrastructure policy (whether you're using the Console, the REST API, or other tools). See Getting Started with Policies for information on policies.
-
Open the Oracle Cloud Infrastructure console by clicking the hamburger menu next to Oracle Cloud.
-
From the Oracle Cloud Infrastructure left navigation list click Oracle Databases > Exadata Cloud@Customer.
-
On the Autonomous Databases page select an Autonomous Database from the links under the Name column.
To view metrics for an Autonomous Database instance:
Parent topic: Monitor Performance with Autonomous Database Metrics
View Aggregated Metrics for Autonomous Databases in a Compartment
Learn to view aggregated metrics for Autonomous Databases in a compartment.
To view metrics you must have the required access as specified in an Oracle Cloud Infrastructure policy (whether you're using the Console, the REST API, or other tool). See Getting Started with Policies for information on policies
-
Open the Oracle Cloud Infrastructure console by clicking the hamburger menu next to Oracle Cloud.
- From the left navigation list click Solutions and Platform > Monitoring > Service Metrics.
To use the metrics service to view Autonomous Database metrics:
- On the Service Metrics page, under Compartment select your compartment.
- On the Service Metrics page, under Metric Namespace select oci_autonomous_database.
- If there are multiple Autonomous Databases in the compartment you can show metrics aggregated across the Autonomous Databases by selecting Aggregate Metric Streams.
- If you want to limit the metrics you see, next to
Dimensions click Add (click
Edit if you have already added dimensions).
- In the Dimension Name field select a dimension.
- In the Dimension Value field select a value.
- Click Done.
- In the Edit dimensions dialog click +Additional Dimension to add an additional dimension. Click x to remove a dimension.
To create an alarm on a specific metric, click Options and select Create an Alarm on this Query. See Managing Alarms for information on setting and using alarms.
Parent topic: Monitor Performance with Autonomous Database Metrics
Autonomous Database Metrics and Dimensions
You can limit the instances where you see metrics with dimensions. The available dimensions include: workload type, instance display name, region, and the instance OCID.
Use dimensions by selecting values in the Oracle Cloud Infrastructure Console Service Metrics page or by setting dimension values with the API. See View Aggregated Metrics for Autonomous Databases in a Compartment to view metrics and to select metric dimensions.
See Database Metrics for a list of the database metrics and dimensions.
Parent topic: Monitor Performance with Autonomous Database Metrics