Domain 2: Autonomous Database Shared (20%)

Domain 2 of the 1Z0-931-25 Oracle AI Autonomous Database 2025 Professional exam covers provisioning, scaling, consolidation, user management, cloning, monitoring, backup, and disaster recovery for Autonomous Database on Shared (Serverless) infrastructure. At 20% of the exam, this is one of the three heaviest domains, representing approximately 10 questions. Every topic here is hands-on operational knowledge; expect scenario-based questions that test whether you know the specific limits, defaults, and procedures.

The exam syllabus defines eight objectives for this domain:

1. Create Autonomous Database Shared instances (provisioning, scaling OCPU/ECPU and storage, start and stop)
2. Database Consolidation with Elastic Resource Pools
3. Manage users
4. Cloning
5. Move Autonomous Database
6. Monitor Autonomous Database instances (events and alarms)
7. Manage Autonomous Database backups and restores
8. Describe Data Guard

1. Provisioning ADB Shared Instances

Compute Model: ECPUs

ECPU (Elastic CPU) is the only billing metric for all new and existing Autonomous Database Serverless deployments. The legacy OCPU model is retired and cannot be selected for new instances. (ADB Provisioning)

Workload Types

Four workload types are available at provisioning time:

Database Version

Two database versions are available:

• Oracle AI Database 26ai (preferred) -- available in all commercial public cloud regions for Paid tier
• Oracle Database 19c -- available as fallback where 26ai is not yet available

Instance Tiers

Database Naming Rules

• Display name: User-friendly; does not need to be unique. Default is a 16-character generated string.
• Database name: Letters and numbers only, maximum 30 characters, must be unique per tenancy per region. Default matches the display name.

Administrator Credentials

The ADMIN user is created during provisioning. The username is fixed and read-only. The password must meet Oracle Cloud strong password requirements. This is a database user, not an OCI IAM user.

Network Access Options

Three options are available at provisioning time and can be changed after provisioning:

Source: ADB Provisioning

Exam trap: Always Free instances cannot use private endpoints. If a question asks about deploying Always Free with a private endpoint, the answer is that it is not supported.

Encryption Options

Lifecycle Operations: Start, Stop, Restart, Terminate

• Stop: Compute billing stops; storage billing continues. Connections are severed. Automatic backups continue.
• Start: Resumes compute billing and connections. Always Free instances take ~5 minutes before APEX/ORDS endpoints are available after starting.
• Restart: Online restart with brief interruption.
• Terminate: Permanently deletes the instance. Local standby (Data Guard) is terminated with the primary. Cross-region standby must be terminated first.
• Scheduled start/stop: Daily start and stop times can be configured.
• Undelete: Terminated instances can be recovered within a limited window.

2. Scaling: Manual and Auto-Scaling

Compute Scaling

• Manual scaling: Increase or decrease ECPUs at any time; takes effect immediately with no downtime (online scaling). Minimum 2 ECPUs.
• Compute auto-scaling: Enabled by default. The database can automatically use up to 3x the base ECPU count to handle workload spikes. Billing is based on actual usage.

Storage Scaling

• Manual scaling: Increase or decrease storage (subject to minimum of actual data used).
• Storage auto-scaling: Disabled by default. When enabled, storage can expand up to 3x the base provisioned storage.
• Flash cache: Exadata Smart Flash Cache provides a guaranteed minimum of 10% of provisioned storage (or 10% of base/allocated storage, whichever is higher, when auto-scaling is enabled).
• IO capacity: Scales with ECPU count. Provisioning 384 TB of storage provides full Exadata IO capacity regardless of ECPU count.

Source: ADB Provisioning

Exam trap: Compute auto-scaling is ON by default; storage auto-scaling is OFF by default. Both scale up to 3x. The exam loves testing which default applies to which. Also note: auto-scaling must be disabled before joining or creating an Elastic Resource Pool.

3. Database Consolidation with Elastic Resource Pools

