Oracle Database @Google Cloud - Multi Cloud

 

👉 What this diagram is about (view)

This picture shows how Oracle Cloud and Google Cloud are directly connected by a fast private road.

• Oracle Cloud = one city

• Google Cloud = another city

• Interconnect = a private highway between the two cities

• No public internet involved

🔹 Simple story

Your application is in Google Cloud
Your database is in Oracle Cloud

Instead of sending data over the public internet (slow + risky),
Oracle and Google built a dedicated private connection just for customers.

🔵 Diagram 2: Oracle Database @ Google Cloud (September 2024)

👉 What this diagram is about (Layman view)

This picture shows Oracle Database running inside Google Cloud itself.

Not connected from outside — it is already there.

🔹 Simple story

Your application is in Google Cloud
Your Oracle database is ALSO in Google Cloud

Oracle installs and manages its database inside Google’s data center, but:

• Oracle still controls the database

• Google still controls the cloud

🔹 What happens here

• No cross-cloud traffic

• No interconnect needed

• App and DB talk like neighbors

• Extremely low latency

• Oracle handles DB operations

• Google handles infrastructure

Oracle Database@Google Cloud runs Oracle-managed OCI database infrastructure colocated within Google Cloud regions. 

Applications use native GCP services, while databases run on OCI Exadata with OCI networking constructs such as VCN and subnets. 

Connectivity between GCP VPCs and OCI networks is privately managed by Oracle, eliminating the need for interconnects or public networking. 

The OCI control plane remains in Oracle Cloud, while the data plane resides inside Google Cloud, providing low latency, high availability, and full Oracle-managed database operations.

Inside Google data center, Oracle does this:

• Oracle installs multiple independent racks

• Each rack group has:

  • Independent power feeds

  • Independent network paths

  • Independent storage

• Oracle labels these internally as:

  • AD-1

  • AD-2

  • FD-1 / FD-2 / FD-3

⚠️ These AD/FD are OCI logical constructs,
not Google’s zones.

Who manages what (VERY IMPORTANT)

Layer	Who manages it
Building, power, cooling	Google
Physical servers, storage	Oracle
Network between Oracle racks	Oracle
Oracle Exadata / ADB	Oracle
AD / FD logic	Oracle
Patching, backups, RAC	Oracle
App (VMs, GKE, Cloud Run)	You / Google

So Oracle is running OCI inside GCP, not OCI on top of GCP.

Multi-AD / HA in Oracle DB @ GCP

Example: Autonomous Database

• Oracle deploys:

  • Primary DB in one Oracle AD

  • Standby DB in another Oracle AD

• Both ADs are inside same GCP region

• Failover handled by Oracle

👉 From DB point of view:
Same HA behavior as OCI region

=========================================================================

This diagram is not about architecture — it is about how easy Oracle Database@Google Cloud is to buy, operate, and use.
Think of it as customer journey + operations flow.

I’ll explain it step by step, in plain technical language, then summarize it in one clean mental model.

---

1️⃣ What this diagram represents (big picture)

Goal of the diagram:
👉 “Oracle Database behaves like a native Google Cloud service, even though Oracle manages it underneath.”

So this diagram answers:

• How do you buy it?

• How do you deploy & manage it?

• How do you use it with other GCP services?

---

2️⃣ Step 1: Purchase in Google Cloud Marketplace

What happens technically

• Oracle publishes Oracle Database@Google Cloud as a Marketplace offering

• You subscribe using:

  • Your Google Cloud account

  • Your Google billing

• No separate Oracle contract process

Key technical implication

• Billing appears in GCP Billing

• IAM access tied to GCP project

• Subscription links your GCP project ↔ Oracle tenancy

📌 Under the hood:
Google forwards subscription metadata to Oracle → Oracle activates OCI resources.

---

3️⃣ Step 2: Deploy, manage, and monitor from Google Cloud Console

This is the most important part of the diagram.

What you see

• Oracle Database appears as a service inside GCP Console

• You can:

  • Create Exadata / Autonomous DB

  • Scale CPU / storage

  • View metrics

  • Monitor health

What happens under the hood

Action in GCP Console	Actual execution
Create DB	Oracle Control Plane
Scale DB	OCI automation
Patch DB	Oracle SRE
Monitor DB	OCI metrics bridged to GCP Monitoring

📌 UI = Google
📌 Brain = Oracle

---

4️⃣ Instance creation screen (middle image)

This screen shows:

• DB shape selection

• Storage sizing

• CPU configuration

• Region mapping

Important technical detail

You are not choosing GCP machine types.

You are choosing:

• Oracle Exadata shape

• Oracle storage layout

• Oracle HA configuration

Oracle maps this to its OCI hardware inside GCP DC.

---

5️⃣ Monitoring & metrics (graph screen)

• Metrics appear in Google Cloud Monitoring

• Data source is Oracle DB telemetry

