Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
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-driving, 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.
Dedicated deployment is a deployment choice that enables you to provision autonomous databases into their own dedicated Exadata cloud infrastructure, instead of a shared infrastructure with other tenants. Autonomous Database on Dedicated Infrastructure is also available in customer's data centers with Exadata Cloud at Customer.
With Shared Infrastructure deployment, which is the simplest configuration, you share the resources of an Exadata cloud infrastructure. You can quickly get started with no minimum commitment, enjoying quick database provisioning and independent scalability of compute and storage.
All deployment options (Shared, Dedicated in Oracle Cloud and Dedicated Cloud@Customer) are available with Autonomous Transaction Processing and Autonomous Data Warehouse. Oracle Autonomous Data Warehouse provides a fully-managed database that is tuned and optimized for data warehouse workloads. Autonomous Transaction Processing enables businesses to safely run a complex mix of high-performance transactions, reporting, batch, and machine learning along with simpler and faster application development.
ADB is built upon the Oracle Database, therefore, applications and tools that support Oracle Database also support ADB. These tools and applications connect to the service using standard database connectivity such as SQL*Net or JDBC. Click here for more information.
Not all features present in Oracle Database Enterprise Edition are available in ADB; for example, database features designed for administration are not available. Please see Appendix B in both the Autonomous Data Warehouse documentation and Autonomous Transaction Processing documentation for the complete list.
The full list of data centers is shown here: Oracle Cloud Data Regions for Platform and Infrastructure Services.
Autonomous Databases comes with over 30 machine learning algorithms implemented as SQL functions that leverage the strengths of the Oracle Autonomous Database. Oracle Machine Learning algorithms perform all processing inside the Autonomous Database and can mine data tables and views, star schema data including transactional data, aggregations, unstructured data i.e. CLOB data type (using Oracle Text to extract tokens) and spatial data. Oracle Machine Learning for SQL functions take full advantage of database parallelism for model build and model apply and honor all data and user privileges and security schemes. Data scientists can collaborate to build, evaluate and deploy machine learning models using Zeppelin based Oracle Machine Learning Notebooks. Oracle Machine Learning models can be included in SQL queries, BI dashboards and embedded in real-time applications. See Oracle Machine Learning for more information.
In addition to the Oracle Machine Learning algorithms, the Autonomous Database provides an extensive library of analytic and statistical SQL functions. Additionally, insights and predictions discovered in the Autonomous Database can be further investigated, analyzed and included in Oracle Analytics Cloud dashboards and other BI tools and Applications.
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 are described on ADB's pricing page Note: For BYOL, it is possible to seamlessly transition from 16 or fewer OCPUs to greater than 16 OCPUs. The only requirement is that the your BYOL must include RAC when scaling beyond 16 OCPUs. Click here for more information.
Yes. The only requirement is that your BYOL must include RAC when scaling beyond 16 OCPUs. Click here for more information.
This document describes the licensing requirements for ADB.
One OCPU is required to do any work, but the compute portion of the service instance can be turned off and billing for compute will be halted. Billing for storage continues as long as the service instance exists.
Yes, ADB does support per-second billing although certain restrictions apply. There is more information available here
The only things needed for BYOL are: Multitenant and when using more than 16 OCPUs, RAC. The high availability option (coming soon) will require Active Data Guard as well.
No, you cannot use any other storage than Exadata.
However, for Autonomous Database Dedicated Infrastructure deployments, ‘Oracle Cloud Infrastructure – Database Exadata Infrastructure’ which includes Exadata storage should be selected instead of ‘Oracle Autonomous Database - Exadata Storage’.
No, you cannot use any other storage than Exadata.
No, you must specify the initial storage required for your database but ADB is elastic, so it is possible to grow or shrink your database as needed.
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.
No, in the current version there are no customer-managed keys. Oracle manages the keys.
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 using the client credentials wallet. Using client credential wallets includes both server and client-side authentication and provides 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
The database instance will be dropped the moment the service is terminated. However, the database is restorable for up to 60 days, as legally required and documented in the Cloud Hosting and Delivery Policies. After that, the data is gone and cannot be recovered. Click here for more information.
Yes. it is now possible to specify an access control list that blocks all IP addresses that are not in the list from accessing the database. Once an access control list is set then that specific Autonomous Database only accepts connections from addresses in the access control list and rejects all other client connections. By default, when there is no network access control list specified the database is accessible from any IP address. Click here more information
Yes. On the Database Connection form, it is now possible to select type of wallet that will be generated:
Instance Wallet - provides a database-specific wallet with access to a single database only.
Regional Wallet - contains connection details for all ADBs within a given tenant-region.
Note that the instance (database-specific) wallet is the recommended option for applications where the connection is to only one system. Click here more information.
(Shared Infrastructure only)
Yes. This new wallet rotation feature makes it easy for customers to invalidate existing client certification keys for a specific ADW/ATP instance or for all Autonomous Database instances within a region. Click here more information.
(Shared Infrastructure only)
Autonomous Database demonstrates its HIPAA fitness through an additional attestation prepared in accordance with AICPA SSAE 18, AT-C sections 205 and 315. For more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes. Autonomous Database has achieved SOC 1 and SOC 2 compliance. SOC was created because of the rise of cloud computing and outsourcing of functions to service organizations. Liability concerns caused a demand in assurance of confidentiality and privacy of information processed in the cloud. For more information, click here.
Yes. Autonomous Database has achieved ISO27001 compliance. For more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes. Autonomous Database has achieved ISO27017 compliance. For more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes. Autonomous Database has achieved ISO27018 compliance. For more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes, database links are fully supported in ADB.
For Shared Infrastructure ADB deployments the target database must be configured to use TCP/IP with SSL (TCPS) authentication. ADB on Dedicated Infrastructure 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.
Yes. Autonomous Database supports connections that are enabled via Oracle Database Gateway. Database Gateways are designed for accessing non-Oracle Databases such as DB2, Teradata, SQL Server etc. More information is available in the documentation for ATP and ADW.
Yes, directory objects are supported within ADB. This makes it even easier to migrate existing applications to ADB.
Yes. Autonomous Database has enabled a core set of functionality for property graphs.
Yes. Autonomous Database has enabled the core set of spatial functionality including the native spatial type, index, and associated core analysis operators and functions.
Yes. Autonomous Database supports Oracle Text. This means it’s possible to use standard SQL to index, search, and analyze text and documents stored in the Oracle Autonomous Database.
Yes. Autonomous Database does include Oracle Application Express (APEX).
Yes. Oracle SQL Developer Web is included with Oracle Autonomous Database.
Yes. Oracle Rest Data Services (ORDS) is supported by Autonomous Database.
Yes, Autonomous Database supports Simple Oracle Document Access (SODA) for REST.
Yes, Autonomous Database supports partitioned external tables. This provides ability to query multiple data files in the Object Store as a single external table where the Object Store files can be represented as multiple logical partitions.
(Shared Infrastructure only)
Yes, Autonomous Database supports hybrid partitioned tables. This provides ability for a query to access both internal data and multiple data files in the Object Store as single logical table.
(Shared Infrastructure, 19c only)
Yes. The Oracle Architecture Center contains reference architectures, solution playbooks to help you design and implement IT topologies for specific business scenarios. For more information visit the Oracle Architecture Center for more information.
The current SLA for ADB is 99.95% availability during any calendar month. For customers that need high availability, Autonomous Data Guard provides failover protection.
The pillar document provides more information about the specific definitions of key terms relating to the "Service Commitment", see here (PDF).
A full back up will still happen. However, once the service has been stopped there is no need to do incremental backups because the database is not active.
The restore process is very simple - select a specific point in time to restore via the management console.
No, you cannot restore an ADB backup into another cloud service. You can export an ADB database to an object store and then import into another service.
No, ADB backups can only be used to restore and recover to the same database. However, customers have the ability to clone a database and can choose to clone either the full database or only the database metadata.
No, the manual backup, which you must move to your object store bucket, can only be used by ADB. You can use the manual backup functionality for cases like backing up before a large data load.
Note, if you initiate a restore operation ADB may decide to use your object store backup rather than one of its automatic backups – if it will be faster to restore.
Oracle is responsible for the service availability. Therefore, if the whole service goes down it’s Oracles responsibility to get the service back online ASAP.
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.
Oracle Data Safe provides a large selection of audit reports For more information click here.
You can connect your on-premises network to ADB using FastConnect Public Peering and private endpoints
Using Private connectivity to Autonomous Database Dedicated Infrastructure deployment is supported.
Third party drivers must support Oracle Wallets and certificates. With ADB on Dedicated Infrastructure, both regular TCP and TCPS (Oracle Wallets and Certificate) connections are supported. Details on connecting to ATP with via OCI, ODBC and JDBC can be found in the documentation. Details on connecting to ADW with via OCI, ODBC and JDBC can be found in the documentation.
Yes, Private Endpoints are supported with ADB.
Application servers should be provisioned in the same Oracle Cloud Infrastructure Region.
Yes, Oracle data integration tools are configured to work with ADB.
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 these object-stores and use the PL/SQL API DBMS_CLOUD to load data into your database. ADB supports Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure Object Storage Classic, AWS S3, and Azure Blob Storage for loading data. 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 using the security credentials wallet can also be used to load data.
For large data sets, uploading the source files to Oracle Object Storage and loading from the Object Store will most likely be faster than other options.
But you can use the other data loading options too depending on your use-case and requirements. Click here for more information.
Yes, both GoldenGate on-premises and GoldenGate Cloud Service support ADB as a target system only.
ADB cannot be used as a source system for GoldenGate. Please see the GoldenGate documentation for configuring GoldenGate for replication to ADB.
ADB gathers optimizer statistics automatically if you are using the PL/SQL API DBMS_CLOUD, or if the tools and scripts you use to load data are using direct path loads. If you are using conventional DML operations to load data, then you will need to gather optimizer statistics yourself or let the nightly statistics gathering job gather statistics for objects that have stale statistics.
See the FAQ for both Autonomous Data Warehouse and Autonomous Transaction Processing for more details.
Yes. Autonomous Database can now read Avro files and parse the schema within the file to create the columns with the appropriate Oracle Database data types. Avro files may include complex types – like arrays, structs, maps and more; ADW supports avro files that contain Oracle data types. Click here for more information.
Yes. Autonomous Database can now read Parquet files and parse the schema within the file to create the columns with the appropriate Oracle Database data types. Click here for more information.
Yes. Autonomous Database can now read ORC files and parse the schema within the file to create the columns with the appropriate Oracle Database data types.
Yes. If source files reside on the Oracle Cloud Infrastructure Object Storage it is possible to use Oracle Cloud Infrastructure pre-authenticated URIs. When a pre-authenticated request is created, a unique URL is generated. This unique URL can then be provided to users, partners, or third parties to access the Object Storage resource target identified in the pre-authenticated request.
ADB supports all the usual schema models such star schema, snowflake and 3NF. The same basic design concepts still apply when designing data warehouse/data mart schemas and schemas to support OLTP applications. The main difference between ADB and a non-autonomous Oracle Database is that you do not need to specify the physical properties of tables (e.g., partitioning, indexes, compression, storage details etc).
There are no predefined data models in the ADB. You create your own schema, tables and other database objects as needed.
You can use SQL Data Modeler to design a new logical model and physical model, then generate the required DDL script(s) to implement your model in ADB. Click here for more information.
The precise details of how autonomous capabilities are implemented inside ADB are considered proprietary and internal.
Yes, you can create any constraint just like you do in a regular Oracle Database.
Yes, you can create secondary indexes, partitioned tables, or materialized views in ADB.
For specific guidance on when this should be done, please see the specific FAQ sections for Autonomous Data Warehousing and Autonomous Transaction Processing.
Yes, where the database version is 19c which is required for Auto-Indexing. Note that auto-indexing is not on by default.
Yes, customers can utilize nearly all the PL/SQL capabilities. The small set of limitations is listed in the appendices of the ATP and ADW documentation.
For Shared Infrastructure deployments - No. Oracle patches ADB in maintenance windows. Currently, users cannot change the patching schedule. The date-time for the next scheduled maintenance is shown on the OCI console page for each instance.
With Dedicated Infrastructure deployments, you have the option to change the maintenance windows to control when the Exadata environments and the databases are updated.
You cannot rollback patches yourself. Only Oracle operations can rollback a patch. Oracle operations will monitor patching and rollback if a patch 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).
Yes, ADB does have auto-scaling and this enabled by default when you create a new instance. You can select auto scaling during provisioning or later using the Scale Up/Down button on the Oracle Cloud Infrastructure console. Click here for more information
No. ADB does not allow access to the operating system.
ADB provides the following monitoring consoles:
Oracle Management Cloud - supports monitoring Autonomous Databases via its Oracle Database Management console. This provides both monitoring and alerting for your Autonomous Database instances. The Performance Hub page provides both high-level and detailed performance metrics for your Autonomous Database instances. Use of Oracle Management Cloud is included as part of your Autonomous Data Warehouse and Autonomous Transaction Processing services. Click here for more information.
Performance Hub - provides real-time view of performance data directly on the OCI ADB console.
Performance Hub contains the following:
These features provides a simple one-click way to access the same information as found in EM Express, Oracle Management Cloud (OMC), and SQL Developer Web. The most likely target audience for this new feature will be cloud DBAs who manage a range of ADB instances within a single tenant and need a simple and fast way to monitor the performance of individual ADB instances directly from within the OCI Console. Click here for more information.
ADB Service Console - is a web-based service console for each database. Using this console, you can look at performance metrics like CPU storage utilization and monitor database activity. This console also provides real-time SQL monitoring for current and past SQL statements. Click here for more information.
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.
Starting an ADB instance is basically opening up your database. It is completed in seconds.
No. ADB provides a simple resource manager plan out of the box.
Yes. Autonomous Database allows customers to change the CPU/IO shares for the consumer groups within their ADB instance (high, medium, low, tp, tpurgent).
This allows for use cases where, for example, a workload running in the LOW resource group requires a greater share of CPU/IO resources.
No. Any user can connect to any database service of their choice - providing they have a valid database username with the associated password.
Yes. Licenses to use the Database Monitoring features of Oracle Management Cloud are in included in your subscription to Autonomous Data Warehouse and Autonomous Transaction Processing.
Since an ADB database has some restrictions on the object types and Oracle Database Options you need to use a logical migration method rather than a physical one.
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.
No, RMAN restore into ADB is not supported. You need to use one of the supported migration methods outlined above.
No, the original export/import methods are not supported in ADB. You need to use one of the supported migration methods outlined above or in the documentation.
You can use Data Pump export utility to unload data from ADB. For smaller data sets you can also use any SQL client tool to spool your data to a text file.
Yes. Oracle XML DB features are now supported in Autonomous Database. To ensure the security and the performance of Autonomous Data Warehouse and Autonomous Transaction Processing, some Oracle XML DB features are restricted so refer to the documentation for a complete list of supported features.
Yes. Oracle Autonomous Database Schema Advisor is a light-weight utility that analyzes the on-premise or cloud Oracle Database schemas for the suitability of migration to the Autonomous Database. The Advisor discovers the schema objects and performs deep analysis to highlight is any differences exist when the object gets created on Oracle Autonomous Data Warehouse or Oracle Autonomous Transaction Processing database.
The Advisor will run on pre-existing Schema and generates a report that highlights:
For more information click here.
If your ADB instance is using Database 19c then Automatic Indexing is available, however, it is not turned on by default.
No, in the current release ADB does not create materialized views automatically.
No, ADB configures the database memory (SGA and PGA) based on the number of CPUs you provision. Memory scales linearly with the number of CPUs.
IO throughput depends on the number of CPUs you provision and scales linearly with the number of CPUs. Scaling the service is quick and easy in ADB, if you need more IO throughput you can add more CPUs online in a few seconds.
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.
ADB may decide to open a database on a single node or multiple nodes. ADB does not expose these details because it is not necessary to know about this level of detail.
ADB decides where to run a query and where to spawn the parallel processes, it may be on a single node or multiple nodes. Customers do not need to know about these implementation details since ADB controls this automatically.
Yes it is possible to change the CPU/IO shares for the consumer groups within their ADB instance (high, medium, low, tp, tpurgent). This allows for use cases where, for example, a workload running in the LOW resource group requires a greater share of CPU/IO resources than HIGH and MEDIUM.
The 'Set Resource Management Rules' pop-up form on the administration section of the service console has been extended to allow the modification of CPU/IO shares across the different resource groups. It is also possible to change the resource shares within a script, application call and/or via a SQL prompt using the cs_resource_manager package.
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 either data warehouse workloads or transactional/OLTP workloads. With Shared Infrastructure multiple customers share the resources of a single Exadata Cloud Infrastructure.
Yes, Oracle and 3rd party tools and applications that support Oracle Database also support Oracle Autonomous Database on Shared Infrastructure. These tools and applications connect to the service using standard database connectivity such as SQL*Net or JDBC. Click here for more information
Oracle Cloud Customer Connect is a community gathering place for our cloud customers to interact and collaborate on common goals and objectives. It also has a technical forum. Click here for more information about ADW and Click here for more information about ATP.
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
Customers cannot use the features of the database In-Memory option. Internally, ADB on Shared Infrastructure uses some of the key features of Database In-Memory to optimize performance.
Yes. When you enable Autonomous Data Guard on ADB, the system creates a standby database that stays "connected" to the primary database and automatically refreshes its data from the primary database.
If your primary database goes down, Autonomous Data Guard converts the standby database to the primary database with minimal interruption. After failover completes, Autonomous Data Guard automatically creates a new standby database.
Yes. The Architecture Center has been updated to include a new series of data warehouse patterns. Currently, the following patterns are available (note: more patterns are being built and will be added shortly):
- Enterprise Data Warehouse with HCM data enrichment
- Departmental data warehousing - an EBS integration example
- Departmental data warehousing/data marts - consolidate spreadsheets
- Enterprise data warehousing - an integrated data lake example
- Set up a data science environment that uses Oracle Machine Learning
Licenses for Oracle Advanced Analytics are not required for BYOL. However, note that, currently, R Enterprise is not included or supported with ADW.
Yes. Support for both R and Python is on the roadmap.
There are links to tutorials and videos for OML within the Getting Started section on the OML documentation. Click here for more information
The Oracle ML Notebook web tool contains a range of example notebooks covering the most commonly used data mining features. These are all prepared and managed by the Machine Learning product management team. Additional examples are also available via GitHub, click here for more information.
ADB configures parallelism out of the box based on the number of CPUs you provision. This means there is no need to explicitly configure parallelism.
If required, you can include parallelism hints in your queries and enable those hints by setting a database parameter. Oracle recommends using the default settings for optimum performance.
You have complete control over the reject limits from within the SQL Developer data loading wizard and using the command-line approach. This provides control for whether a load fails with the very first row being rejected or whether a specific number of errors can be tolerated and possibly reviewed later. The default reject limit is set to zero to ensure highest level of data completeness. Click here for more information.
ADB 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 TP and TPURGENT services. Queries will be automatically executed in parallel when sessions are connected to the HIGH and MEDIUM services.
Yes, Autonomous Database allows you to switch network access type. You can perform an in-place switch from public endpoint to private endpoint (and vice versa).
Yes, SQL Developer provides a migration wizard for AWS Redshift as it does for other databases. This wizard connects to the source Redshift database, exports the metadata and the data to AWS S3, and imports them into ADW. 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, SQL Developer provides a migration wizard for Teradata. This wizard connects to the source Teradata database, exports the metadata and the data to files on local storage. These can then be moved to Oracle Object Store and imported into ADB on Shared Infrastructure. The migration wizard allows you to save the migration scripts and run them outside of SQL Developer as needed. Click here for more information.
Yes, SQL Developer provides a migration wizard for DB2. This wizard connects to the source DB2 database, exports the metadata and the data to files on local storage. These can then be moved to Oracle Object Store and imported into ADB on Shared Infrastructure. The migration wizard allows you to save the migration scripts and run them outside of SQL Developer as needed. Click here for more information.
Yes, SQL Developer provides a migration wizard for Sybase. This wizard connects to the source Sybase database, exports the metadata and the data to files on local storage. These can then be moved to Oracle Object Store and imported into ADB on Shared Infrastructure. The migration wizard allows you to save the migration scripts and run them outside of SQL Developer as needed. Click here for more information.
Yes, SQL Developer provides a migration wizard for MySQL. This wizard connects to the source MySQL database, exports the metadata and the data to files on local storage. These can then be moved to Oracle Object Store and imported into ADB on Shared Infrastructure. The migration wizard allows you to save the migration scripts and run them outside of SQL Developer as needed. Click here for more information.
Yes, SQL Developer provides a migration wizard for SQL Server. This wizard connects to the source SQL Server database, exports the metadata and the data to files on local storage. These can then be moved to Oracle Object Store and imported into ADB on Shared Infrastructure. The migration wizard allows you to save the migration scripts and run them outside of SQL Developer as needed. Click here for more information.
As a general rule, any business intelligence tool that connects to the Oracle Database using an OCI 'thick' connection or a JDBC thin connection with support for wallets should work with ADB on Shared Infrastructure. Oracle has partnered with many 3rd party developer to test and certify tools and connectivity solutions. There is more information here for the most popular tools.
Yes, ADB supports Application Continuity which enhances the fault tolerance of systems and applications that use an Oracle Autonomous Database.
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 shared (ADB-S) offers an ultra-simple and elastic database deployment in the cloud, it enables customers to quickly provision their own autonomous databases and become productive with new application development. ADB-S delegates all operational decisions to Oracle for the highest level of Autonomous experience, think of an autonomous vehicle with no need for a steering wheel or cruise control.
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 separate 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.
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.
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.