Oracle Cloud Infrastructure's Autonomous Database is a fully managed, preconfigured database environment with two workload types available, Autonomous Transaction Processing and Autonomous Data Warehouse. You do not need to configure or manage any hardware, or install any software. After provisioning, you can scale the number of CPU cores or the storage capacity of the database at any time without impacting availability or performance. Autonomous Database handles creating the database, as well as the following maintenance tasks:
- Backing up the database
- Patching the database
- Upgrading the database
- Tuning the database
Upgrading a database
If your Autonomous Database instance is on Oracle Database 18c, after notifying you of the upgrade date, Oracle will automatically upgrade your instance to Oracle Database 19c. If you want to upgrade at a time of your choosing, then you can manually upgrade your database to Oracle Database 19c. By choosing to manually upgrade, you can start using the Autonomous Database features that are available in Oracle Database 19c prior to the automatic upgrade date. See To upgrade an Autonomous Database for information on manual upgrades.
Autonomous Database can be used without charge as part of Oracle Cloud Infrastructure's suite of Always Free resources. Users of both paid and free Oracle Cloud Infrastructure accounts have access to two Always Free instances of Autonomous Database. Always Free Autonomous Databases have a fixed 8 GB of memory, 20 GB of storage, 1 OCPU, and can be configured for either Autonomous Transaction Processing or Autonomous Data Warehouse workloads.
Always Free databases have only single available version. You can see the version that is being used for your database in the details screen. After a newer Oracle Database version is available in Oracle Cloud Infrastructure, your database will be automatically upgraded during one of your database's upcoming maintenance windows.
To learn about Free Tier Databases, see Oracle Cloud Infrastructure Free Tier. To learn about the details of the Always Free Autonomous Database, see Overview of the Always Free Autonomous Database. To provision an Always Free Autonomous Database, see Creating an Autonomous Database.
For information on regional availability of Always Free Autonomous Database, see the "Always Free Cloud Services" section of Data Regions for Platform and Infrastructure Services.
Autonomous Database offers two workload types:
The Autonomous Transaction Processing workload type configures the database for a transactional workload, with a bias towards high volumes of random data access.
The Autonomous Data Warehouse workload type configures the database for a decision support or data warehouse workload, with a bias towards large data scanning operations.
Autonomous Databases have the following Exadata infrastructure options:
Dedicated Exadata Infrastructure: With this option, you have exclusive use of the Exadata hardware. Dedicated Exadata infrastructure offers multitenant database architecture, allowing you to create and manage multiple Autonomous Databases within a single database system. Both workload types (transaction processing and warehouse) can be provisioned on dedicated Exadata infrastructure. You have the following hardware configuration options:
- System Models: X7 and X8
- Configurations: quarter rack and half rack
See Overview of Autonomous Database on Dedicated Exadata Infrastructure for more information about dedicated Exadata infrastructure architecture, features, and hardware specifications.
- Shared Exadata Infrastructure: With this option, you provision and manage only the Autonomous Database, while Oracle handles the Exadata infrastructure deployment and management tasks. Both workload types (transaction processing and warehouse) can be provisioned with shared Exadata infrastructure.
Per-Second Billing Billing for Autonomous Database Resources
Shared Exadata Infrastructure
Autonomous Database on shared Exadata infrastructure uses per-second billing. This means that OCPU and storage usage is billed by the second. OCPU resources have a minimum usage period of 1 minute..
Dedicated Exadata Infrastructure
For each Autonomous Exadata Infrastructure instance you provision, you are billed for the infrastructure for a minimum of 48 hours, and then by the second after that. Each OCPU you add to the system is billed by the second, with a minimum usage period of 1 minute.
When you provision an Autonomous Database with shared Exadata infrastructure, you can configure the network access so that the database uses a private endpoint within one of your tenancy's virtual cloud networks (VCNs). When you use a private endpoint, your database is only accessible via the IP address of the associated private endpoint. For more information, see Autonomous Database with Private Endpoint.
You can manually scale the database's base number of CPU cores up or down at any time. Note the following:
- CPU scaling does not require any downtime.
CPU utilization information is available for all Autonomous Databases on the database details page in the Metrics section. CPU utilization is reported as a percentage of available CPUs, aggregated across all consumer groups.
For databases using Shared Exadata infrastructure, you can also view hourly snapshots of the database's CPU usage (actual number of cores allocated) over the most recent 8 days. This information is available in the Service Console, in the Overview page graph "Number of OCPUs Allocated". For more information, see To view OCPU allocation hourly snapshot data for an Autonomous Database.
Autonomous Database's auto scaling feature allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, auto scaling automatically increases the number of cores in use. Likewise, as demand drops, auto scaling automatically decreases the number of cores in use. Scaling takes place without any lag time, and you are only billed for your actual average CPU core usage per hour. Note the following points regarding the auto scaling feature:
- Auto scaling is enabled by default and can be enabled or disabled at any time.
- The auto scaling status for a database (enabled or disabled) is displayed on the database details page.
- The base number of OCPU cores allocated to a database is guaranteed. For databases on dedicated Exadata infrastructure, the maximum number of cores available to a database depends on the total number of cores available in the Exadata infrastructure instance, and is further limited by the number of free cores that aren't being used by other auto scaling databases to meet high-load demands. Available OCPU cores are enabled on a "first come, first served basis" for autoscaling databases sharing an Autonomous Exadata Infrastructure instance.
The following table illustrates OCPU core availability for a single database on an X8 quarter rack dedicated Exadata infrastructure instance. As you increase the database's base core count from 1 to 40 cores, the maximum core count scales until it reaches the hardware limit of 100 OCPUs. The final column, which shows the remaining available OCPUs that can be allocated to additional databases, assumes that no other databases exist on the quarter rack instance.
Example: OCPU auto scaling for a single database on an X8 quarter rack as base OCPU is increased
|Base OCPU core count||Maximum OCPU core count||OCPU cores remaining|
The following table illustrates OCPU core availability for four databases on an X8 half rack dedicated Exadata infrastructure instance. The hardware limit is 200 OCPUs. The Base OCPU count for each database is guaranteed to be available to the database at all times. In the example, the three database with auto scaling enabled are in contention for the 60 available cores that are not allocated to any database as base cores. Databases Sales and Development each auto scaled to take a combined 140 OCPU, and database Chicago (with auto scaling disabled) is using its 10 base OCPU. That leaves only 50 OCPU remaining in the half rack hardware instance, and the base OCPU of database HR is 50. Therefore, database HR cannot auto scale up until cores are released by the other auto scaling databases.
Example: OCPU auto scaling for four databases on an X8 half rack
|DB Name||Auto Scaling||Base OCPU Count (Guaranteed OCPU)||Maximum OCPU core count||OCPU Enabled During Load|
Autonomous Database allows you to scale the storage capacity of the database at any time without impacting availability or performance.
You can monitor and analyze the performance of an Autonomous Database in the Oracle Cloud Infrastructure Console using the Performance Hub ASH Analytics, SQL Monitoring, Workload, and Blocking Sessions features. These features provide the same information as the ASH Analytics and SQL Monitoring tools found in Oracle's EM Express, Oracle Management Cloud (OMC), and SQL Developer Web applications. In addition, the Workload performance monitoring feature provides detailed real-time and historical performance data of CPU Statistics, Wait Time Statistics, Workload Profile, and Sessions. The Blocking Sessions feature provides information about blocking and waiting sessions for a selected Autonomous Database and includes procedures to display detailed information about the sessions and to kill sessions as needed. Detailed information about these features and how to use them is located in Using Performance Hub to Analyze Database Performance.
Oracle Cloud Infrastructure periodically offers Autonomous Database preview versions of Oracle Database for testing purposes. You can provision an Autonomous Database using preview version software to test applications before the general availability of the software in Autonomous Database. Oracle will notify Autonomous Database customers when preview versions are available. Preview version software is available for a limited time. Databases provisioned with preview version software will display the end date of the preview period at the top of the database details page in the Console. If you are using the Console, you can also see the end date of the preview period in the Create Database provisioning dialog before the database is created.
Preview version software should not be used for production databases or for databases that need to persist beyond the limited preview period. Note that preview databases and their associated resources (including backups) are terminated automatically at the conclusion of the preview period. Oracle will notify customers prior to the conclusion of the preview period regarding the end date of the preview.
Any existing Autonomous Database (including those provisioned with preview version software) can be cloned using a preview version of Autonomous Database. However, preview version databases cannot be cloned using the regular (general-availability) Autonomous Database software.
See Creating an Autonomous Database for details on provisioning a preview version of Autonomous Database.
Depending on the region where you provision or clone your database, Autonomous Database supports one or more Oracle Database versions.
Always FreeAutonomous Databases supports only a single Oracle Database version. See Overview of the Always Free Autonomous Database for more information.
Autonomous Database is currently available in all regions of the commercial realm. Autonomous Database is currently not available in regions within the Government Cloud realm.
Oracle Data Safe is a unified cloud service control center that enables you to monitor the security status of your Autonomous Databases on shared Exadata infrastructure and dedicated Exadata infrastructure. It helps you to evaluate security controls, assess user security, monitor user activity, and address data security compliance requirements for your database by evaluating the sensitivity of your data as well as masking sensitive data for non-production databases. It provides the following set of features in a single, easy-to-use management console:
- Security Assessment assesses the security of your database configuration.
- User Assessment evaluates the security of your database users and identifies high risk users.
- Data Discovery finds sensitive data in your database.
- Data Masking masks sensitive data so that the data is safe for non-production purposes.
- Activity Auditing audits user activity on your database so that you can monitor database usage and receive alerts of unusual database activities.
For information on registering or deregistering a database with Data Safe, see Managing an Autonomous Database. Autonomous Databases using the private endpoint feature are not compatible with Data Safe.
For information on creating and using Data Safe instances, see the Data Safe documentation.
Autonomous Database is one of the Oracle Cloud Infrastructure services that can be privately accessed through a service gateway within a VCN . This means you do not need a public IP or NAT to access your Autonomous Database instance from any of the cloud services within the Oracle Services Network. For example, if you have a Compute instance that uses a VCN with a service gateway, you can route traffic between your Compute instance and an Autonomous Database in the same region without the traffic going over the internet. For information on setting up a VCN service gateway and configuring it to access all supported Oracle Service Network services (which include Autonomous Database), see Access to Oracle Services: Service Gateway.
For Autonomous Databases on shared Exadata infrastructure, an access control list (ACL) provides additional protection for your database by allowing only specified IP addresses and VCNs in the list to connect to the database. Specified IP addresses can include private IP addresses from your on-premises network that connect to your database using transit routing and allow traffic to move directly from your on-premises network to your Autonomous Database without going over the internet. See Transit Routing: Private Access to Oracle Services for more information on this method of access.
You can add the following to your ACL:
- Public IP addresses (individually, or in CIDR blocks)
- An entire VCN (specified by OCID )
- Private IP addresses within a specified VCN (individually, or in CIDR blocks)
- Private IP addresses within an on-premises network that have access using a transit routing
You can create an ACL during database provisioning, or at any time thereafter. You can also edit an ACL at any time. Removing all entries from the list makes the database accessible to all clients with the applicable credentials. See To manage the access control list of an Autonomous Database on shared Exadata infrastructure to learn how to create, update, or delete an ACL.
If you want to only allow connections coming through a service gateway you need to use the IP address of the service gateway in your ACL definition. To do this you need to add an ACL rule using the CIDR source type and the value 240.0.0.0/4. Note that this is not recommended. Instead, you can specify individual VCNs in your ACL definition for the VCNs you want to allow access from. See Access to Oracle Services: Service Gateway for more information.
Note the following about using an ACL with your Autonomous Database:
- When you restore a database the existing ACLs are not overwritten by the restore.
- The network ACL applies to the database connections and Oracle Machine Learning notebooks. If an ACL is defined and you try to login to Oracle Machine Learning from a client whose IP is not specified on the ACL you will see a "login rejected based on access control list set by the administrator" error.
- Oracle Application Express (APEX), RESTful services, and SQL Developer Web are subject to ACLs. You can create rules specifying Virtual Cloud Networks, Virtual Cloud Network OCIDs, IP addresses, or CIDR blocks to control access to these tools.
- The Autonomous Database Service console is not subject to ACL rules.
If you have a private subnet in your VCN that is configured to access the public internet through an NAT gateway, you need to enter the public IP address of the NAT gateway in your ACL definition. Clients in the private subnet do not have public IP addresses. See NAT Gateway for more information.
Network security groups (NSGs) are an optional Networking security feature available for dedicated Exadata infrastructure and databases on shared Exadata infrastructure that use private endpoints. NSGs act as a virtual firewall for your Autonomous Database resources. An NSG consists of a set of ingress and egress security rules that apply only to a set of VNICs of your choice within a single VCN. For more information, see the following topics:
- Network Security Groups
- To edit the network security groups (NSGs) for your Autonomous Exadata Infrastructure resource
- To update the network configuration of an Autonomous Database on shared Exadata infrastructure that uses a private endpoint
For Autonomous Databases on shared Exadata infrastructure, Oracle manages the automatic maintenance. You can view the next scheduled maintenance in the Console on the details page for your Autonomous Database. For Autonomous Databases on dedicated Exadata infrastructure, see Overview of Dedicated Exadata Infrastructure Maintenance.
Development and Administration Tools
Oracle's SQL Developer Web, Application Express (APEX), and Machine Learning applications are available for Autonomous Databases. For information on how to use these applications and access them from the Console, see Autonomous Database Development and Administration Tools.
Compartment Quotas for Autonomous Databases
You can use compartment quotas to control how Autonomous Database OCPU and storage resources are allocated to Oracle Cloud Infrastructure compartments. You can use compartment quota policy statements to control OCPU and storage resources by both workload type and Exadata infrastructure type. For example, you can allocate 10 Autonomous Transaction Processing OCPUs on shared Exadata infrastructure to a specific compartment. This would not affect the number of OCPUs available to Autonomous Data Warehouse databases, or databases using dedicated Exadata infrastructure. For more information on using compartment quotas, see Compartment Quotas and Database Quotas.
Using the Oracle Cloud Infrastructure Console to Manage Autonomous Databases
For information on provisioning, managing, and backing up an Autonomous Database in the Oracle Cloud Infrastructure Console, see the following topics:
- Creating an Autonomous Database
- Managing an Autonomous Database
- Connecting to an Autonomous Database
- Backing Up an Autonomous Database Manually
- Restoring an Autonomous Database
Additional Autonomous Database Product Information
Information for Databases on Dedicated Exadata Infrastructure
For in-depth documentation on using and managing your Autonomous Transaction Processing on dedicated Exadata infrastructure, see the following topics:
- Getting Started with Autonomous Transaction Processing
- Connecting to Autonomous Transaction Processing
- Loading Data into Autonomous Transaction Processing
- Starting, Stopping and Scaling Autonomous Transaction Processing
- Managing Database Users
- Managing and Monitoring Performance
- Backing Up and Restoring Autonomous Transaction Processing
- Cloud Object Storage URI Formats
- Using Oracle Database Features in Autonomous Transaction Processing
For information on how application developers connect their applications to Autonomous Transaction Processing databases, see Developer’s Guide to Oracle Autonomous Transaction Processing on Dedicated Exadata Infrastructure.
For known issues, see Known Issues for Oracle Autonomous Database on Dedicated Exadata Infrastructure.
Information for Databases on Shared Exadata Infrastructure
For in-depth documentation on using and managing your Autonomous Transaction Processing database, see the following topics:
- Getting Started with Autonomous Transaction Processing
- Connecting to Autonomous Transaction Processing
- Loading Data with Autonomous Transaction Processing
- Querying External Data with Autonomous Transaction Processing
- Creating Dashboards, Reports, and Notebooks with Autonomous Transaction Processing
- Managing Users on Autonomous Transaction Processing
- Managing and Monitoring Performance of Autonomous Transaction Processing
For information on using a database client to manage your database, see Connect Autonomous Transaction Processing Using a Client Application.
Information for Databases on Shared Exadata Infrastructure
For in-depth documentation on using and managing your Autonomous Data Warehouse database, see the following topics:
- Getting Started with Autonomous Data Warehouse Cloud
- Migrating Data from Amazon Redshift
For information on using a database client to manage your database, see the following topic:
High availability is suitable for all development, test, and production databases that have high uptime requirements and low data loss tolerance. You can select high availability for databases that require a multi-node configuration to protect against localized hardware failures but that do not require fast disaster recovery. Each Autonomous Database application service resides in at least one Oracle Real Application Clusters (Oracle RAC) instance with the ability to fail over to another available Oracle RAC instance for unplanned outages or planned maintenance activities, resulting in zero or near-zero downtime. Autonomous Database's automatic backups are stored in Oracle Cloud Infrastructure Object Storage and replicated to another availability domain, and can be restored in the event of a disaster. Major database upgrades, however, require downtime.
The uptime service-level objective per month is 99.95% (a maximum of 22 minutes of downtime per month), but when you use Maximum Availability Architecture best practices for continuous service, most months would effectively have zero downtime. The uptime service-level objective does not include downtime due to customer-initiated high availability tests, disaster recovery (such as an availability domain or regional outage), database corruptions, or downtime due to planned maintenance that cannot be done online or through an Oracle RAC rolling update solution, such as major database upgrades from one release to another.
The following table describes the recovery-time objectives and recovery-point objectives (data loss tolerance) for service-level objectives.
High Availability Policy Recovery Time (RTO) and Recovery Point (RPO) Sevice-level Objectives
|Failure and Maintenance Events||Database Downtime||Service-Level Downtime (RTO)||Potential Service-Level Data Loss (RPO)|
|Localized events, including:
|Events requiring restoring from backup because standby database does not exist:
||Minutes to hours||Minutes to hours||15 minutes|
In the preceding table, the amount of downtime for events requiring restoring from a backup varies due to the nature of the failure. In the most optimistic case, a physical block corruption is detected and the block is repaired with block media recovery in minutes. In this case, only a small portion of the database is affected and there is zero data loss.
In a more pessimistic case, an availability domain or data region fails, and a new cluster must be provisioned and restored with the latest database backup, including all archives, and a complete database recovery must be run. Data loss is limited by the last successful archive log backup, the frequency of which is every 15 minutes, by default, and includes a log switch and subsequent archive log backup of any redo that has not been backed up to Oracle Cloud Infrastructure Object Storage. The backup should be quick and estimated data loss can be less than 15 minutes or, at worst, slightly above 15 minutes.
Maintaining Application Uptime
Ensure that network connectivity to Oracle Cloud Infrastructure is reliable so that you can access your tenancy's Autonomous Database resources.
Follow the guidelines in the Continuous Availability - Application Continuity for the Oracle Database white paper to experience application-level service uptime similar to that of the database uptime.