Oracle Database@Google Cloud: Connecting Google Cloud Applications with Exadata

On this page

1. 01 · A Short Path With Sharp Edges
2. 02 · How the Network Fits Together
3. 03 · Getting Each Runtime Onto the Private Path
4. 04 · DNS, Firewall Rules and Routes
5. 05 · When the App Cannot Reach the Database
6. 06 · Pitfalls to Avoid Before Go-Live
7. 07 · Beyond Connectivity: Identity, Monitoring and Data
8. 08 · Key Takeaways
9. 09 · Frequently Asked Questions

01 · A Short Path With Sharp Edges

Integration brief · Google Cloud applications to Exadata

"It works from the VM. It fails from GKE and Cloud Run."

That sentence turns up in a lot of first-week tickets on Oracle AI Database@Google Cloud (launched in September 2024 as Oracle Database@Google Cloud). The Exadata VM cluster is running, a Compute Engine VM in the same VPC connects in milliseconds, and then the containerised version of the same application cannot reach the database at all. The database is fine. The difference is in how each Google Cloud runtime resolves names and sends packets.

Google Cloud networking has its own rules that Oracle teams coming from on-premises or OCI do not always expect: VPCs are global, VPC Network Peering is not transitive, serverless products need explicit VPC egress, and private DNS zones are visible only to the networks they are bound to. None of these is hard on its own. Together, they decide whether every application reaches the database on the first try.

02 · How the Network Fits Together

Answer: When you create an Exadata VM cluster in Oracle AI Database@Google Cloud, you attach it to a VPC and give it two address ranges: a client subnet for application traffic and a backup subnet for backups. The SCAN listener and node VIPs live in the client range, and Google Cloud workloads reach them over private routing in the same region.

The Exadata hardware itself sits in an Oracle-operated OCI child site inside the Google Cloud data center. OCI's control plane in a parent region builds, patches and scales the infrastructure. What your applications see is a set of private IP addresses on your network, published under host names in a private DNS zone.

The figure below shows the components most designs include. Compute Engine VMs, GKE pods and Cloud Run services share a set of app subnets in the customer VPC. They converge on the client subnet, where the SCAN and VIP addresses live. Cloud DNS answers for the SCAN name. Backups leave through the backup subnet. The OCI parent region sits off to the side as the control plane.

The blue arrow labelled "same data center" is the reason to use Database@ at all: application-to-database round trips stay inside one facility. The orange backup path and the red control-plane path never carry application traffic, so firewall rules for applications only need to cover the client subnet.

03 · Getting Each Runtime Onto the Private Path

Answer: Compute Engine VMs reach the client subnet directly. GKE clusters should be VPC-native so pod addresses are routable. Cloud Run and Cloud Run functions need Direct VPC egress or a Serverless VPC Access connector, with private ranges routed into the VPC. On-premises clients come in over Cloud Interconnect.

Compute Engine

The simplest case. A VM in an app subnet of the same VPC routes to the client subnet with the VPC's own routes. You need an egress firewall rule if your VPC denies egress by default, and the database-side rules must allow the app subnet range.

GKE

Use VPC-native clusters, where pods get addresses from a secondary range of the node subnet. Those addresses are routable inside the VPC, so the database sees real pod source IPs and your allow rules can name the pod range. Be careful with egress NAT or masquerading configurations that rewrite pod addresses to node addresses: either is fine, but your firewall rules must match what the database actually sees. Store the database wallet or credentials as a Kubernetes secret, ideally synced from Secret Manager.

Cloud Run

Cloud Run services do not live in your VPC. Configure Direct VPC egress (or a Serverless VPC Access connector) and route at least private ranges through it. Without that setting the service tries to reach the SCAN address over its default egress and times out. Keep connection pools small: each instance opens its own pool, and autoscaling can multiply sessions quickly.

04 · DNS, Firewall Rules and Routes

Answer: Bind the database's private DNS zone to every VPC with clients, using DNS peering zones for other VPCs and an inbound server policy for on-premises forwarding. Allow TCP 1521 (and 2484 for TLS) from client ranges to the whole client subnet. Remember that VPC Network Peering is not transitive.

Applications should always connect to the SCAN host name. The service publishes the cluster's host names in a private zone visible to the VPC you attached the cluster to. Any other VPC, and any on-premises network, needs an explicit way to see that zone. In Cloud DNS that means a DNS peering zone in the other VPC pointing at the database VPC, and for on-premises an inbound server policy whose entry addresses your corporate DNS servers forward the database domain to.

