This web page provides a list of frequently asked questions and answers for Oracle Autonomous Database (Autonomous Data Warehouse and Autonomous Transaction Processing).
This list of FAQs will be updated on a regular basis.
This section includes a list of frequently asked questions that relate to Oracle Autonomous Database, i.e. the questions and answers cover both Autonomous Data Warehouse and Autonomous Transaction Processing. Below are sections covering each of these specific services.
Oracle Autonomous Database is the world’s first autonomous data management in the cloud to deliver automated patching, upgrades, and tuning—including performing all routine database maintenance tasks while the system is running - without human intervention. This new autonomous database cloud is self-managing, self-securing, and self-repairing, which helps to eliminate manual database management and human errors.
The Oracle Autonomous Database is fully elastic: You simply specify the number of OCPUs and the storage capacity in TB's for the database. At any time, you may scale up or down the OCPUs or the storage capacity.
Autonomous Database supports four main types of workload:
Click here for more information.
Shared Exadata Infrastructure: With this option, you provision and manage only the Autonomous Database, while Oracle deploys and manages all the underlying infrastructure. Oracle autonomously operates all aspects of the database life cycle from database placement to backup and updates.
Dedicated Exadata Infrastructure: this offers a private cloud in the public cloud. A completely dedicated compute, storage, network and database service for only a single tenant. This offers a multitenant database architecture, allowing you to create and manage multiple Autonomous Databases within a single database system. Autonomous Database on Dedicated Infrastructure is also available in customer's data centers with Exadata Cloud at Customer.
The full list of data centers is shown here: Oracle Cloud Data Regions for Platform and Infrastructure Services.
In some cases, tools, applications and services etc. have been extended specifically for Autonomous Database. In general, tools etc. that are certified with Oracle Database should work successfully against Autonomous Database, whether the tool is on the list or not. For a detailed list of tools, applications and services etc. that work with Autonomous Database, click here.
There's plenty of material to help you get started and be successful with Autonomous Database. Click here for more information.
Pricing details can be found on the Autonomous Data Warehouse (ADW) or Autonomous Transaction Processing (ATP) page of oracle.com.
You can provision a License-included version of ADB, or you can provision a Bring-Your-Own-License (BYOL) instance. If you wish to use BYOL, then you must apply current database licenses to your ADB service. The BYOL requirements for ATP are described on ATP's pricing page. The BYOL requirements for ADW are described on ADW's pricing page.
This document describes the licensing requirements for ADB.
Yes, ADB does support per-second billing although certain restrictions apply. There is more information available here
The auto scaling features within Autonomous Database provide the ability to automatically scale in real-time in response to workload. Auto scaling immediately gives 3x more CPU/IO resources with no downtime. But you only get charged only for actual usage - you only pay for those additional compute resources when they are needed, which gives you a true pay-as-you-go model. There is more information available here
Yes. You can do this by stopping the service from the cloud console or from the command line using the OCI APIs. This operation closes your ADB database, keeps your data in place, and stops charging for CPUs. You can also define a schedule to automatically stop and start your Autonomous Database, for more information click here.
Yes. ADB offers 30-day free trials. There is a sign-up process on oracle.com. For more information click here.
Yes. ADB offers a free service on Shared Exadata Infrastructure. There is a sign-up process on oracle.com. For more information click here.
Yes, Autonomous Database allows customer manages the encryption keys. More information is provided in the documentation, click here.
As part of our overall security approval process, Oracle uses an external company to perform penetration testing.
Oracle Autonomous Database protects against both external attacks and malicious internal users:
All data is encrypted at rest using transparent data encryption. Network connections from clients to ADB are also encrypted to provide the highest level of security.
Oracle automatically applies all security updates to ensure data is not vulnerable.
Customers are not given OS logons or SYSDBA privileges to prevent phishing attacking.
Additional in-database features such as Database Vault, Virtual Private Database and Data Redaction are also available.
Yes, data redaction is part of ADB.
Yes, the current version of ADB includes Database Vault. This can be combined with other PaaS offerings such Data Safe which is free to use with ADB to create a comprehensive security layer within ADB. Click here for more information
Oracle Data Safe provides a large selection of audit reports For more information click here.
The current SLA for ADB is 99.95% availability during any calendar month. For customers that need higher levels of availability, the Autonomous Data Guard feature provides failover protection, via a standby instance, with an SLA of 99.995%. You can monitor the availability metrics of your Autonomous Database from the console, click here.
To learn more about how to enable Autonomous Data Guard for disaster recovery, click here.
Yes. The Autonomous Data Guard feature enables a standby instance in the background which provides automated failover protection. For more information see here for ADW and see here for ATP.
The pillar document provides more information about the specific definitions of key terms relating to the "Service Commitment", see here (PDF).
Oracle is responsible for the service availability. Therefore, if the whole service goes down it is Oracles responsibility to get the service back online ASAP. Customers can create a standby database using Autonomous Data Guard, which provides automated data protection and disaster recovery for an Autonomous Database instance.
Yes, ADB provides the ability to clone a database and you can choose to clone either the full database or only the database metadata.
Yes it is possible to use Oracle Data Safe data masking capabilities with cloned instances of ADB. For more information click here.
Yes, Autonomous Database has a built-in web toolkit called Database Actions. This provides development tools, data tools, administration, and monitoring features for Autonomous Database. Using Database Actions you can run SQL statements, queries, and scripts in a worksheet. For more information, click here
You can connect your on-premises network to ADB using VPN or FastConnect.
Using Private connectivity to Autonomous Database Dedicated Infrastructure deployment is supported.
Yes, Private Endpoints are supported with ADB.
Yes, database links are fully supported in ADB.
ADB supports both regular TCP (non-wallet) and TCPS (wallet based) SQL*Net connections. Inbound database link connections to ADB Dedicated can be TCP or TCPS, however, outbound database link connections from ADB Dedicated can only be TCP based.
More information is available in the documentation click here.
Yes. Autonomous Database provides Oracle-managed heterogenous connectivity to non-Oracle Databases such as PostgreSQL, Amazon Redshift, Snowflake, MySQL, DB2, Teradata, SQL Server etc. More information is available in the documentation, click here.
Yes, directory objects are supported within ADB. This makes it even easier to migrate existing applications to ADB.
More information is available in the documentation, click here.
Yes. Oracle Rest Data Services (ORDS) is supported by Autonomous Database.
Yes, Autonomous Database supports Simple Oracle Document Access (SODA) for REST.
More information is available in the documentation, click here.
There are multiple ways to load data into ADB:
ADB is integrated with multiple object storage services for data loading. You can upload your source files to one of the supported object-stores and this is the recommended method for loading large data sets. SQL Developer also provides a data loading wizard that can load data from these object stores.
You can use Data Pump Import to load data from dump files. Data Pump Import is integrated with Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure Object Storage Classic, AWS S3, Microsoft Azure Blob Storage. You can upload your dump files to one of these object-stores and import from those dump files.
You can also use client-side tools like SQL*Loader, or your in-house scripts to load data from files residing on your client machines.
Another option is to use Oracle tools and cloud services like GoldenGate, ODI, GoldenGate Cloud Service, and Oracle BI Data Sync.
Any 3rd party ETL tool that can connect to ADB can also be used to load data.
Autonomous Database provides wizard-driven data loading tools for non-technical users and APIs for scripting.
Autonomous Database is able to load a wide range of file types:
Loading data from local files: You can add files in these file formats: AVRO, CSV, JSON, TSV, delimited TXT, XLS, XLSX, XML.
Loading data from cloud storage: You can load data from a cloud store (Oracle Object Storage, Amazon S3, Azure Blob Storage, Google Cloud Storage, and Wasabi Cloud Store) to a table in your Autonomous Database. The following file formats are supported: AVRO, CSV, JSON, Parquet, ORC, and delimited TXT.
Oracle Autonomous Database can synchronize metadata directly with OCI Data Catalog. The data catalog is a metadata management service that helps data professionals discover data and support data governance. Designed specifically to work well with Autonomous Database by providing an inventory of assets, a business glossary, and a common metastore for data lakes. For more information click here.
Yes, however, note that auto-indexing is not on by default. For more information, click here.
Yes, however, note that auto-partitioning is not on by default. For more information, click here.
Yes, customers can utilize nearly all the PL/SQL capabilities. For more information, click here.
Yes. Autonomous Database provides an easy way to efficiently setup access to these organized sources. Queries can take advantage of the partitioning structure to minimize scans and maximize performance. For more information click here.
Autonomous Database on Shared Infrastructure uses predefined maintenance windows to automatically patch your database. You can view maintenance and patch information and see details for Autonomous Database maintenance history. When you provision your database you can select a patch level. You can view the maintenance event history for details about past maintenance events, such as the title, state, start time, and stop time. For more information, click here.
With Dedicated Infrastructure deployments, you have the option to change the maintenance windows to control when the Exadata environments and the databases are updated.
Oracle operations will monitor patching and rollback a patch if it cannot be applied successfully according to basic sanity tests. However, there is always a chance that the adverse effect is only observable from the application. In that case, you will have to notify Oracle via a Service Request(SR).
No. ADB does not allow access to the operating system.
Yes. Oracle Autonomous Database uses a free tool called Cloud Premigration Advisor Tool (CPAT). This is a light-weight utility that analyzes the existing Oracle Database schemas and makes recommendations to ensure a successful migration to the Autonomous Database. For more information click here.
Oracle recommends using a logical migration approach to migrate existing Oracle Databases to Autonomous Database. For more information click here.
The main migration tool for migrating to ADB is Data Pump. You can export your schemas and import them into ADB using Data Pump. To sync up the additional/incremental changes on the source database during the export/import process you can use GoldenGate or GoldenGate Cloud Service to replicate those changes to ADB.
In the current release you cannot use physical migration methods like backup/restore, Data Guard, database clones, and transportable tablespaces to move your existing database to ADB.
Yes. You can use Data Pump to export the source schema, move the dump files to the object store, and use Data Pump Import to load them into your ADB database.
ADB uses Database Resource Manager and IO Resource Manager to isolate resources for all databases. CPUs, memory, and IO resources are not over-provisioned in ADB, this makes sure every customer gets their assigned amount of resources at all times.
This section includes a list of frequently asked questions that relate specifically to Oracle Autonomous Database on Shared Infrastructure.
Oracle Autonomous Database provides a fully-managed database that is tuned and optimized for different types of workloads: data warehousing ana analytics, transactional/mixed, APEX, and JSON. With Shared Infrastructure customers have a fully elastic database where Oracle autonomously operates all aspects of the database life cycle from database placement to backup and updates.
More information about Autonomous Database is available on oracle.com and via the documentation
Oracle uses stackoverflow.com for technical questions about Autonomous Database, click here. Please use the tag oracle-autonomous-db when you post a question.
Yes. There is a publicly available, personalized TCO report builder for Oracle Autonomous Data Warehouse which allows you to calculate the value of automation in three quick steps and see how much you can save with the Oracle Autonomous Data Warehouse. Click here for more information
Autonomous Database comes with 5 preconfigured database services, HIGH, MEDIUM, LOW, TP and TPURGENT. The services control the priority of the sessions when the system is under resource pressure and some control the parallel degree used. By default, queries will execute serially when connected to the TP, TPURGENT and LOW services.
Users can specify a parallel degree on an object or uses optimizer hints to trigger parallel execution to be used when connected to the TPURGENT services. Queries will be automatically executed in parallel when sessions are connected to the HIGH and MEDIUM services.
Autonomous Database configures parallelism out of the box based on the number of CPUs you provision. This means there is no need to explicitly configure parallelism.
Customers cannot use the features of the database In-Memory option. Internally, Autonomous Database on Shared Infrastructure uses some of the key features of Database In-Memory to optimize performance.
Yes, SQL Developer provides a migration wizards for AWS Redshift, MySQL, Microsoft SQL Server, Sybase Adaptive Server, and IBM DB2 (UDB). The migration wizards connect to the source database, exports the metadata and the data and imports them schema objects and data Autonomous Database. It also allows you to save the migration scripts and run them outside of SQL Developer anywhere you want. Click here for more information.
Yes, if your organization already owns Oracle Database software licenses then you can bring your existing database licenses to Autonomous Database. See Autonomous Database pricing for information on Bring Your Own License (BYOL) and other licensing options for Oracle Cloud Infrastructure cloud service pricing, click here.
Licenses for Oracle Advanced Analytics are not required for BYOL.
Licenses for Oracle Spatial and Graph are not required for BYOL.
This section includes a list of frequently asked questions that relate specifically to Oracle Autonomous Database on Dedicated Infrastructure.
Autonomous Database on dedicated infrastructure (ADB-D) is a deployment choice that enables customers to provision autonomous databases into their own dedicated Exadata cloud infrastructure, instead of a shared Exadata infrastructure with other tenants.
ADB-D provides the customer customization over operational polices, including software and hardware isolation for the highest levels of performance and security governance; it is well suited for customers wanting to deploy Oracle Autonomous Database in cloud with common enterprise lifecycle controls and especially ideal for customers who want a self-service capability via their own database cloud. ADB-D is available in the Oracle Cloud and in the customer’s data center with Exadata Cloud@Customer.
Autonomous Database cloud services offer two infrastructure choices, shared and dedicated:
With shared infrastructure (ADB-S), the simplest configuration, multiple customers share the resources of an Exadata cloud infrastructure. These customers can quickly get started with no minimum commitment, enjoying quick database provisioning and independent scalability of compute and storage. Shared infrastructure runs on Oracle Cloud Infrastructure.
With dedicated infrastructure (ADB-D), the customer must first subscribe to a dedicated Exadata cloud infrastructure that is isolated from other tenants, with no shared processor, memory, network, or storage resources. This infrastructure choice offers greater control of the software and infrastructure lifecycle, customizable policies for separation of database workload, software update schedules and versioning, workload consolidation, and availability policies. Dedicated infrastructure is available on Oracle Cloud Infrastructure and Exadata Cloud@Customer.
Both Autonomous Database infrastructure options ensure high availability, exceptional performance, and multi-level security.
ADB-S delegates all operational decisions to Oracle for the highest level of autonomous experience - think of a fully autonomous vehicle with no need for a steering wheel or cruise control. ADB shared (ADB-S) enables customers to quickly provision their own autonomous databases and become productive.
ADB dedicated (ADB-D), on the other hand, is more like an autonomous vehicle that still includes a steering wheel and cruise control. ADB-D offers greater control and isolation starting at the Exadata cloud infrastructure level, with customizable maintenance schedules, software update versions, backup retention periods, etc. ADB-D allows customers to group and separates out databases based on organizational structure and criticality of application workload. ADB-D is ideal for customers looking to deliver a self-service database capability within their own database cloud environment running either on the public cloud or in the customer’s data center. Using this model, customer fleet administrators can use the steering wheel and cruise control (customized operational policies) to tailor an operational plan for different parts of their organization, then the organization consumes via a self-service experience similar to the vehicle with no need for a steering wheel or cruise control.
You can run all your data warehousing (ADW-D), transaction processing or mixed workload (ATP-D) databases of any size, scale or criticality on ADB dedicated. As well as supporting databases that may require highest governance, consistent performance and operational controls.
With Exadata Cloud@Customer deployment, ADB dedicated is ideal for on-prem customers desiring Autonomous Database but cannot move to the public cloud due to data sovereignty, corporate policies, network latency and security requirements etc.
Yes, you can have a mix of ATP-D and ADW-D databases on the same ADB dedicated Exadata rack.
Not all features present in Oracle Database Enterprise Edition are available in ADB-D; for example, database administration features are not available. Please see Autonomous Database dedicated documentation for the complete list.
Autonomous Database on Exadata Cloud@Customer (or ADB-ExaC@C for short) is Autonomous Database on dedicated Infrastructure running on Gen 2 Exadata Cloud@ Customer for on-premises deployment. It is the same ADB dedicated cloud service as on Oracle Cloud Infrastructure except it runs in the customer’s data centers. This is for customers desiring Autonomous Database but cannot leverage the public cloud due to sovereignty laws, industry regulations, corporate policies, network latency and security requirements, or customers that have on-premises applications that are tightly coupled with databases running locally.
It is the same Autonomous Database dedicated cloud service running on 2 different platforms. Both services are managed via the same interface, OCI Console, CLI and REST APIs. They have the same feature set; however new features on these platforms will have different release dates.
The key differences are:
Oracle Autonomous Database is responsible for backup and restore operations, and the management of object storage and local Exadata storage. Backup and restore using customer managed storage (NFS and ZDLRA) are the customer’s responsibility.
Oracle Autonomous Database is responsible for patching both the Exadata and user databases (Dom0 and DomU); customers has the option to override the default patching schedule with their preferred schedule.
In the first release, customer must designate whether an ExaC@C rack is for Autonomous Database or Exadata Database. Supporting a mix of Autonomous Database and Exadata Database is a roadmap item for CY 2021.
X8 and X7 Exadata Infrastructure Quarter, Half and Full Racks are supported. See here for details about the capacities and characteristics of these systems.
Gen 2 Exadata Cloud at Customer Infrastructure Quarter, Half and Full Racks are supported.
Note: ADB are not available on Base System and Gen 1 Exadata Cloud at Customer Infrastructure. See here for details about the capacities and characteristics of these systems.
Exadata Infrastructure on an X8 Quarter Rack has 100 enabled CPU cores; therefore, it can support as many databases as it has CPU cores, i.e. 100 databases.
When ADB-D supports fractional OCPUs/overprovisioning, you will be able to have up to 10 databases running on a single CPU core, however you can only have a maximum of 200 databases within each Autonomous Container Database provisioned for High Availability deployment.
You can have up to 12 autonomous container databases with a maximum of 200 autonomous databases on Half and Full rack, and 100 autonomous databases for Quarter rack per container database for the high availability configuration.
See here for more info.
Fleet administrator is a logical service role (managed by IAM privileges) responsible for the creation and the management of Autonomous Exadata Infrastructure (AEI) and Autonomous Container Database (ACD) resources for dedicated deployments. On Exadata Cloud@Customer, the fleet administrator is also responsible for provisioning and managing Backup Destinations and Autonomous Exadata VM Cluster. These resources must be created before dedicated Autonomous databases can be created.
The logical role is materialized by granting IAM privileges to a group of users (a Fleet Administrator Group) to manage the AEI and ACD resources. Please see Fleet Administrator’s Guide to Autonomous Database Dedicated Deployments for more information.
Database Administrator is both a logical service user role (managed by IAM privileges) and a Database User role responsible for the creation, monitoring and management of Autonomous databases. In order to manage the Autonomous Database resource, the service role must also be able to at a minimum USE Autonomous Container Database resources, which must be visible to assign as the target for the ADB during provisioning.
Database Users are in essence application developers, users who can connect to and use an Autonomous Database to store and access the data generated by applications. Database Users are not managed by IAM like service users, rather they are managed by capabilities built natively into the Autonomous Database. A Database Administrator is an IAM service user who is also a special case Database User, a user with the highest level of ADB privileges.
The Database Administrator can create, connect and manages schema and user access to autonomous databases. The Database Administrator has the exact same responsibilities in ADB-D as in ADB-S.
Yes, you can use on-prem EM 13.3+ or the OCI Marketplace EM 13c Image to monitor both ADB Dedicated on OCI and Autonomous Database on Exadata Cloud@Customer
For more information, refer to the EM Cloud Control Administrator’s Guide for Oracle Autonomous Databases.
There are two components:
1. Infrastructure: subscribe to Exadata Cloud Infrastructure for Oracle Cloud Infrastructure deployment or Exadata Cloud at Customer Infrastructure for Cloud at Customer deployment
2.Database OCPUs: subscribe to hourly per active OCPU consumed, using either license included or BYOL license type. Billing happens monthly at an aggregate level, total of all active OCPUs, for each Exadata Cloud Infrastructure resource.
ADB-D on OCI pricing details can be found on the Autonomous Database pricing pages ( ATP / ADW). ADB on ExaC@C pricing details can be found on the Exadata Cloud@Customer pricing page
On OCI, this is defined at the Exadata Infrastructure level. On ExaC@C, this is defined at the Autonomous VM Cluster level. Hence today, you can only use one license type (License included or BYOL) on an Exadata rack until Multiple VM Clusters per rack is supported on ADB-D and ADB-ExaC@C resp.