Domain 3: MySQL HeatWave (20%)

Domain 3 of the 1Z0-1093-25 Oracle AI Cloud Database Services 2025 Professional exam covers MySQL HeatWave on Oracle Cloud Infrastructure. At 20% of the exam weight, this is a substantial domain worth approximately 10 questions on the exam. The exam tests your understanding of MySQL HeatWave architecture, provisioning, query acceleration, Lakehouse, AutoML, GenAI capabilities, operational management, and migration methods.

1. MySQL HeatWave Service Overview

What MySQL HeatWave Is

MySQL HeatWave is a fully managed database service on OCI built on MySQL Enterprise Edition. It is the only cloud MySQL service that combines transactions, real-time analytics, machine learning, and generative AI in a single service without requiring ETL data duplication. (MySQL HeatWave Product Page)

The key differentiator from competing managed MySQL offerings (Amazon RDS/Aurora, Azure Database for MySQL, Google Cloud SQL) is that HeatWave provides an in-memory query accelerator, a machine learning engine, and generative AI capabilities natively within the database -- not as separate services requiring data movement.

Two Core Components

Every MySQL HeatWave deployment consists of two components. (HeatWave Architecture Overview)

Exam trap: A MySQL DB System can run without a HeatWave cluster. It is a standalone managed MySQL database in that case. The HeatWave cluster is an add-on accelerator. The exam may present scenarios where a customer "just needs managed MySQL" -- the answer is a DB System without HeatWave, not the full HeatWave stack.

Multicloud Availability

MySQL HeatWave is available on three clouds: (MySQL HeatWave Product Page)

• Oracle Cloud Infrastructure (OCI) -- primary platform
• Amazon Web Services (AWS) -- MySQL HeatWave on AWS
• Microsoft Azure -- MySQL HeatWave for Azure (via ODSA)

Exam trap: The exam is about OCI-specific deployment. However, understanding that HeatWave is multicloud may appear in comparison questions. The storage layer persists to OCI Object Storage on OCI and AWS S3 on AWS.

2. HeatWave Cluster Architecture

How the Cluster Works

The HeatWave Cluster uses a distributed, scalable, shared-nothing architecture. Five design characteristics drive its performance:

1. In-Memory Hybrid-Columnar Format

Data is stored in main memory using a hybrid columnar format that combines the analytical benefits of columnar storage (compression, vectorized processing) with efficient update handling. This avoids the materialization costs of pure columnar formats and enables fixed-width data processing.

2. Massively Parallel Architecture

Data is partitioned both across nodes (internode) and within nodes (intranode). Each CPU core processes its data partition in parallel. The architecture scales to thousands of cores using high-fanout, workload-aware partitioning.

3. Push-Based Vectorized Query Processing

Queries are processed by pushing vector blocks (columnar data slices) through the execution plan in an operator-to-operator push model. This avoids deep call stacks and is more efficient than traditional tuple-based (row-at-a-time) processing.

4. Scale-Out Data Management with Storage Layer

The MySQL HeatWave Storage Layer automatically persists loaded data to OCI Object Storage. This enables:

• Pause and resume of HeatWave clusters without data loss
• Fast recovery from node or cluster failures
• Automatic data restoration after planned or unplanned restarts

As of MySQL 9.2.0, additional metadata is persisted for even faster recovery. In earlier versions, HeatWave reloads data from the original source (InnoDB or Object Storage for Lakehouse tables).

5. Inbuilt GenAI and Machine Learning

ML and GenAI run inside the database engine, eliminating data movement to separate AI/ML infrastructure.

Data Loading and Change Propagation

When a table is loaded into HeatWave, data is sharded and distributed among the HeatWave nodes. The Auto Parallel Load utility automates this process. After loading:

• DML operations (INSERT, UPDATE, DELETE) on loaded tables are automatically propagated to HeatWave nodes
• No manual synchronization is required
• Query results are always up-to-date with the source data

Query Offloading

Queries are automatically offloaded from the DB System to the HeatWave cluster when a HeatWave cluster is enabled. The flow is:

1. Client sends query to DB System (MySQL endpoint)
2. HeatWave plugin evaluates whether the query can be accelerated
3. Qualifying queries are offloaded to the HeatWave cluster
4. HeatWave processes the query in parallel across nodes
5. Results return to the DB System and then to the client

Traffic between the DB System and the HeatWave cluster is fully encrypted.