# From each client network: VM, GKE debug pod, Cloud Run job, on-prem host
nslookup exa-clu1-scan.db.example.internal     # expect the SCAN IPs
nc -zv exa-clu1-scan.db.example.internal 1521  # TCP reachability
tnsping exa-clu1-scan.db.example.internal:1521/app_svc.example.internal

For firewall rules, think in two directions. On the Google Cloud side, VPC firewall rules or a network firewall policy must permit egress from the app ranges to the client subnet on the listener ports. On the database side, the security rules that guard the VM cluster's client interfaces must permit ingress from the same app ranges. Allow the whole client subnet, not only the three SCAN addresses, because the SCAN listener redirects each connection to a node VIP.

05 · When the App Cannot Reach the Database

Answer: Check five things in order: name resolution, the TCP port, routes in both directions, the listener and service, and the TLS handshake. Fix the first check that fails and start again from the top, because a later check cannot pass while an earlier one fails.

Connection errors from Oracle clients are not very specific. A missing route, a dropped packet and an unresolvable host can all surface as ORA-12170 or a driver timeout. The decision flow below gives you a fixed sequence so two engineers debugging the same issue reach the same answer. Each question on the left is a check you can run from the failing client; each orange box on the right is the fix when the answer is no.

The order matters. A TLS error is meaningless if the TCP port is closed, and a closed port tells you nothing if the client resolved the wrong address. The green "yes" arrows only move down once a check has passed from the failing client itself, not from a VM that happens to work.

1. Run every test from the failing runtime. Use a debug pod in the same GKE namespace, or a Cloud Run job with the same egress settings. Tests from a working VM prove nothing about the failing path.
2. Read the listener side. On a database node, lsnrctl status LISTENER_SCAN1 and srvctl status service -db CDB1 show whether the service is registered and running.
3. Check effective routes. In the console or with gcloud, inspect the routes the client's VPC actually has, including peering and Cloud Router routes.
4. Use VPC Flow Logs and firewall logging. Denied packets in firewall rules logging point straight at the missing rule.

06 · Pitfalls to Avoid Before Go-Live

Answer: Most connectivity problems on Oracle AI Database@Google Cloud are design issues that can be fixed before provisioning: overlapping ranges, assuming peering is transitive, serverless without VPC egress, firewall rules that cover only SCAN addresses, DNS visible in one VPC only, and applications pinned to one node.

The comparison below pairs each pitfall with its fix. Treat the left column as a design review checklist: if a reviewer cannot answer how the design avoids each one, the design is not finished.

The last row is the only one that is not a network issue. Exadata is a RAC cluster, and rolling patching restarts instances regularly. Applications that connect by IP to one node will see every maintenance window as an outage, however good the network design is.

APP_SVC =
 (DESCRIPTION =
   (CONNECT_TIMEOUT=90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
   (ADDRESS_LIST = (LOAD_BALANCE=on)
     (ADDRESS = (PROTOCOL=TCP)(HOST=exa-clu1-scan.db.example.internal)(PORT=1521)))
   (CONNECT_DATA = (SERVICE_NAME=app_svc.example.internal)))

07 · Beyond Connectivity: Identity, Monitoring and Data

Answer: Once the data path works, connect the operations layer: Google Cloud IAM controls who can manage the service, Cloud Monitoring and Cloud Logging receive metrics and events, and data can flow to BigQuery or Vertex AI for analytics and AI use cases.

Keep the layers clear. Google Cloud IAM roles decide who can create, scale or delete Exadata resources from the console and APIs. Database users and roles still decide who can log in and what they can read. Do not grant broad project roles to application service accounts just because they talk to the database: they need network reach and database credentials, not permission to manage the cluster.

For analytics and AI, the common patterns are replicating or exporting selected data into BigQuery, and calling Vertex AI models from applications that read Oracle data. Each path adds its own network and identity requirements, so design it as a separate integration with its own review, not as a side effect of opening the database to the whole VPC.

On Google Cloud the shortest path to Exadata is also the most private one. Most failures come from a runtime that was never put on that path.

08 · Key Takeaways

1. Two ranges per VM cluster. A client subnet for SCAN and VIPs, a backup subnet for backups. Neither may overlap anything the VPC can see.
2. Put each runtime on the private path. VPC-native GKE, Cloud Run with VPC egress, and Interconnect with advertised routes for on-premises.
3. Peering is not transitive. Hub designs need Shared VPC, direct peering or an appliance; confirm what the service supports.
4. Debug in a fixed order. DNS, firewall, routes, listener, TLS, always from the failing runtime itself.
5. Design for RAC behaviour. SCAN name, a dedicated service, FAN and Application Continuity turn patching into a non-event.

09 · Frequently Asked Questions