• Metrics include:

  • CPU utilization

  • Storage usage

  • I/O behavior

📌 Monitoring is integrated, not duplicated
📌 No need to log into OCI console separately (unless deep DBA ops)

---

6️⃣ Step 3: Combine with your choice of Google Cloud services

This right-most part shows native GCP services:

• Compute Engine

• GKE

• Cloud Run

• BigQuery

• Vertex AI

• VPC Network

• Cloud Storage

Technical meaning

• Apps connect to Oracle DB over private OCI-managed network

• Latency is intra-datacenter

• No VPN, no Interconnect, no public IP

Result

• Google apps feel like they are talking to a native database

• Oracle DB keeps OCI-grade reliability

=========================================================================

Google runs the application, Oracle runs the database — both inside the same Google Cloud zone, but with separate ownership.

---

🔁 Concept Mapping (Google ↔ Oracle)

🟦 Google Cloud side

• Project (Google) → Your billing + IAM + resources container

• VPC (Google) → Network for your applications

• Zone (Google) → Physical location where your app VM/GKE runs

• Application Subnet → App lives here

---

🟥 Oracle Cloud side (inside Google DC)

• Tenancy (Oracle) → Oracle’s account that owns the DB

• VCN (Oracle) → Oracle’s private network for DB

• AD (Oracle) → Oracle’s fault-isolated deployment unit

• Client / DB / Backup Subnets → Oracle DB traffic separation

---

🔌 How they connect

• App in GCP VPC talks to DB in OCI VCN

• Connection is via OCI-managed private network

• No public IP, no VPN, no interconnect

---

🧠 One-line memory trick

Project ↔ Tenancy
VPC ↔ VCN
Zone ↔ AD
App ↔ DB (private, Oracle-managed)

---

Onboarding:-

Note:-

Patching - As DBA we need to do it (GRID + Oracle) - ExaCC / ExaCS / DBCS 

Creating Autonomous Database :-

Create Exadata@GCP 

OIC instance in OCI

 

OCI vs OIC – Know the Difference in Oracle Cloud When you're exploring Oracle Cloud, two terms that sound similar — but do very different jobs — are: 🔹 OCI – Oracle Cloud Infrastructure 🔹 OIC – Oracle Integration Cloud Here’s a quick breakdown to clear the confusion 👇 🔷 What is OCI? (Oracle Cloud Infrastructure) OCI is Oracle’s core cloud platform — a suite of Infrastructure-as-a-Service (IaaS) offerings. It provides the foundation to build and run any application with services like: 🖥️ Compute (VMs, bare metal) 💾 Storage (block, object) 🌐 Networking (VCN, Load Balancer) 🔐 Identity & Access (IAM, Vault) 🧠 Think of OCI as the “ground floor” where cloud apps and services are built and hosted. 🔷 What is OIC? (Oracle Integration Cloud) OIC is a Platform-as-a-Service (PaaS) built on top of OCI. It’s designed to help you: 🔗 Connect Oracle and third-party apps (like ERP, HCM, Salesforce, etc.) 🔁 Automate business workflows ⚙️ Expose and consume REST/SOAP APIs 👨💻 Build integrations with low-code tools 🧠 Think of OIC as the “connector layer” that moves data between systems. 📌 Key Differences: 👉 Type • OCI – IaaS (Infrastructure) • OIC – PaaS (Integration Platform) 👉 Purpose • OCI – Host applications, storage, security • OIC – Connect apps and automate processes 👉 Used By • OCI – Cloud/Infra Engineers, DevOps • OIC – Integration Developers, Architects 👉 Example Use • OCI – Launch a virtual machine • OIC – Integrate Oracle ERP with Salesforce 👉 Relationship • OCI – Base platform • OIC – Runs on top of OCI 🚀 In short: OCI is the engine room of Oracle Cloud. OIC is one of the many tools that runs on OCI — designed to simplify integration.

Back End

Front End

SAML in OCI

 

First, set the roles clearly (very important)

• Nizam → Apple employee

• Azure AD (or On-prem AD + ADFS/Okta) → Identity Provider (IdP)

• OCI Identity Domain → Service Provider (SP)

• OCI Console → What Nizam wants to access

👉 OCI does NOT authenticate users directly in this setup.
👉 OCI trusts Apple’s Identity system via SAML.

---

Why SAML is needed (big picture)

Enterprises never want separate passwords for each cloud.

So:

• User identity = Enterprise control (AD / Azure AD / Okta)

• Cloud access = Federated using SAML

• Result = Single Sign-On (SSO)

That’s why you wrote correctly:

99% customers map cloud auth with on-prem AD / OKTA

---

Now the STEP-BY-STEP FLOW (mapped to your numbers)

---

🔹 STEP 1: Nizam tries to access OCI Console