Exam trap: Not all queries are offloaded. Queries must meet specific prerequisites (supported SQL operations, data types, functions). If a query cannot be offloaded, it runs on the DB System's InnoDB engine as normal. The system does not fail -- it falls back to standard MySQL execution.

3. Provisioning and Shapes

ECPU Shapes (Current Standard)

ECPU (Elastic Central Processing Unit) shapes are the current recommended shapes. All ECPU shapes support HeatWave clusters. OCPU shapes are deprecated as of September 5, 2024 and unavailable after March 13, 2026. (Supported Shapes)

HeatWave Cluster Node Shapes (ECPU)

Key memorization points:

• Read replicas require 8 or more ECPUs (MySQL.8 and above)
• HA configuration is available on MySQL.2 and above (not MySQL.Free)
• MySQL.Free does not support HA, read replicas, manual backups, or PITR
• MySQL.256 has limited hardware availability (contact Oracle sales)
• HeatWave.512GB is the recommended production node shape with no node limit

Exam trap: The exam may test whether you know that the Always Free tier (MySQL.Free shape) has significant limitations -- no HA, no read replicas, no manual backups, 1-day automatic backup retention only, no point-in-time recovery.

Legacy OCPU Shapes with HeatWave Support

For reference on the exam (as the transition period extends to March 2026):

Exam trap: Under the old OCPU model, only specific HeatWave-dedicated shapes supported HeatWave clusters. Under the new ECPU model, all shapes support HeatWave. This is a significant simplification.

4. Networking and Connectivity

VCN and Subnet Requirements

MySQL HeatWave DB Systems are deployed in a private subnet within a VCN. DB System endpoints are not directly accessible from the internet. You must use an intermediate service to connect.

Connection Methods

Required ports: MySQL classic protocol uses port 3306; MySQL X Protocol uses port 33060. Security lists or Network Security Groups must allow ingress on these ports from authorized sources.

Exam trap: Unlike Oracle Database services (BaseDB, Exadata) which can optionally have public endpoints, MySQL HeatWave DB Systems are always in private subnets. There is no "public IP" option for the DB System itself. The Network Load Balancer method exists but Oracle explicitly warns against it.

5. High Availability

Architecture

MySQL HeatWave HA uses MySQL Group Replication with 3 MySQL instances: 1 primary (read/write) + 2 secondary (read-only). All three instances have identical CPU, RAM, and storage resources.

Placement Models

• Multi-AD regions with regional subnet: Each instance in a different Availability Domain
• Multi-AD regions with AD-specific subnet: Each instance in a different Fault Domain within the same AD
• Single-AD regions: Each instance in a different Fault Domain within the same AD

Failover and Switchover

Automatic failover triggers when the primary fails. One secondary is promoted automatically. The read/write endpoint IP does not change. After failover:

• Scheduled events inherit REPLICA_SIDE_DISABLED status and must be manually re-enabled
• HeatWave queries experience a temporary delay while the cluster reattaches

Manual switchover allows planned primary relocation. Same behavior as failover regarding binary log positions.

HeatWave Cluster Behavior During Failover

Exam trap: HA consumes 3x the compute and storage resources of a standalone system. The exam may ask about cost or resource implications. Also, binary log file names and positions differ between the old and new primary after failover -- this matters for any external replication channels.

Exam trap: Unlike Oracle RAC (active-active for Oracle Database), MySQL HeatWave HA is active-passive for writes. Only the primary accepts writes. Secondaries handle reads only. Do not confuse the two models.

6. Backups and Recovery

Backup Types

MySQL HeatWave supports four backup creation types. (Backups Overview)

Incremental Backups

Incremental backups capture only changes since the last full or incremental backup. They are functionally equivalent to full backups for recovery -- you do not need to maintain a chain. Any single backup (full or incremental) can restore the DB system to the point in time when that backup was taken.

Point-in-Time Recovery (PITR)

PITR restores a DB system to a specific point in time or to the latest available point. It creates a new DB system (does not restore in-place). Not available on Always Free DB systems.

Cross-Region Backup Copy

Automatic backups can be scheduled for cross-region copy. Requires MYSQL_BACKUP_COPY permission (not included in the mysql-family aggregate resource type).

Soft Delete

When enabled, backups scheduled for deletion are retained for an additional 7 days in DELETE_SCHEDULED state before permanent deletion. Not available on Always Free DB systems.