Elastic Resource Pools are a key 2025 feature that enables database consolidation by grouping multiple ADB instances to share compute resources, providing up to 87% cost savings through over-provisioning. (Elastic Pools)

Pool Architecture

Valid Pool Sizes

Example: A 256 ECPU pool has 1,024 ECPUs of total capacity. If 8 member databases each have 80 ECPUs allocated (640 total), 384 ECPUs remain available. This is over-provisioning: the sum of member allocations (640) exceeds the pool base size (256) but stays within total capacity (1,024).

Prerequisites

• Instance must use the ECPU compute model (not legacy OCPU)
• Compute auto-scaling must be disabled
• Storage auto-scaling must be disabled for dedicated pools
• Instance cannot already be a member of another pool

Regular vs. Dedicated Elastic Pools

Multi-Tenancy

Elastic pools support cross-tenancy membership. Child tenancy instances join a parent tenancy pool leader by entering the pool leader's OCID. Specific IAM policies are required.

Terminating a Pool

The pool must have zero members before the pool leader can terminate the pool.

Exam trap: The capacity math is testable. Pool size x 4 = total capacity. The exam will give you a pool size and member allocations and ask whether a new member can join or whether the pool can be downsized. Remember: you cannot decrease pool size if the resulting capacity would be less than total current member allocations.

4. User Management

ADMIN User

The ADMIN user is the primary administrative account created during provisioning. It has full database privileges and is used for:

• Creating additional database users and schemas
• Granting roles and privileges
• Managing Oracle Machine Learning (OML) user accounts

Authentication Methods

Source: User Management

User and Schema Management

Users can be created through Oracle Database Actions (GUI), SQL client tools, or command-line tools. Key operations:

• CREATE USER ... PROFILE <profile_name> to create users with specific profiles
• ALTER USER to modify user properties
• Profiles can be imported via Oracle Data Pump Import
• OML users can be added from existing database accounts

Exam trap: OCI IAM controls who can manage the ADB instance (start, stop, scale, terminate). The ADMIN database user controls who can access data inside the database. These are separate identity layers. A question may try to conflate them.

5. Cloning

ADB supports three clone types, all of which can be performed from a running instance or from a backup. (ADB Cloning)

Clone Types

Clone Sources

• Clone from database instance: Clones the running (live) database
• Clone from backup: Clone from a selected backup, a point-in-time timestamp, or the latest available backup data

Full Clone Storage Requirements

Refreshable Clones: Deep Dive

Refreshable clones are a frequently tested topic. Key facts from Refreshable Clone Documentation:

Changes to the source database's storage and ADMIN password propagate to all attached refreshable clones. You must disconnect or terminate all refreshable clones before terminating the source database.

Cross-Region Cloning

• Clone to a different subscribed region
• For CLI/Terraform: the CREATE API must be called from the target region with the source database OCID
• Only subscribed regions appear in the region list

Cross-Workload Cloning

The clone defaults to the same workload type as the source, but cross-workload cloning is supported (e.g., clone a Lakehouse instance as Transaction Processing).

Database Version Constraints for Cloning

Clone Naming

Default display name: Clone-of-<DBname>. Database name must still be unique per tenancy per region.

Exam trap: A refreshable clone that is not refreshed within 7 days will auto-disconnect. After disconnect, you have exactly 24 hours to reconnect. After that window expires, it becomes a permanent standalone database. The exam may present a scenario with specific timelines and ask whether reconnection is still possible.

6. Moving Autonomous Database

Moving Between Compartments

Moving an ADB instance to a different compartment is a single-step operation via More actions > Move resource. Key facts from Move ADB:

• Requires manage autonomous-database permission in both the source and target compartments
• Compartment IAM policies apply immediately after the move -- access to the instance may change based on the new compartment's policies
• The database itself is not physically moved; only the compartment assignment changes

Moving Between Regions

Cross-region movement is not a direct "move" operation. To migrate an ADB to a different region, use one of:

• Cross-region cloning (full or metadata clone to the target region)
• Cross-region Autonomous Data Guard (switchover to promote the standby in the target region to primary)
• Data Pump export/import via Object Storage

Exam trap: Moving between compartments is a metadata operation that takes effect immediately. Moving between regions requires cloning or Data Guard switchover -- there is no single "move to region" button.

7. Monitoring ADB Instances

OCI Metrics

ADB emits metrics to the OCI Monitoring service under the oci_autonomous_database namespace. Key metrics include:

• CPU utilization (percentage of allocated ECPUs in use)
• Storage utilization (bytes/TB used vs. provisioned)
• Number of active sessions
• Peer Lag (seconds standby lags behind primary, for Data Guard)

OCI Events

ADB generates events that can trigger OCI Notifications, Functions, or Streaming. Events are emitted for:

• Data Guard operations (enable, disable, failover begin/end, switchover begin/end, automatic failover begin/end)
• Lifecycle changes (start, stop, terminate, scale)
• Backup and restore operations
• Maintenance and patching

Alarms and Notifications

• Create OCI Alarms based on ADB metrics (e.g., CPU utilization > 80% for 5 minutes)
• OCI Notifications deliver alerts via email, PagerDuty, Slack, HTTPS, or OCI Functions
• Customer contacts (up to 10 email addresses per database) receive operational notifications and announcements

Performance Hub

Performance Hub is the built-in performance monitoring tool in the OCI Console. It provides:

• Active Session History (ASH) analytics
• SQL monitoring for active and recent SQL statements
• Real-time and historical performance data
• No additional configuration or licensing required

8. Backup Management

Automatic Backups

Source: Backup and Restore

Long-Term Backups

• Retention: 3 months to 10 years
• Manually created
• Stored in OCI Object Storage
• Used for compliance and archival requirements

Backup-Based Disaster Recovery

A lower-cost alternative to Autonomous Data Guard:

• Local: No additional cost. Higher RTO than Data Guard.
• Cross-region: Incurs additional cost for backup storage in the remote region.
• Instantiates the peer database from backups only at switchover/failover time (not a continuously running standby).

Always Free Backup Restrictions

Always Free instances do not support:

• Long-term backups
• Manual backups to Object Storage
• Restore functionality
• Any backup configuration changes

Exam trap: Immutable backup retention is a one-way door. Once enabled, it cannot be turned off or shortened. An Oracle Support Service Request is required to change it. The exam may present a scenario where an administrator wants to shorten the retention period after enabling immutability.

9. Autonomous Data Guard

Autonomous Data Guard provides continuous replication to a standby database for high availability and disaster recovery. (Data Guard)

Standby Types

Local Standby Key Facts

• Default disaster recovery is Backup-Based DR, not Data Guard. Data Guard must be explicitly enabled.
• In multi-AD regions, the standby is placed in a different Availability Domain.
• In single-AD regions, the standby is placed in a different Fault Domain (different physical machine).
• No direct user access to the local standby. All operations happen on the primary.
• Automatic failover uses a configurable data loss limit (0 to 3600 seconds, default 0). If potential data loss exceeds the limit, automatic failover does NOT occur and manual failover is required.

Cross-Region Standby Key Facts

• Automatic failover is not supported for cross-region standby.
• The standby can be converted to a snapshot standby for up to 48 hours, allowing read-write access temporarily. Data refresh from the primary pauses during this time.
• If both local and cross-region standbys exist and the local standby is available, failover must go to the local standby first. You cannot skip the local standby to fail over to the remote standby.

Switchover vs. Failover

Billing

What Survives Failover/Switchover

All of the following are preserved: ECPU count, storage, display name, database name, auto-scaling settings, tags, BYOL licensing, OML notebooks and users, APEX data and metadata, ACLs, private endpoints, client connection strings, and existing wallet-based connections.

Data Guard Events (Monitoring Integration)

Data Guard emits OCI Events for: begin/end automatic failover, begin/end manual failover (with success/failure result), begin/end switchover (with success/failure result), begin/end enable/disable Data Guard.

