13.2 Autonomous AI Database: Workload Types, Deployment Options, Services & Connectivity
Key Takeaways
Autonomous AI Database supports four workload types: Lakehouse, Transaction Processing, JSON Database, and APEX Service.
Every Autonomous AI Database provides five predefined services (tpurgent, tp, high, medium, and low) for all workload types.
The tpurgent service has the highest priority and supports manual parallelism, while tp and low do not run with parallelism.
ECPUs are the billing metric for all new and existing Autonomous AI Database deployments, and OCPU is a retired legacy metric.
Autonomous AI Database on Dedicated Exadata Infrastructure is built from Exadata infrastructure, Autonomous Exadata VM Clusters, Autonomous Container Databases, and the databases inside them.
What "Autonomous" Means
Oracle Autonomous AI Database (formerly Autonomous Database) runs on Exadata infrastructure and automates the work that DBAs usually do by hand: provisioning, configuration, tuning, indexing, patching, backups, and scaling. You choose a workload type, the compute and storage size, and the network access; Oracle handles the rest. This is the main contrast with Base Database Service, where you decide when to patch and how to configure the database.
Workload Types
| Workload type | Product name | Optimized for |
|---|---|---|
| Lakehouse | Autonomous AI Lakehouse (formerly Autonomous Data Warehouse) | Analytics: data marts, data lakes, and lakehouses |
| Transaction Processing | Autonomous AI Transaction Processing | Transactional, analytical, and batch workloads running concurrently |
| JSON Database | Autonomous AI JSON Database | JSON-centric document applications |
| APEX Service | APEX Service | Low-code application development with Oracle APEX |
Pricing for compute and storage depends on the workload type selected. A database can be cloned to a different workload type when requirements change. For example, an Autonomous AI JSON Database is limited to 20 GB of data other than JSON documents, so an application that grows into relational tables can move to Transaction Processing.
Deployment Options
| Option | Infrastructure | Who controls maintenance timing | Typical use |
|---|---|---|---|
| Serverless | Shared Exadata infrastructure managed by Oracle | Oracle, within published maintenance windows (you can choose an Early or Regular patch level) | Most applications; fast provisioning; pay per use |
| Dedicated Exadata Infrastructure | Exadata infrastructure reserved for you in OCI | You set maintenance schedules for the container databases | Isolation requirements, many databases, custom maintenance windows |
| Exadata Cloud@Customer | Dedicated Exadata in your data center | You | Data residency in your own facility |
Autonomous AI Database on Dedicated Exadata Infrastructure has a layered structure:
- Exadata infrastructure: the dedicated hardware.
- Autonomous Exadata VM Cluster (AVMC): a VM cluster carved from the infrastructure.
- Autonomous Container Database (ACD): holds maintenance settings, the database software version, and Autonomous Data Guard configuration for the databases inside it.
- Autonomous AI Databases: the individual databases created by application teams.
Globally Distributed Autonomous AI Database (Chapter 14) also runs on dedicated Exadata infrastructure.
The ECPU Compute Model
ECPUs are the billing metric for all new and existing Autonomous AI Database deployments; OCPU is a retired legacy metric. You specify an ECPU count and storage when provisioning, and both can be changed later. Compute auto scaling, covered in the next section, lets the database use up to three times its ECPU count during peaks.
Provisioning Choices
When you create a database you choose:
- Workload type and database version.
- ECPU count and storage, and whether compute auto scaling (enabled by default) and storage auto scaling (disabled by default) are on.
- Administrator password.
- Network access: public endpoint, public endpoint with access control rules, or private endpoint.
- License type: license included or bring your own license (BYOL); with BYOL Standard Edition, the ECPU count is limited to 32.
- Patch level: Regular (default) or Early.
Predefined Database Services
Connections choose one of five predefined database services, available for every workload type. Each service has different priority, parallelism, and concurrency characteristics:
| Service | Priority | Parallelism | Best for |
|---|---|---|---|
| tpurgent | Highest | Supports manual parallelism | Time-critical transactions |
| tp | High (below tpurgent) | No parallelism | Typical transaction processing |
| high | High priority for reporting and batch | All operations run in parallel and are subject to queuing | Low-concurrency analytics with few users |
| medium | Medium | Parallel; concurrency limit can be changed | Moderate reporting and batch |
| low | Lowest | No parallelism | Low-priority reporting, batch, and background work |
Separating workloads by service protects interactive users. For example, route checkout transactions through tp or tpurgent and nightly reports through low or medium, so heavy queries queue instead of starving transactions. Enabling compute auto scaling changes the concurrency and parallelism settings of the predefined services. Within one session, the CS_SESSION package can switch to a different service.
Network Access
| Option | How it works | When to use |
|---|---|---|
| Public endpoint, open | Reachable from any IP with valid credentials | Rarely appropriate for production |
| Public endpoint with access control list (ACL) | Allows only listed IP addresses, CIDR blocks, or VCNs (traffic from a VCN through a service gateway) | Controlled access without a private IP |
| Private endpoint | The database gets a private IP in your subnet, with NSGs controlling access, and no public access | Production systems, on-premises access over FastConnect or VPN |
With a private endpoint, Oracle recommends a regional subnet for the best availability, and the same private endpoint applies to an Autonomous Data Guard standby after a failover or switchover.
Tools Included With the Database
Database Actions provides browser-based tools for SQL development, data loading, data modeling, and monitoring, and the database includes Oracle APEX and Oracle REST Data Services for building low-code applications and REST APIs.
A bank requires that its Autonomous AI Databases run on Exadata hardware reserved for the bank, with maintenance windows the bank controls for groups of databases. Which deployment meets this requirement?
Dedicated Exadata Infrastructure, with maintenance set on Autonomous Container Databases
Autonomous AI Database Serverless on the Early patch level for every database
Autonomous AI Database Serverless with private endpoints in a subnet reserved for the bank
Base Database Service single-node VM DB systems in a compartment reserved for the bank
An online store uses one Autonomous AI Transaction Processing database for checkout and for analytics reports. During sales, reports slow down checkout. Without adding ECPUs, how should the architect separate the workloads?
Connect both checkout and reports through the high service so both get parallel execution
Connect reports through tpurgent because it has the highest priority
Disable compute auto scaling so reports cannot use extra CPU
Connect checkout through tp or tpurgent and run reports through the low or medium service
A team wants an Autonomous AI Database that has no public access at all, can be reached from on-premises over FastConnect, and only accepts connections from the application tier's NSG. Which network option should be chosen?
A public endpoint whose access control list allows the on-premises CIDR and the application VCN
A public endpoint with no network restrictions, protected by strong passwords
A private endpoint in a private subnet with an NSG limited to the app tier and on-premises
A public endpoint reached through an internet gateway attached to the VCN
Sections you finish are checked off in the contents.