13.3 Operating Autonomous AI Database: Scaling, Cloning, Backups, Patching & Self-Tuning

Scaling

Compute Auto Scaling

When compute auto scaling is enabled, which is the default for new databases, the database can use up to three times more CPU and I/O resources than its ECPU count. For example, a database with 512 ECPUs can use up to 1,536 ECPUs. You are billed for the additional CPU the workload actually consumes. The number of ECPUs allocated can be checked on the Database Dashboard in Database Actions. Enabling auto scaling also changes the concurrency and parallelism settings of the predefined services.

Storage Auto Scaling

Storage auto scaling is disabled by default. When you enable it, the database can expand to use up to three times the reserved base storage. You can also change the base storage manually at any time through Manage resource allocation.

Manual Scaling

You can change the ECPU count and storage online, without downtime. A common pattern is a modest base ECPU count with auto scaling for peaks, plus scheduled manual scaling for known month-end loads.

Cloning

Clones create new databases from an existing one, for testing, development, analytics, or recovery.

For full and metadata clones you also choose the source:

• Clone from a database instance: a copy of the running database.
• Clone from a backup: a copy at a selected backup or point in time.
• Clone from the latest backup: a copy using the most recent backup data.

Additional options include cross-region cloning, cross-tenancy cloning, cloning to change the workload type, cloning when the source is unavailable (to replace a failed database from its backup), and cloning to a preview of an upcoming release when one is available. Refreshable clones are a popular way to give reporting teams a read-only, periodically refreshed copy without affecting production.

Backups and Recovery

Autonomous AI Database backs itself up automatically:

• Automatic backups: retained for 60 days by default; you can set the retention from 1 to 60 days. You can restore or clone to any point in time within the retention period.
• Long-term backups: created once or on a weekly, monthly, or yearly schedule, with retention from 3 months to 10 years, for compliance and archival needs.

Restore operations replace the database contents with an earlier point in time, while cloning from a backup creates a separate database and leaves the original untouched, which is usually safer when investigating a data error.

Patching and Maintenance

Oracle applies patches automatically during maintenance windows shown in the Console:

• Patch level: Regular (default when provisioning) or Early. Early-level databases receive maintenance one week before Regular ones, so you can test patches in non-production databases before they reach production. A clone inherits the source's patch level by default.
• Patches are applied in a rolling fashion within the scheduled maintenance window to minimize disruption, and the Console shows the next scheduled maintenance.
• On dedicated Exadata infrastructure, you set maintenance preferences at the Autonomous Container Database level, so groups of databases share schedules you control.

Self-Tuning: Auto Configuration and Optimizer Statistics

Autonomous AI Database configures memory, parallelism, and many database settings automatically based on the workload type and size. It also maintains optimizer statistics for you:

• High-frequency automatic optimizer statistics collection is enabled by default and runs every 15 minutes, so statistics are less likely to be stale.
• Real-time statistics are gathered during conventional DML, helping the optimizer between collection jobs.
• Automatic indexing, once you enable it with the DBMS_AUTO_INDEX package (it is disabled by default), creates and validates indexes based on the workload.
• SQL quarantine can stop repeatedly runaway statements (automatic quarantine based on Resource Manager limits is disabled by default, but manually quarantined statements are honored).

Settings such as OPTIMIZER_IGNORE_HINTS and OPTIMIZER_IGNORE_PARALLEL_HINTS control whether the optimizer follows hints in application SQL, which matters when migrating applications that contain old hints.

Initialization Parameters

Unlike Base Database Service, you cannot change most initialization parameters. Oracle publishes a list of parameters that you can modify, such as NLS formatting parameters, OPTIMIZER_IGNORE_HINTS, OPTIMIZER_IGNORE_PARALLEL_HINTS, OPTIMIZER_MODE, OPTIMIZER_REAL_TIME_STATISTICS, and RESULT_CACHE_INTEGRITY, using ALTER SESSION or ALTER SYSTEM as documented for each parameter. If an application depends on parameters outside that list, Base Database Service may be a better fit.

Stopping and Starting

You can stop an Autonomous AI Database when it is not needed, such as a development database at night. Compute billing stops while it is stopped, but storage is still billed. Combine start and stop actions with the Resource Scheduler or a scheduled function to automate this.