Exam trap: When you delete a non-latest backup, it is merged into the following incremental backup to maintain the chain. Deleting the latest backup does not trigger a merge. This is a subtle but testable detail.

7. HeatWave Lakehouse

What Lakehouse Does

HeatWave Lakehouse enables querying data stored in OCI Object Storage without loading it into InnoDB tables on the DB System. Data is read from Object Storage, transformed to HeatWave's memory-optimized format, persisted in the HeatWave Storage Layer, and loaded into HeatWave cluster memory for in-memory query processing.

Supported File Formats

HeatWave Lakehouse supports CSV, Parquet, Avro, JSON, and Aurora/Redshift export files stored in Object Storage.

External Tables

Lakehouse uses external tables that reference data in Object Storage rather than storing data locally.

MySQL 9.4.0+:

CREATE EXTERNAL TABLE sales_data (id INT, amount DECIMAL(10,2))

Earlier versions:

CREATE TABLE sales_data (id INT, amount DECIMAL(10,2))
ENGINE=LAKEHOUSE
SECONDARY_ENGINE=RAPID;

External tables store the location of the data, not the data itself. Data in external tables is deleted when:

• The external table is dropped
• The external table is unloaded
• The HeatWave cluster is deleted

Data Access Methods

Three authentication methods for accessing Object Storage:

Data Refresh Options

• Event-Based Incremental Load: Triggered by data changes
• Incremental Load: Periodic refresh of changed data
• Selective Load: Add or remove specific files from the external table

Exam trap: Lakehouse queries run on the HeatWave cluster, not on the DB System. You must have a HeatWave cluster enabled to use Lakehouse. A standalone DB System without HeatWave cannot query Object Storage data.

Exam trap: You can join InnoDB tables (on the DB System) with Lakehouse external tables (from Object Storage) in the same SQL query. This is a key differentiator -- no ETL pipeline needed to combine operational and analytical data.

8. HeatWave AutoML

Supported ML Tasks

HeatWave AutoML supports the following machine learning tasks directly within the database:

Core ML Routines

Key AutoML Features

• Automatic algorithm selection: AutoML evaluates multiple algorithms and selects the best performer -- no manual algorithm selection needed
• Model catalog: Central repository for managing trained models with metadata
• External ONNX model support: Import pre-trained models in ONNX format
• Data drift detection: Monitor model performance degradation over time
• Lakehouse integration: Train models on data in Object Storage (not just InnoDB tables)

Exam trap: AutoML runs entirely inside HeatWave -- no external ML service, no data export, no separate infrastructure. This is architecturally different from Oracle Database's approach (which uses OCI Data Science or Oracle Machine Learning as separate services). The exam tests whether you understand this distinction.

9. HeatWave GenAI

Capabilities

HeatWave GenAI integrates generative AI capabilities directly into the MySQL database engine. This is a new-for-2025 feature likely to appear on the exam.

How GenAI Works

1. Vector Store: Documents are ingested into a vector store. HeatWave automatically generates embeddings (vector representations of the text) using the OCI Generative AI Service
2. Automatic Vector Indexing: HeatWave creates and maintains vector indexes for efficient similarity search
3. RAG Pipeline: When a user asks a question, HeatWave performs vector search to find relevant documents, then sends the context plus the question to an LLM for answer generation
4. Custom Embeddings: "Bring Your Own Embeddings" support allows using custom embedding tables

Integration Points

• Integrates with OCI Generative AI Service for embedding models and LLMs
• Vector store tables persist in block storage (not in HeatWave cluster memory like analytical data)
• Role-based access control for GenAI operations via dedicated privileges

