Your search did not match any results.
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, increase or decrease either 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.
With serverless deployment, 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.
Currently both deployment options are available with Autonomous Transaction Processing. Autonomous Data Warehouse only supports “Serverless” deployment.
For questions specifically about Autonomous Transaction Processing – Serverless, click here. For questions specifically about Autonomous Transaction Processing – Dedicated, click here. For questions specifically about Autonomous Data Warehouse, click here
ADB is built upon the Oracle Database; 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.
In the current release up to 128 CPUs and 128TB can be provisioned from the cloud console. Customers requiring more than these need to call their Oracle account team.
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 Autonomous Data Warehouse or Autonomous Transaction Processing documentation for the complete list.
As of June 2019, ADB is available in Ashburn (Virginia, US), Phoenix (Arizona, US), Frankfurt (Germany), London (UK) and Toronto (Canada), Tokyo (Japan) and Seoul (South Korea) data centers.
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 SQL Analytical and SQL Statistical 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.
Pricing details can be found on the Autonomous Data Warehouse or Autonomous Transaction Processing page of cloud.oracle.com
You can provision a License-included version of ADB, or you can provision a 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 you must BYOL RAC when scaling beyond 16 OCPUs. Click here for more information.
Yes. The only requirement is that you must BYOL 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.
The only things needed for BYOL are: Multitenant and RAC (when using more than sixteen OCPUs). The standby option (not yet available) will require Active Data Guard as well.
No, you cannot use any other storage than Exadata.
However, for Autonomous Transaction Processing dedicated 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, the customer must specify the initial storage they require for their database but ADB is elastic, so that customers can grow or shrink their database as needed.
You can create users, roles, etc. as before. However, note that certain the commands are blacklisted, and the list of these commands is provided in the documentation.
No, in the current version there are no customer-managed keys. Oracle manages the keys.
As part of the security approval process, an external company performs penetration testing.
Oracle Autonomous Database protects against both external attacks and malicious internal users:
All data 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 to known attack vectors
Customers are not given OS logons or SYSDBA privileges to prevent phishing attacking.
Additional in-database features like Virtual Private Database and Data Redaction are also available.
Yes, data redaction is part of ADB.
In the current version of ADB, the on-premises version of Audit Vault will not work because of the need to install an agent on the server running ADB. Since there is no access to the underlying O/S it is not possible to install additional software components such as agents. There is a PaaS offering for Audit Vault (via Oracle Managed Security Services), however, this has not been certified as working with ADB by the security PM team.
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 that specific Autonomous Database only accepts connections from addresses on 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
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.or more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes. Autonomous Database has achieved ISO27017 compliance.or more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes. Autonomous Database has achieved ISO27018 compliance.or more information visit the following page on cloud.oracle.com - Oracle Cloud Compliance and Security.
Yes,database links are fully supported in ADB.
For serverless ADB deployments the target database must be configured to use TCP/IP with SSL (TCPS) authentication. ATP Dedicated does not support TCP/IP with SSL (TCPS) encrypted connections for DB Links.
Yes,directory objects are supported within ADB. This makes it even easier to migrate existing appications to ADB.
Autonomous Database has enabled the core set of Spatial functionality including the native spatial type, index, and associated core analysis operators and functions.
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. SODA for REST uses the representational state transfer (REST) architectural style to implement Simple Oracle Document Access (SODA).
The current SLO for ADB is 99.95% availability. There is an Extreme Availability option on the short roadmap, which will offer 99.995% availability.
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 import it into another service.
No, ADB backups can only be used to restore and recover the same database. However, customers have the ability to clone a database and they can choose to clone either the full database or only the database metadata.
No, the manual backup you take 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, for example. 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- within a region and across regions in the future when DR is available. Therefore, if the whole service goes down it’s Oracles responsibility to get the service back online ASAP.
Oracle does not provide RTO/RPO SLOs. ADB uses the fastest restore method (flashback database, automatic and manual backups) depending on the point-in-time specified by the customer for the recovery operation.
No ADB does not currently provide a DR configuration. However, it is on the short-term roadmap.
Yes, ADB provides the ability to clone a database and you can choose to clone either the full database or only the database metadata.
Currently no, but it is on our long-term roadmap.
Audit trail is available through service REST call invocations. Database audit trails can also be retrieved. Future release will include detailed auditing through additional security services.
You can connect your on-premises network to ADB using FastConnect Public Peering. Private connectivity to ADB is on the roadmap.
Using Private connectivity to Autonomous Database dedicated deployment is also supported. Private connectivity to ADB serverless deployment is on the roadmap.
Third party drivers must support Oracle Wallets and certificates. With ATP-D, both regular TCP and TCPS (Oracle Wallets and Certificate) connections are supported.
Details on connecting to ADB with via OCI, ODBC and JDBC can be found in the documentation.
Not yet for serverless ADB deployments but they are on the short-term roadmap.
Yes, private IPs are supported with ATP-Dedicated
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. DBMS_CLOUD to load data is not applicable for ATP-D because DBMS_CLOUD is not available on ATP-D.
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 Data Integration Platform Cloud.
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 there will be faster than other options if you are using the same region for your ADB instance and your object store files. 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 or the GoldenGate Cloud Service 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. 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.
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 they 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.
For serverless deployments - No. Oracle patches ADB in maintenance windows. Currently, users cannot change the patching schedule.
With dedicated deployments, customer has the option to change the maintenance windows on when their Exadata environments and the databases are updated. Please see Fleet Administrator’s Guide to ATP Dedicated Deployments for more information.
Customer themselves cannot rollback patches, only Oracle operations can. 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, customer will have to notify Oracle via an SR.
Yes, ADB (serverless) does have auto-scaling. 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
ATP-D does not have auto-scaling support.
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.
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 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 Data Warehouse. 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.
No, in the current release ADB does not create indexes or materialized views automatically. However, Automatic Indexing will be available with Oracle Database 19c.
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 RAC concepts.
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, 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 spefically to Oracle Autonomous Data Warehouse
Oracle Autonomous Data Warehouse provides a fully-managed database that is tuned and optimized for data warehouse workloads.
As a fully-managed service, all database lifecycle operations are managed by the service: the creation of the data warehouse database, the backups of the database, the patching and the upgrading of the database, and the growing or the shrinking of the database. <
Oracle Autonomous Data Warehouse is fully elastic: You simply specify the number of OCPUs and the storage capacity in TB's for the data warehouse. At any time, you may scale, increase or decrease either the OCPUs or the storage capacity.
Oracle Autonomous Data Warehouse is built upon the Oracle Database, so business intelligence applications and tools that support Oracle Database also support Oracle Autonomous Data Warehouse Cloud. These tools and applications connect to the service using standard database connectivity such as SQL*Net or JDBC. Click here for more information
The North America Information Management Platform Team has hosted a detailed hands-on lab for ADW which covers everything customers need to get started. 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. Cloud Ops will use the forum to update customers about patching schedules and details of patch contents. Click here for more information
Yes. There is a publicly available, personalized TCO report builder for Oracle Autonomous Data Warehouse Cloud available via cloud.oracle.com. The report builder allows you to calculate the value of automation in three quick steps and see how much your customer can save with the Oracle Autonomous Data Warehouse. Click here for more information
In the current release up to 128 CPUs and 128TB can be provisioned from the cloud console. Customers requiring more than these need to call their Oracle account team.
Customers cannot use the features of the database In-Memory option. ADW uses Database In-Memory option features like in-memory columnar flash cache under the covers.
Yes, they can use the in-database SQL data mining part of OAA but note that, currently, R Enterprise is not included with ADW.
ADW supports all the usual schema models such star schema, snowflake and 3NF. The same basic design concepts still apply when designing the data warehouse/data mart schema. The main difference between the ADW 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.).
The CREATE INDEX statement is supported in ADW. Howver, ADW uses other techniques such as Exadata smart scan and storage indexes to quickly locate data. ADW will automatically create, maintain and delete indexes in certain cases such as with enforced and enabled primary key constraints.
Yes, users can create any constraint just like they do in a regular Oracle Database.
The in-database analytic SQL features and the in-database data mining features of Advanced Analytics included with ADW. The Enterprise R part of Advanced Analytics is not included with ADW.
Yes, customers can manually create any type of partitioned table in ADW. No automatic partitioning is done. Instead, ADW creates tables using the column store format which is automatically managed by the database and provided very fast access to data.
ADW configures parallelism out of the box based on the number of CPUs you provision. So, you do not need to explicitly configure parallelism. But, if you have to 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.
Users have control over the reject limit (within the SQL Developer data loading wizard and the command-line approach) to control 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.
SQL in-database data mining is already part of ADW. Support for R is on the roadmap but no dates or timescales. The In-database SQL data mining features are part of ADW. We have published a whole series of examples on GitHub linked to the new SQL worksheet tool Oracle ML. These are all prepared and managed by Charlie Berger in the Advanced Analytics team. Click here for more information.
There are links to tutorials and documentation for OML on the ADW page of cloud.oracle.com. Click here for more information
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
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 ADW. Oracle has partnered with many 3rd party developer to test and certify tools and connectivity solutions with ADW. This includes (but is not limited to) MicroStrategy, Looker, Clik, Informatica, Tableau, Cognos, Alteryx, Power BI, Data Virtually and WanDisco. Click here for more information.
This section includes a list of frequently asked questions that relate spefically to Oracle Autonomous Transaction Processing
Oracle Autonomous Transaction Processing is one of a family of cloud services built on the self-driving, self-securing, and self-repairing Oracle Autonomous Database. Autonomous Transaction Processing (ATP) enables businesses to safely run a complex mix of high-performance transactions, reporting, batch, and machine learning along with simpler and faster application development on the Oracle Database on Exadata in the cloud.
ATP automates patching, upgrades, and tuning without human intervention or downtime. Users can instantly create new ATP databases and easily convert existing databases, dramatically reducing costs and time to market.
ATP is also fully elastic: you can instantly and independently, scale the compute or storage, so only the required resources are provisioned at any given time, decreasing runtime costs.
ATP offers two deployment options: serverless and dedicated. With dedicated, a customer's ATP databases are provisioned on a dedicated Exadata Cloud Infrastructure, with no shared resources, isolated from other tenants. With serverless, multiple customers share the resources of a single Exadata Cloud Infrastructure.
In the current release up to 128 CPUs and 128TB can be provisioned from the cloud console. Customers requiring more than these should contact their Oracle account team.
Not all features present in Oracle Database Enterprise Edition are available in ATP; for example, database features designed for administration are not available. You can find a complete list of the features that are not supported in the ATP documentation.
Yes, ATP has a technical forum on Oracle Cloud Customer Connect. Customer Connect is a community-gathering place for our cloud customers to interact and collaborate on common goals andobjectives. Cloud Ops will use the forum to update customers about patching schedules and details of patch contents.
ATP is built upon the Oracle Database; applications and tools that support Oracle Database also support ATP. These tools and applications connect to the service using standard database connectivity such as SQL*Net or JDBC.
Note, all communications with the database are encrypted and users are required to download a wallet file after creating the ATP serverless instance, which contains the necessary credentials, to establish a connection.
ATP-D supports both regular TCP (no wallet required) and TCPS encrypted (wallet required) connections.
Click here for more information.
Application servers should be provisioned in the same Oracle Cloud Infrastructure Region.
ATP 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. There is also a limit on the number of concurrent sessions that can execute on the HIGH and MEDIUM services.
Yes, customers can create any constraint just like they do in a regular Oracle Database.
Yes, customers can create both B-Tree or Bitmap indexes on any table.
Yes, on ATP-D the database version is 19c which is required for Auto-Indexing. In ATP-D, Auto-Indexing is on by default. Support for 19c / Auto-Indexing on ATP-S is on the roadmap.
Yes, customers can create any type of partitioned table.
No, not in the initial release of the services.
Yes, customers can create any materialized view.
No, not in the initial release of the services.
Yes,customer can utilize all of Oracle’s advanced SQL and PL/SQL capabilities.
By default, ATP does not use parallel execution when sessions connect on the TP, TPURGENT or LOW database services. However, you can include parallelism hints in your SQL when connected to TP and TPURGENT. For longer running reports we recommend using the MEDIUM service where queries will be automatically parallelized.
No, data is not automatically compressed in ATP due to the additional overhead a compressed data format has on DML operations. However, users can specify a compression attribute on any table or partition and ATP will honor that attribute.
This section includes a list of frequently asked questions that relate spefically to Oracle Autonomous Database Dedicated deployments
Autonomous Database dedicated deployment (ADB-D) is a deployment choice that enables customers to provision autonomous databases into their own dedicated Exadata cloud infrastructure, instead of a shared infrastructure with other tenants. Dedicated deployment 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 Database in cloud with common enterprise lifecycle controls and especially ideal for customers who want a private self-service capability via their own private database cloud within the public cloud.
Autonomous Database cloud service now offers two deployment choices, serverless (ADB-S) and dedicated (ADB-D). With serverless deployment, 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.
With dedicated deployment, 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 deployment 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. Both deployment options ensure high availability, exceptional performance, and multi-level security.
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-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 especially ideal for customers looking to deliver a self-service database capability within a private database cloud environment running on the public cloud. 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 transaction processing or data warehouse or mixed workload databases of any size, scale or criticality on ADB-D. As well as supporting application databases that may require highest governance, consistent performance and operational controls.
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 Transaction Processing documentation and Autonomous Data Warehouse documentation for the complete list.
In the first release of ADB-D, only Exadata Infrastructure Quarter Rack containing 2 compute nodes and 3 Exadata storage servers is offered. This gives a total capacity of 92 OCPU and 107TB of effective database storage. Half Rack and Full Rack will be available in future ADB-D releases.
You can have up to 12 autonomous container databases with a maximum of 200 autonomous databases on each 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. These resources must be created before 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 ADB 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.
There are two components:
1. Subscription to Exadata Cloud Infrastructure, the minimum term is one month.
2. Database software usage, subscribed to hourly per active OCPU consumed. Billing happens monthly at an aggregate level, total of all active OCPUs, for each Exadata Cloud Infrastructure resource.
Pricing details can be found on the Autonomous Database page at cloud.oracle.com