📌 (Your arrow #1)

• Nizam opens browser

• Goes to:
  https://cloud.oracle.com

• Selects Apple’s OCI Identity Domain

• Enters email: nizam@apple.com

👉 At this point:

• OCI sees: This domain uses SAML

• OCI knows: I am NOT responsible for password validation

---

🔹 STEP 2: OCI redirects Nizam to Apple Identity Provider

📌 (Your arrow #2)

OCI sends a SAML Authentication Request to Azure AD.

This request says:

“Hey Azure AD,
Someone named nizam@apple.com wants to log in.
Please authenticate him and tell me who he is.”

🔁 Browser is redirected to:

• Azure AD login page (or ADFS / Okta)

👉 OCI console is now waiting

---

🔹 STEP 3: Azure AD validates Nizam (real authentication)

📌 (Inside Apple on-prem / Azure AD box)

Now real security checks happen:

• Password verification

• MFA (OTP / Authenticator / SMS)

• Conditional access

• Device trust

• Location rules

If ❌ fails → OCI never sees Nizam
If ✅ success → Azure AD proceeds

---

🔹 STEP 4: Azure AD sends SAML Response back to OCI

📌 (Your arrow #3)

Azure AD creates a SAML Assertion (signed XML).

It contains:

• ✔ User identity: nizam@apple.com

• ✔ Group membership (e.g. OCI-Admins)

• ✔ Tenant / domain info

• ✔ Timestamp & signature

This message says:

“OCI, I confirm Nizam is authenticated.
Here are his attributes and groups.
You can trust this.”

👉 Browser auto-posts this back to OCI.

---

🔹 STEP 5: OCI validates trust (critical step)

OCI does NOT blindly accept the response.

OCI checks:

• Signature is valid?

• Certificate matches Azure AD?

• Assertion not expired?

• User exists in OCI Identity Domain?

• Group mapping exists?

If ❌ → Access denied
If ✅ → Login allowed

---

🔹 STEP 6: OCI maps Nizam to OCI Groups & Policies

Example mapping:

Azure AD Group → OCI Group
--------------------------------
OCI-Admins     → OCI_Admins
OCI-ReadOnly   → OCI_ReadOnly

OCI Policies:

Allow group OCI_Admins to manage all-resources in tenancy

👉 This defines what Nizam can do, not Azure AD.

---

🔹 STEP 7: Nizam gets OCI Console access 🎉

• OCI session is created

• Token/cookie issued

• OCI Console loads

Now Nizam can:

• View compartments

• Manage compute, DB, network

• According to OCI IAM policies

---

Important clarification (common confusion)

❌ Nizam does NOT log in to OCI directly
❌ OCI does NOT store his password

✔ OCI outsources authentication
✔ OCI keeps authorization

---

One-line summary (interview perfect answer)

OCI acts as a Service Provider, Azure AD acts as an Identity Provider, and SAML is used to federate authentication so that enterprise users can securely access OCI using their corporate credentials without managing passwords in OCI.

 

Create Bucket and IAM policy in OCI

 

The Oracle Cloud Infrastructure policy specifies who has access to which resources in OCI. Policies simply allow a group to manage certain types of resources in a specific compartment in certain ways.

Policy basic Syntax:

Allow group <group_name> | <group_ocid> to <verb> <resource-type> in compartment <compartment_name>

Allow group <group_name> | <group_ocid> to <verb> <resource-type> in tenancy

Verbs:

inspect: Resource listing without access to confidential information or user-specified metadata.
read: It includes inspect as well as the ability to get user-specified metadata as well as the resource itself.
use: Includes reading and working with existing resources. Includes updating the resource, except for resource types where “update” has the same effect as “create”. In general, this verb doesn’t include the ability to create or delete.
manage: Includes all permissions associated with the resource.

Resource types:

all-resources: All Oracle Cloud Infrastructure resource-types
compute-management-family: Compute
database-family: Autonomous Database, Bare Metal and Virtual Machine DB Systems
virtual-network-family: Networking

Admin:-

sankar is in storage admin group

Storage Policy:- 

Resources

Statements

Edit Policy Statements

allow group STORAGE-ADMIN to manage buckets in compartment test-dev-cmp

allow group STORAGE-ADMIN to manage instance-family in compartment test-dev-cmp where request.permission != 'INSTANCE_DELETE'

allow group STORAGE-ADMIN to use virtual-network-family in compartment test-dev-cmp

allow group STORAGE-ADMIN to use subnets in compartment test-dev-cmp

Sankar:-

Admin:-

allow group STORAGE-ADMIN to manage users in compartment test-dev-cmp

Note:- Sankar will be able to see the users or not

In order to have a users, group , domain , it should be added at root level.

Policy should be at root level

Default Domain - that's why sankar is not able to see users

Admin:-

Creating Group -  IAM-Group

Creating Policy - IAM-Policy

Adding Sankar into group 

Sankar - still facing issue because of IAM policy 

Admin:- Manage Vs Read

Sankar:- Now Sankar is able to see by adding policy 

Policy :-