Learn about Google Cloud NetApp Volumes architecture for high availability Oracle Database 26ai
Suggest changes
PDFs
Google Cloud NetApp Volumes provides high-performance iSCSI block storage for Oracle Database 26ai high availability architectures, with storage-layer replication that significantly accelerates standby database initialization compared to traditional Oracle RMAN methods. Explore GCNV's integration with Oracle Data Guard, including reference data paths, storage topology, and the division of responsibilities between GCNV's block storage and Data Guard's continuous synchronization.
Architecture overview
This architecture uses Google Cloud NetApp Volumes (GCNV) iSCSI block storage to provide high availability for Oracle Database 26ai on Google Cloud with Oracle Data Guard.
GCNV provides high-performance block storage and accelerates standby database initialization using storage-layer replication, snapshots, and clones.
Data Guard provides continuous redo transport, role management, and failover orchestration (Broker, Fast-Start Failover, Observer).
| Layer | Role |
|---|---|
GCNV |
Block storage, standby initialization, storage replication |
Data Guard |
Continuous synchronization, redo apply, switchover, FSFO |
GCNV replication significantly reduces standby initialization time compared to RMAN active duplicate by moving data at the storage layer instead of through Oracle database channels.
Use GCNV replicate, snapshot, or clone to initialize the standby database, then activate Data Guard for continuous synchronization and high availability.
| Component | Detail |
|---|---|
DB hosts |
oracdb1 / oracdb2 - different zones, five GCNV iSCSI volumes each |
Storage |
/u01 + ASM +DATA, +RECO, +FRA on GCNV (EXTERNAL) |
Standby init |
GCNV replicate / snapshot / clone → Oracle finalize → Data Guard |
HA |
Restart, physical standby (MOUNTED), Broker, FSFO, Observer (oradg-obs) |
Apps |
Service orclapp (Step 8.2) |
Zoning
Deploy one GCNV Flex Unified pool per database zone and assign dedicated volumes to each host. Use boot disks for the operating system only.
Out of scope: TDE, RAC, NVMe/TCP, OEM, and Active Data Guard (the standby remains MOUNTED).
Architecture reference diagram
The solution architecture provides three independent data paths. Storage replication and Data Guard redo transport are separate paths.
-
Path 1 moves datafiles at the GCNV layer for standby initialization.
-
Path 2 keeps databases synchronized after cutover.
-
Path 3 orchestrates role transitions and automatic failover through Oracle Data Guard Broker and the Observer.
Platform roles
The following table summarizes which platform layer provides storage services and which layer provides database synchronization and failover control.
| Platform | Delivers |
|---|---|
GCNV |
iSCSI volumes, snapshots, volume replication (baseline + incrementals) - standby initialization |
Data Guard |
Redo transport, MRP, Broker, FSFO - continuous synchronization and failover |
GCNV replication runs a baseline copy, then incremental block updates per policy. Data Guard owns redo apply and FSFO after the standby is initialized.
Topology and storage
This topology places primary, standby, and observer roles across separate zones and maps each database host to dedicated GCNV pools and iSCSI volumes.
| Role | VM | Zone | GCNV pool | Volumes (per host) |
|---|---|---|---|---|
Primary |
|
|
|
|
Standby |
|
|
|
Same naming pattern |
Observer |
|
|
- |
Boot disk only |
| Storage | Backing | Use |
|---|---|---|
OS |
GCE boot disk |
OS only |
|
GCNV iSCSI |
Grid/DB homes, staging (XFS) |
|
GCNV iSCSI |
ASM EXTERNAL - datafiles, archives, FRA |
Sample n4-highmem-8 in this solution; OLTP workloads typically use c4-standard-*.
What's next?
To choose the deployment path that matches your recovery and availability goals, go to Learn about deployment options for Oracle Database 26ai on Google Cloud NetApp Volumes.