Exam trap: HeatWave GenAI eliminates the need for a separate vector database (like Pinecone, Weaviate, or Oracle 23ai's vector features in Oracle Database). Vectors, operational data, and analytical data coexist in the same MySQL database. If the exam asks about the simplest architecture for RAG with MySQL data, HeatWave GenAI is the answer.

10. HeatWave Auto Pilot

Automated Performance Optimization

HeatWave Auto Pilot uses machine learning techniques to automate performance optimization across four categories:

Auto Pilot continuously learns from:

• Data sampling and statistics collection
• Memory usage modeling
• Network load modeling
• Execution time modeling
• Patterns in executed queries

Exam trap: Auto Pilot is not a separate product or add-on. It is built into every HeatWave cluster. You do not enable or purchase it separately. The exam may frame questions around "how to optimize HeatWave performance" -- the answer often involves Auto Pilot features that are already active.

11. Replication and Migration

Inbound Replication (Channel-Based)

Inbound replication uses replication channels to replicate data asynchronously from an external MySQL source to a MySQL HeatWave DB System.

Key requirements:

• Source must be MySQL 5.7.9 or later
• Target DB System must be the same version or higher than the source
• A consistent snapshot must be loaded into the target before enabling replication (unless the source is empty)
• Two user accounts required: Replication User (on source) and Applier User (on target with REPLICATION_APPLIER privilege)

Migration workflow:

1. Configure source server and network connectivity
2. Create replication user on source with appropriate privileges
3. Load initial data snapshot to target DB System (using MySQL Shell dump/load, mysqldump, or similar)
4. Create applier user on target DB System
5. Create and start the replication channel
6. Monitor channel state and metrics

Read Replicas

Read replicas are read-only copies of the primary MySQL instance within the same region. (Read Replicas)

• Asynchronous replication from source to replicas
• Scale out read-heavy workloads
• Require shapes with 8+ ECPUs (or 4+ OCPUs)
• Same region only (no cross-region read replicas)

Outbound Replication

Outbound replication streams data from a HeatWave DB System to external MySQL instances for hybrid deployment scenarios.

Exam trap: Inbound replication is the primary migration path from on-premises MySQL to MySQL HeatWave on OCI. The exam may present a scenario where a customer needs to migrate with minimal downtime -- the answer is: load a snapshot, set up inbound replication channel, let replication catch up, then cut over.

12. OLTP + OLAP on a Single Service

Hybrid Workload Architecture

MySQL HeatWave is specifically designed to handle both OLTP and OLAP workloads on a single system. (HeatWave Architecture)

Changes made via OLTP workloads on InnoDB are automatically propagated to the HeatWave cluster so analytical queries always see current data. No ETL pipeline or data warehouse is needed.

Exam trap: This is the fundamental architectural differentiator. Competing services require separate analytics databases (Redshift, BigQuery, Snowflake) with ETL pipelines. HeatWave eliminates that layer. If the exam asks "how to eliminate ETL between transactional and analytical systems for MySQL," the answer is HeatWave.

13. Comparison with Oracle Database Services

For exam context, understand the key differences between MySQL HeatWave and Oracle Database services on OCI:

14. Key Exam Traps and Gotchas

1. DB System vs. HeatWave Cluster: A DB System without a HeatWave cluster is just managed MySQL. HeatWave acceleration, Lakehouse, AutoML, and GenAI all require the HeatWave cluster to be enabled.

2. ECPU vs. OCPU deprecation: OCPU shapes are deprecated and will be unavailable after March 2026. ECPU is the current standard. All ECPU shapes support HeatWave; only specific OCPU shapes did.

3. Always Free limitations: No HA, no read replicas, no manual backups, 1-day auto backup retention, no PITR, no soft delete.

4. Private subnet only: MySQL HeatWave DB Systems cannot be given a public IP. Access requires a compute instance, VPN, or bastion in the same VCN.

5. HA is active-passive: Only the primary accepts writes. Do not confuse with Oracle RAC's active-active model.

6. Lakehouse requires HeatWave: You cannot query Object Storage data without an enabled HeatWave cluster.

7. Auto Pilot is built-in: No separate enablement or purchase. It is always active on every HeatWave cluster.

8. Inbound replication minimum version: Source must be MySQL 5.7.9 or later.

9. Read replicas are same-region only: No cross-region read replica support.

10. GenAI uses OCI Generative AI Service: HeatWave GenAI integrates with OCI's external GenAI service for embeddings and LLMs. It is not a fully self-contained LLM -- it orchestrates external models.

11. Backup merging: Deleting a non-latest backup merges it into the next incremental. This is unique to MySQL HeatWave's backup management.

12. Cross-region backup copy permission: Requires MYSQL_BACKUP_COPY -- not included in mysql-family aggregate resource type. Must be granted explicitly.

References

• MySQL HeatWave on OCI Documentation
• HeatWave Cluster Documentation
• HeatWave User Guide
• HeatWave Architecture Overview
• HeatWave Lakehouse Overview
• HeatWave GenAI
• HeatWave AutoML
• Supported Shapes
• High Availability Overview
• Backups Overview
• Inbound Replication
• Read Replicas
• Connecting to DB System
• MySQL HeatWave Product Page
• 1Z0-1093-25 Exam Page