Disconnect Operation

• Disconnecting a standby converts it to a standalone database. The disassociation is permanent and cannot be reversed.

Exam trap: Automatic failover is local standby only. Cross-region standby requires manual failover. The default data loss limit for automatic failover is 0 seconds, meaning automatic failover only fires when zero data loss is guaranteed. If the standby has any lag, automatic failover will NOT trigger -- manual intervention is required.

Exam trap: You must terminate the cross-region standby before terminating the primary database. Terminating the primary automatically terminates the local standby, but cross-region standby must be handled separately.

10. Always Free Tier Limitations

Always Free ADB instances are a frequent exam topic because the restrictions are numerous and specific. (Always Free)

Upgrading to Paid Tier

You cannot upgrade from Always Free 19c to Always Free 26ai directly. To get 26ai, you must upgrade to a paid tier or clone to a Developer instance.

Exam trap: 7 days idle = auto-stopped. 90 cumulative days stopped = permanently deleted. Making a SQL*Net or HTTPS connection and running a SQL command resets the inactivity counter. Starting the database is not enough -- you must actually run a query.

11. Network Access: Public, Private, and ACLs

Network access is configured at provisioning time but can be changed afterward.

Access Control Lists (ACLs)

• Applied to public endpoints to restrict access by IP address, CIDR block, or VCN OCID
• Multiple rules per instance supported
• Can be configured during provisioning, cloning, or post-deployment

Private Endpoints

• Private IP and hostname within a VCN subnet
• No public IP assigned; all public access blocked
• Traffic controlled by Network Security Groups (NSGs)
• Supports Zero Trust Packet Routing (ZPR) with security attributes (namespace, key, value)
• Regional subnet recommended for optimal availability and latency
• Not available for Always Free instances

Changing Network Access Post-Deployment

Network access type (public, ACL-restricted, private endpoint) can be changed after deployment. This means you can start with public access and later switch to private endpoint without reprovisioning.

Key Exam Traps Summary

1. ECPU is the only compute metric. OCPU is deprecated and retired on Serverless.
2. Compute auto-scaling ON by default; storage auto-scaling OFF by default. Both scale to 3x.
3. Elastic Pool capacity = pool size x 4. Valid sizes: 128, 256, 512, 1024, 2048, 4096 ECPUs. Auto-scaling must be disabled to join a pool.
4. Dedicated Elastic Pools require minimum 256 ECPUs AND 256 TB storage. Maintenance window is set once and cannot be changed.
5. Refreshable clone max age is 7 days before auto-disconnect. After disconnect, 24 hours to reconnect. After that, it becomes a standalone database permanently.
6. Always Free: 2 instances max, ~20 GB, 30 sessions, no scaling, no Data Guard, no backups, no private endpoints, no GoldenGate. Idle 7 days = stopped. Stopped 90 days = deleted.
7. Automatic failover is local standby only with a default data loss limit of 0 seconds. Cross-region standby requires manual failover.
8. Cross-region standby must be terminated before the primary. Local standby is terminated automatically with the primary.
9. Immutable backup retention cannot be reversed without a Service Request. It is a one-way operation.
10. Moving between compartments is a metadata-only operation that applies new IAM policies immediately. Moving between regions requires cloning or Data Guard switchover.
11. Clone from 19c source can target 19c or 26ai. Clone from 26ai source can only target 26ai.
12. Pool leader is the only role that can modify pool shape, remove members, or terminate the pool. Members can only remove themselves.

References

• ADB Serverless: Provisioning
• ADB Serverless: Cloning
• ADB Serverless: Refreshable Clones
• ADB Serverless: Autonomous Data Guard
• ADB Serverless: Elastic Resource Pools
• ADB Serverless: Always Free
• ADB Serverless: Backup and Restore
• ADB Serverless: Move to Different Compartment
• ADB Serverless: User Management
• 1Z0-931-25 Exam Syllabus
• Oracle Education: 1Z0-931-25