Autonomous Database (ADB) is marketed with phrases like “self-driving,” “self-securing,” and “self-repairing.” These are not meaningless marketing terms, but they’re also not magic. Understanding what ADB actually does automatically — and how — makes you a better operator of the service and helps you set realistic expectations with your business stakeholders.

Auto-Tuning: What It Does and What It Doesn’t

ADB continuously analyzes workload patterns and applies optimizations. The most visible automations:

Automatic Indexing — ADB’s machine learning component monitors SQL execution statistics, identifies columns that would benefit from indexing based on access patterns, creates candidate indexes invisibly, tests them against real workload, and promotes them to visible indexes only if they demonstrably improve performance. Indexes that stop being beneficial are dropped automatically.

sql

-- Monitor automatic indexing activity
SELECT index_name, table_name, column_name, index_type,
       creation_date, last_operation
FROM dba_auto_index_ind_col_usage
ORDER BY creation_date DESC;
-- Check automatic indexing configuration
SELECT parameter_name, parameter_value
FROM dba_auto_index_config;

You can influence this:

sql

-- Allow automatic indexing but don't auto-promote (manual approval required)
EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE', 'IMPLEMENT');
-- Options: OFF, REPORT ONLY, IMPLEMENT

Automatic Statistics Collection — ADB collects optimizer statistics more aggressively than the default Oracle scheduler. Fresh statistics mean the optimizer makes better cardinality estimates. This is a significant part of why ADB query performance often surprises people who migrate from poorly-maintained on-prem databases where statistics haven’t been refreshed in months.

Automatic Memory Management — ADB manages SGA and PGA sizing based on actual workload. There are no user-configurable memory parameters — you specify OCPUs and ADB translates that to memory allocation.

The OCPU Scaling Mechanism

ADB scales compute (OCPUs) in two ways:

Manual scaling: you change the OCPU count through the console or REST API. Takes effect within seconds. No downtime.

Auto-scaling: when enabled, ADB can temporarily scale up to 3x your base OCPU count when workload demands it. It scales back down when demand drops. You pay only for what you use.

The mechanism: ADB monitors CPU utilization. When average utilization exceeds a threshold for a sustained period, it expands. When utilization drops, it contracts.

What to know operationally:

• Auto-scaling adds latency to the scale-up — it doesn’t happen instantaneously when a spike hits
• You pay OCPU-hours for auto-scaled capacity, which can make cost unpredictable
• Set an OCPU maximum if cost predictability matters:

sql

-- Set maximum OCPU for autoscaling (via OCI CLI)
oci db autonomous-database update \
    --autonomous-database-id <ocid> \
    --max-cpu-core-count 8

Patching — Zero Downtime, But Not Zero Impact

ADB patches itself automatically. Quarterly database security patches are applied without downtime using online patching. This is a significant operational advantage over self-managed databases, where patching always involves planning, testing, and downtime windows.

But “zero downtime” doesn’t mean “zero impact.” During patching:

• Individual sessions may experience a brief reconnect (sub-second)
• Applications using connection pools with retry logic handle this transparently
• Applications that don’t handle reconnections may report transient errors

This is why ADB’s documentation strongly recommends connection retry logic in your application. On OCI, the Thin JDBC driver (23c+) handles reconnection automatically for most scenarios. Check your application’s connection pool configuration:

• Validate connection on borrow (detect dead connections before use)
• Connection retry count and interval
• Session state management (ADB uses session state service to preserve state across reconnects)

Security Automation — What ADB Does Without Being Asked

ADB runs Oracle Data Safe continuously in the background. Security configuration is assessed against Oracle’s security benchmarks. Deviations are flagged.

More importantly, ADB enforces security configuration that self-managed databases often drift from:

• Default user accounts are locked and expired
• Minimum password requirements are enforced
• Auditing is enabled by default with a comprehensive policy
• Network access is controlled at the service level (no direct OS access)
• TDE is always on, always using customer-managed keys (with OCI Vault)

One thing to understand: you don’t have SYSDBA access to an ADB instance. You have ADMIN user, which has broad DBA-equivalent privileges, but it’s not SYSDBA. Some administrative operations that require SYSDBA on self-managed databases simply aren’t available on ADB — by design, because Oracle manages those aspects for you.

Data Guard — Automatic, But Configurable

Every Autonomous Database automatically has Oracle Data Guard configured as a local standby. This is transparent to you. The Local Standby provides:

• Automatic failover with RTO under 2 minutes for most configurations
• Zero data loss (synchronous redo transport to local standby)

You can additionally configure a Cross-Region Autonomous Data Guard standby for geographic DR:

sql

-- Via OCI CLI
oci db autonomous-database create-autonomous-database-from-backup-timestamp \
    --source-autonomous-database-id <primary_ocid> \
    --region us-ashburn-1  -- secondary region

The cross-region standby is a separate billable resource. For production databases handling sensitive workloads, cross-region ADB Data Guard is worth the cost — you get geographic DR without managing a single Data Guard parameter.