Migrating On-Premises Oracle RAC to Google Cloud: Bare Metal Solution vs. Oracle Database@Google Cloud
Moving an enterprise application to Google Cloud becomes more complicated when its database runs on Oracle Real Application Clusters—Oracle RAC.
The application servers may be straightforward to migrate. The database introduces additional requirements: shared storage, cluster networking, Oracle licensing, application certification, and carefully tested failover behavior.
Google Cloud provides two important options for organizations that want to retain Oracle: Bare Metal Solution (BMS) and Oracle Database@Google Cloud.
Both can support a migration that preserves Oracle RAC, but they offer different infrastructure and operating models. A third option—moving to Cloud SQL for PostgreSQL—changes the database engine and requires a broader modernization effort.
Why Oracle RAC Requires More Than a Database Copy
Oracle RAC allows multiple database instances running on separate servers to access the same database.
Its architecture depends on:
- Shared storage accessible to the cluster nodes.
- A private interconnect for communication between instances.
- Oracle Clusterware and Grid Infrastructure to coordinate the cluster.
- Client connectivity through database services and SCAN, the Single Client Access Name.
Consequently, migrating RAC means recreating a supported database environment, moving the data, and validating application behavior against the new cluster.
The migration should preserve the business capabilities the cluster provides—not simply its node count.
Using Bare Metal Solution to Preserve Oracle RAC
Bare Metal Solution provides dedicated physical servers and storage in regional extensions connected to Google Cloud through low-latency Partner Interconnect connectivity.
This allows organizations to run Oracle on physical infrastructure close to their Google Cloud applications. Google manages the underlying infrastructure, while the customer manages the operating system, Oracle software, cluster, database, and data protection.
For a migration, the target environment can include:
- Multiple BMS servers running the RAC instances.
- Shared storage configured for Oracle ASM.
- A client network for application connections.
- A private network for cluster communication.
- Application servers running in Google Cloud.
Google’s BMS planning documentation explicitly addresses storage and networking configurations for high-availability workloads such as Oracle RAC.
BMS is particularly useful when the immediate goal is to leave the data center while retaining substantial control over the Oracle environment.
A Practical BMS Migration Approach
The following is a planning approach; the exact implementation depends on the source platform, Oracle version, licensed features, and downtime requirements.
1. Assess the Existing Environment
Inventory more than database size and server specifications.
Capture Oracle and Grid Infrastructure versions, patch levels, database options, ASM configuration, peak resource consumption, redo generation, application dependencies, and recovery requirements.
Also identify Oracle-specific application dependencies: PL/SQL packages, database links, external procedures, scheduled jobs, and vendor certification requirements.
These details determine whether the target can preserve the current design or requires changes before migration.
2. Build and Validate the Target RAC Cluster
Provision the BMS infrastructure, configure the operating systems and shared storage, and install the supported Oracle stack.
Configure client access and SCAN name resolution before moving production workloads. Google documents using Cloud DNS to resolve RAC SCAN names for applications connecting from Google Cloud.
Validate the target under representative load. Test node failure, connection recovery, storage performance, and application reconnection behavior.
3. Choose the Data Migration Method
BMS supports established Oracle migration approaches, including Data Guard, RMAN, Data Pump, and GoldenGate. The appropriate choice depends on compatibility and the permitted outage window.
| Method | When to evaluate it | Main planning consideration |
|---|---|---|
| RMAN backup and restore | Physical migration with an acceptable outage window | Restore duration, compatibility, and final synchronization |
| Data Guard | Compatible source and target environments requiring limited downtime | Initial seeding, redo transport, apply lag, and switchover |
| Data Pump | Logical migration or selective movement of schemas | Export/import duration and object dependencies |
| GoldenGate | Logical replication and more flexible migration requirements | Supported objects, replication configuration, and licensing |
For a compatible environment, a common approach is to seed a standby database on BMS, keep it synchronized, and perform a planned switchover.
Compatibility must be checked explicitly. A physical migration from a different operating system or platform cannot be assumed to work without additional planning.
4. Coordinate Database and Application Cutover
Database synchronization alone does not complete the migration.
A cutover runbook should cover stopping application writes, confirming replication has caught up, promoting the target, updating connections, restarting workloads, and verifying transactions.
Define rollback conditions before cutover. Once the new database accepts writes, returning to the original environment requires a method for preserving those changes.
5. Design Disaster Recovery Separately
RAC provides cluster availability; it does not replace a disaster recovery design.
Google documents a BMS architecture with separate RAC clusters in different regional extensions and Data Guard replication between the primary and standby databases. Backup and recovery remain separate requirements.
What Changes With Oracle Database@Google Cloud?
Oracle Database@Google Cloud brings Oracle database services into Google Cloud data centers, with integrations for networking, provisioning, identity, and observability.
The current portfolio includes Exadata Database Service, Autonomous AI Database Service, Base Database Service, and Exadata Database Service on Exascale Infrastructure. These services have different capabilities and operating responsibilities, so they should be evaluated individually.
For an existing mission-critical RAC workload, Exadata Database Service is the most direct comparison to BMS. Oracle’s documented architecture supports RAC on Exadata VM clusters and Data Guard for disaster recovery.
Oracle also documents migration to this service using Zero Downtime Migration, or ZDM. Its physical online workflow uses Data Guard to synchronize compatible source and target databases; logical workflows use Data Pump and, for online migration, GoldenGate. Despite the product name, the application cutover still requires planning and testing.
BMS vs. Oracle Database@Google Cloud
For RAC migration planning, the comparison below focuses on the Exadata service within Oracle Database@Google Cloud.
| Consideration | Bare Metal Solution | Oracle Database@Google Cloud: Exadata |
|---|---|---|
| Infrastructure | Dedicated physical servers and storage in regional extensions | Oracle Exadata infrastructure in Google Cloud data centers |
| RAC support | Customer installs and operates the RAC stack | RAC runs on Exadata VM clusters |
| Operating model | Customer manages OS, cluster, and database lifecycle | Service tooling automates parts of provisioning and lifecycle management; customer responsibilities remain |
| Control | Broad control over OS and Oracle configuration | Configuration follows the Exadata service’s supported model |
| Migration tools | Established Oracle tools, including RMAN, Data Guard, Data Pump, and GoldenGate | Oracle ZDM provides documented migration workflows |
| Primary attraction | Retaining operational control and familiar practices | Adopting Exadata and Oracle cloud service automation |
These differences follow the documented infrastructure, responsibility, and migration models.
The architectural decision is therefore broader than “Which service runs Oracle?”
How much of the current operating model should the organization retain, and how much should it move into a cloud database service?
Where Cloud SQL Fits
Cloud SQL becomes relevant when the organization wants to move away from Oracle.
Google Database Migration Service supports migrating Oracle databases to Cloud SQL for PostgreSQL. That process includes converting Oracle schemas and code objects to PostgreSQL syntax and then migrating the data.
This changes the scope of the project.
| Migration target | Database engine after migration | What happens to RAC? |
|---|---|---|
| BMS | Oracle | RAC can be retained |
| Oracle Database@Google Cloud: Exadata | Oracle | RAC can be retained on the target service |
| Cloud SQL for PostgreSQL | PostgreSQL | Availability must be redesigned for the target platform |
A PostgreSQL migration also requires application testing for SQL behavior, stored procedures, data types, drivers, and transaction semantics.
Schema conversion helps move the database objects. It does not establish that the application behaves correctly.
Compare Total Cost and Operational Effort
For an architecture decision, compare the complete production environment:
- Compute and storage.
- Database licenses and support.
- Standby capacity and backups.
- Connectivity.
- DBA and operating system administration.
- Migration, testing, and application changes.
Google does not supply Oracle licenses for BMS; customers are responsible for obtaining and complying with them. Oracle Database@Google Cloud offers BYOL arrangements, subject to the applicable service and agreement.
Neither platform should be assumed cheaper without sizing the workload and reviewing the commercial terms.
Choosing the Right Path
My architectural recommendation is to start with the desired end state:
Evaluate BMS when retaining control over the Oracle stack and minimizing changes to existing operating practices are major priorities.
Evaluate Oracle Database@Google Cloud Exadata when the organization wants to retain RAC while adopting Exadata infrastructure and service automation.
Evaluate Cloud SQL for PostgreSQL when the organization is prepared to change database engines, refactor dependencies, and redesign availability.
For an enterprise RAC migration, success means more than moving data into Google Cloud. It means preserving transaction integrity, recovery capability, application performance, and the operational practices the business depends on.
