Oracle Cloud Exadata Database Service on Cloud@Customer Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Data Management

1. Introduction

What this service is

Exadata Database Service on Cloud@Customer is an Oracle Cloud (OCI) database service that delivers Oracle Exadata infrastructure in your data center while using Oracle Cloud’s operational model, APIs, and console to provision and manage Oracle Database.

One-paragraph simple explanation

If you need Oracle Database and Exadata performance but must keep data on-premises (for latency, sovereignty, or regulatory reasons), Exadata Database Service on Cloud@Customer provides a cloud-managed Exadata platform installed in your facility. You manage databases through the same OCI-style workflows (compartments, IAM policies, console/CLI), while the data stays local.

One-paragraph technical explanation

Technically, this service combines Exadata hardware (database servers, storage servers, high-speed networking) with an OCI-managed control plane to create and operate Exadata VM Clusters, database homes, and Oracle databases (commonly Oracle RAC-enabled, depending on configuration) on customer premises. It uses OCI Identity and Access Management (IAM) for authorization, OCI-style resource models (compartments, tags), and integrates with OCI observability and audit capabilities where applicable. Exact integration details can vary by Cloud@Customer deployment—verify in official docs for your environment.

What problem it solves

It solves the common enterprise requirement: run mission-critical Oracle Database workloads with Exadata performance and availability, but keep the infrastructure and data inside the customer’s own facilities, while still gaining cloud-like provisioning, lifecycle management, and standardized governance.

2. What is Exadata Database Service on Cloud@Customer?

Official purpose

Exadata Database Service on Cloud@Customer is designed to provide Oracle Exadata and Oracle Database capabilities on customer premises with cloud operational consistency (resource model, APIs, automation) aligned to Oracle Cloud.

Naming note: Oracle marketing and documentation sometimes refer to “Exadata Cloud@Customer” alongside “Exadata Database Service on Cloud@Customer.” Treat Exadata Database Service on Cloud@Customer as the primary service name, and verify the latest naming and scope in official OCI documentation.

Core capabilities (what it can do)

At a high level, you can: – Provision and manage Exadata database environments on-premises using OCI-style tooling. – Create Exadata VM Clusters to allocate compute resources. – Create database homes (Oracle Database software homes) and then create databases. – Apply lifecycle operations (scale, patch, maintenance workflows) using supported OCI procedures. – Implement enterprise-grade security controls (IAM, network segmentation, encryption options). – Monitor and audit operations using OCI-aligned logging/metrics where supported.

Major components

Common components you’ll see in OCI workflows for this service include (terminology can vary slightly by release—verify in official docs): – Exadata Infrastructure: The underlying Exadata hardware system installed on-premises and registered/managed through OCI workflows. – Exadata VM Cluster: A logical allocation of compute (VMs) on the Exadata database servers where Oracle Database runs. – Database Home (DB Home): The Oracle Database software installation (version + patch level) used to create one or more databases. – Database (often CDB/PDB model): The database instances you create and run (commonly multitenant architecture). – Networking: Client access networks (subnets/VLANs) and DNS considerations in your on-prem environment. – IAM + compartments + policies: OCI-style governance boundary and access control.

Service type

Managed database service on customer premises (cloud-managed control plane, on-prem data plane).
Designed for enterprise production workloads with strict requirements.

Scope (regional / zonal / account-scoped)

Because this is a Cloud@Customer offering: – The infrastructure is physically installed in your data center. – Management is performed through an Oracle Cloud tenancy and OCI-style APIs/console. – Availability is tied to your Cloud@Customer site rather than a public OCI region/availability domain. – Resource scoping commonly follows OCI patterns: – Tenancy (account-level) – Compartments (project/environment boundaries) – Policies (authorization)

Exact scoping and “region” representation can differ depending on how your Cloud@Customer is integrated—verify in official docs for your deployment model.

How it fits into the Oracle Cloud ecosystem

Exadata Database Service on Cloud@Customer fits into Oracle Cloud’s Data Management portfolio as the on-prem counterpart to Exadata-based OCI services. It typically aligns with: – OCI IAM (identity, policies) – OCI tagging (governance, cost tracking) – OCI Monitoring/Logging/Audit (observability and governance—capabilities can vary by deployment) – OCI networking concepts (VCN-like segmentation or on-prem equivalents, depending on architecture)

3. Why use Exadata Database Service on Cloud@Customer?

Business reasons

Data residency and sovereignty: Keep sensitive data on-premises to meet legal/regulatory constraints.
Risk reduction: Modernize operations without a full data center exit or immediate re-platforming.
Standardization: Apply cloud-like governance (compartments, policies, automation patterns) consistently.
Procurement preference: Some organizations prefer subscription/managed service models even on-premises (exact commercial terms vary).

Technical reasons

Exadata performance: Optimized database + storage architecture for Oracle Database workloads.
Consolidation: Run multiple databases on a shared engineered system.
Compatibility: Supports Oracle Database workloads that may not be eligible for Autonomous or require OS-level/database-level control.
Hybrid architecture: Keep core systems on-prem while integrating with Oracle Cloud services as allowed.

Operational reasons

Managed lifecycle: Supported processes for provisioning, patching, scaling, and maintenance.
Consistency: Similar operational constructs to OCI public cloud Exadata Database Service.
Automation: API/CLI-driven operations (where enabled) reduce manual runbooks.

Security/compliance reasons

Controlled perimeter: Database servers and storage remain in your facility.
IAM governance: Centralized identity/policy model consistent with OCI.
Auditability: OCI-style audit trails for supported operations; OS/database auditing remains available as well.

Scalability/performance reasons

Scale up/out within the engineered system: Expand CPU allocation, storage capacity (subject to your installed system’s limits).
Predictable latency: On-prem proximity to applications that can’t move to cloud.

When teams should choose it

Choose Exadata Database Service on Cloud@Customer when you have: – Latency-sensitive apps located on-prem. – Regulatory requirements preventing data from leaving premises. – Large Oracle estates needing consolidation with strong performance. – A desire to standardize operations on OCI-style governance while staying on-prem.

When teams should not choose it

Avoid it (or reconsider) if: – You want a fully public cloud service without on-prem hardware. – You do not need Exadata characteristics and could use simpler managed databases. – Your team cannot support on-prem networking, facilities, and operational prerequisites. – Your workloads are better suited to Autonomous Database (less administrative control, more automation) and can run in OCI regions.

4. Where is Exadata Database Service on Cloud@Customer used?

Industries

Commonly adopted in industries with strict compliance and large Oracle footprints: – Financial services (banking, payments, trading) – Telecommunications – Government and public sector – Healthcare and life sciences – Manufacturing and supply chain – Retail (large-scale ERP/CRM backends)

Team types

Platform engineering teams running shared database platforms
DBAs modernizing operational practices
SRE/Operations teams needing standardized lifecycle processes
Security teams enforcing centralized IAM and audit
Solution architects designing hybrid and regulated architectures

Workloads

ERP (e.g., Oracle E-Business Suite, Oracle Fusion-related integrations, Oracle-based ERPs)
Core OLTP systems (high throughput, low latency)
Mixed OLTP + reporting (where Exadata offload benefits apply—verify workload fit)
Data consolidation and multi-tenant database hosting
Legacy Oracle workloads requiring OS or database-level customizations

Architectures

On-prem application tier + on-prem Exadata Database Service on Cloud@Customer
Hybrid: on-prem database + OCI application tier (or vice versa) connected via FastConnect/VPN (subject to design constraints)
Hub-and-spoke governance using OCI compartments/policies, with environment segmentation (prod/dev/test)

Real-world deployment contexts

Data centers with strict physical security and controlled network egress
Edge-like deployments for ultra-low latency (within enterprise campuses)
Transitional environments while moving selected components to public OCI

Production vs dev/test usage

Production: Common for mission-critical systems where on-prem data residency is mandatory.
Dev/Test: Also used, but may be constrained by the fixed nature/cost of on-prem Exadata capacity. Many teams instead run dev/test in OCI public regions and reserve Cloud@Customer capacity for production—your policy and compliance posture will dictate.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Exadata Database Service on Cloud@Customer is typically a strong fit.

1) Regulated banking core ledger on-prem

Problem: Regulations require customer financial data to remain within a specific facility.
Why this service fits: Keeps data on-prem while enabling cloud-like lifecycle management and governance.
Example scenario: A bank runs core ledger and payment settlement databases locally but uses OCI-style IAM controls and standardized provisioning.

2) Low-latency telecom billing

Problem: Real-time rating/billing requires sub-millisecond network latency to local application clusters.
Why this service fits: On-prem placement reduces latency; Exadata supports high throughput.
Example scenario: Telecom charging systems run in the same data center, with databases on Exadata Database Service on Cloud@Customer.

3) ERP consolidation for a global manufacturer

Problem: Many Oracle databases across plants and regions cause operational sprawl.
Why this service fits: Consolidation on engineered infrastructure with standardized operations and strong performance.
Example scenario: Consolidate dozens of Oracle databases into fewer consolidated CDBs with separate PDBs per plant/business unit.

4) “Cloud operating model” without moving data offsite

Problem: Security policy blocks production data from public cloud, but the organization wants cloud governance and automation.
Why this service fits: OCI-style resource model and controls applied to on-prem databases.
Example scenario: Central IAM policies and compartment structure mirror OCI, enabling consistent governance.

5) Oracle RAC modernization with managed lifecycle

Problem: Self-managed RAC is operationally heavy, patching and scaling are risky.
Why this service fits: Provides supported workflows for lifecycle operations on Exadata.
Example scenario: Move from older on-prem RAC clusters to Exadata Database Service on Cloud@Customer and adopt standardized patch windows.

6) Hybrid DR strategy with OCI Object Storage (where supported)

Problem: Offsite backups and/or DR copies are needed without full database relocation.
Why this service fits: Can integrate with OCI services depending on connectivity and supported features.
Example scenario: Send backups to OCI Object Storage over private connectivity; verify supported backup targets and configurations.

7) Data gravity: database cannot move, apps can

Problem: Database must remain local; some app components can move to OCI.
Why this service fits: Database remains on-prem; application tier can modernize in OCI.
Example scenario: Microservices in OCI access on-prem database over FastConnect/VPN with strict network controls.

8) Performance “escape hatch” for critical OLTP

Problem: A high-throughput OLTP system hits limits on commodity storage/compute.
Why this service fits: Exadata is engineered for Oracle Database performance.
Example scenario: Critical order processing DB moved to Exadata Database Service on Cloud@Customer to stabilize latency under peak.

9) Secure multi-tenant database hosting for internal teams

Problem: Multiple internal teams need databases with isolation and governance.
Why this service fits: Use compartments, IAM, and multitenant architecture (PDB isolation) for safer consolidation.
Example scenario: Platform team offers “database as a service” to internal application teams on-prem.

10) Gradual migration off legacy data center tooling

Problem: Existing monitoring, ticketing, and manual DB provisioning cause slow delivery.
Why this service fits: Standardized provisioning APIs and repeatable operations reduce manual work.
Example scenario: Replace manual provisioning with OCI console/CLI runbooks and integrate with CI/CD pipelines for database provisioning requests.

6. Core Features

Feature availability can differ by Cloud@Customer configuration and your purchased capabilities. Always verify in official Oracle Cloud documentation for Exadata Database Service on Cloud@Customer.

1) Exadata engineered system on customer premises

What it does: Runs Oracle Database on Exadata hardware installed in your data center.
Why it matters: Delivers engineered performance characteristics and predictable on-prem latency.
Practical benefit: Consolidation, high throughput, optimized database I/O.
Caveats: Requires facilities readiness (power, cooling, rack space) and Oracle-managed installation process.

2) OCI-style resource model (compartments, tags, lifecycle states)

What it does: Represents Exadata infrastructure, VM clusters, DB homes, and databases as OCI resources.
Why it matters: Enables consistent governance, access control, and automation patterns.
Practical benefit: Standard tagging for cost allocation; compartment isolation between teams/environments.
Caveats: Some resource operations may require specific service limits/quotas and operator privileges.

3) Exadata VM Clusters for compute allocation

What it does: Allocates compute (VMs) on Exadata database servers for database workloads.
Why it matters: Separates hardware from workload allocation; supports consolidation and administrative boundaries.
Practical benefit: Scale CPU resources for the cluster (within system limits).
Caveats: Scaling and max limits depend on your installed Exadata configuration and purchased capacity.

4) Database Homes (DB Homes) for software lifecycle management

What it does: Provides a managed Oracle Database software home used to create databases.
Why it matters: Standardizes patching and version control across databases.
Practical benefit: More predictable patch/upgrade management.
Caveats: Supported database versions and patching methods depend on Oracle’s service release and policy.

5) Oracle Database provisioning and management

What it does: Creates databases (often with multitenant architecture) on the VM Cluster.
Why it matters: Core capability for delivering database environments quickly and consistently.
Practical benefit: Repeatable creation workflows; consistent configuration patterns.
Caveats: Options (RAC, single instance, storage management) depend on your system and service configuration.

6) Integrated security controls (IAM authorization + database security)

What it does: Uses OCI IAM for API/console access; still supports Oracle Database-native security (users/roles, TDE, auditing).
Why it matters: Central governance plus strong DB-level security.
Practical benefit: Least privilege policies + separation of duties.
Caveats: You must still design database accounts/privileges correctly; cloud IAM does not replace DB security.

7) Monitoring and operational telemetry (where supported)

What it does: Exposes metrics and operational status via OCI console/APIs; integrates with monitoring tooling depending on environment.
Why it matters: Enables capacity planning and incident response.
Practical benefit: Visibility into resource health and lifecycle operations.
Caveats: Exact metrics/log sources vary—verify what’s available in your Cloud@Customer deployment.

8) Backup and recovery options (configuration-dependent)

What it does: Enables database backup strategies (local and/or remote targets depending on connectivity and supported features).
Why it matters: Backups are mandatory for production reliability and compliance.
Practical benefit: Offsite backups or centralized backup targets.
Caveats: Backup targets (e.g., OCI Object Storage) may require private connectivity and supported configurations—verify official docs and your network posture.

9) Maintenance and patching workflows (service-guided)

What it does: Supports lifecycle operations such as patching with Oracle-recommended procedures.
Why it matters: Reduces risk compared to purely self-managed patching.
Practical benefit: Standard maintenance windows; less downtime risk when using supported rolling methods (where available).
Caveats: Rolling patching and downtime characteristics depend on configuration (RAC vs single instance) and patch type—verify per release.

10) High availability options (architecture-dependent)

What it does: Supports HA patterns using Oracle Database features (e.g., RAC within the system, Data Guard to another site—subject to design and licensing).
Why it matters: Mission-critical systems require resilience.
Practical benefit: Reduced downtime and faster recovery.
Caveats: HA/DR features depend on licensing, architecture, and operational maturity—verify supported reference architectures.

7. Architecture and How It Works

High-level service architecture

Exadata Database Service on Cloud@Customer separates responsibilities: – Control plane: OCI-style console/API/IAM orchestration for resource operations (create VM cluster, DB home, database, lifecycle actions). – Data plane: Actual database compute/storage running on Exadata in your facility; client connections typically remain local unless you intentionally expose them.

Request / data / control flow (conceptual)

An operator or automation pipeline authenticates to Oracle Cloud (IAM).
The operator calls OCI APIs (console/CLI/SDK) to create or modify resources (VM Cluster, DB Home, Database).
The service orchestrates the change on the on-prem Exadata system.
Applications connect to the database over your on-prem network (or hybrid network if designed).
Telemetry and audit events are collected through supported mechanisms.

Integrations with related services (common patterns)

Depending on your Cloud@Customer capabilities and connectivity, typical integrations include: – Oracle Cloud IAM for authentication/authorization to manage resources. – Oracle Cloud Audit for tracking API calls (verify event coverage in docs). – Oracle Cloud Monitoring/Logging for metrics/log ingestion (verify integration specifics). – OCI Object Storage as a backup target if supported and connected (verify). – Networking connectivity: FastConnect/VPN for hybrid use cases (verify design requirements).

Dependency services

You typically depend on: – IAM (users/groups/dynamic groups/policies) – Networking (on-prem VLAN/subnets, routing, DNS; and possibly OCI networking for hybrid) – Key management (database TDE key strategy; OCI Vault may be used in some architectures—verify supported integration) – Backup storage targets (local appliance, NFS, ZDLRA, or OCI Object Storage—verify supported options)

Security/authentication model

OCI IAM governs who can create/modify resources.
SSH and OS-level access (if permitted) must be tightly controlled.
Database authentication/authorization is handled within Oracle Database (users, roles, privileges).
Separation of duties is recommended: IAM admins ≠ DBAs ≠ security auditors.

Networking model (typical)

Client traffic stays within on-prem networks.
Separate networks for:
Client access
Management/administration
Backup/replication (as designed)
DNS is crucial for cluster endpoints and SCAN-style connectivity (if used).

Monitoring/logging/governance considerations

Use compartments and tags for governance.
Capture audit events for administrative actions.
Centralize DB alert logs and OS logs in your SIEM (Splunk/Elastic/etc.) using agents if OCI-native logging is not available or not sufficient.
Establish SLOs (availability, RPO/RTO, performance) and alert thresholds.

Simple architecture diagram (Mermaid)

flowchart LR
  User[Admin / DBA] -->|OCI Console / CLI| IAM[OCI IAM]
  IAM -->|Authorize API calls| ControlPlane[OCI Control Plane]
  ControlPlane -->|Provision / Patch / Scale| ExaCAtC[Exadata Database Service on Cloud@Customer\n(On-Prem Exadata)]
  App[On-Prem Apps] -->|SQL*Net / JDBC| ExaCAtC
  ExaCAtC --> Telemetry[Metrics / Logs / Audit (as supported)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Governance["Oracle Cloud Governance"]
    IAM2[OCI IAM\nUsers/Groups/Policies]
    Audit[OCI Audit\nAPI activity]
    Tags[Compartments + Tags]
  end

  subgraph OnPrem["Customer Data Center"]
    subgraph Net["Network Segmentation"]
      ClientNet[Client Subnet/VLAN]
      AdminNet[Admin Subnet/VLAN]
      BackupNet[Backup/Replication Network]
    end

    subgraph Exa["Exadata Database Service on Cloud@Customer"]
      ExaInfra[Exadata Infrastructure]
      VMCluster[Exadata VM Cluster]
      DBHome[Database Home]
      DB[Oracle Database\n(CDB/PDB, RAC if configured)]
    end

    Apps[App Tier / Middleware] -->|JDBC/SQL*Net| DB
    Admins[DBA / Ops Jump Host] -->|SSH + Admin tools| VMCluster
  end

  IAM2 --> Control[OCI APIs / Console]
  Tags --> Control
  Control -->|Lifecycle ops| ExaInfra
  Control -->|Create| VMCluster
  Control -->|Create| DBHome
  Control -->|Create| DB

  Control --> Audit
  Exa --> Obs[Monitoring/Logging\n(as supported)]
  BackupTarget[(Backup Target:\nLocal / ZDLRA / OCI Object Storage*)]
  DB -->|RMAN backups| BackupTarget

  note1["*OCI Object Storage backups require supported configuration\nand network connectivity. Verify in official docs."]:::note

  classDef note fill:#f6f6f6,stroke:#999,color:#333;

8. Prerequisites

Because Exadata Database Service on Cloud@Customer is an on-prem managed service, prerequisites are more involved than typical public-cloud labs.

Account/tenancy requirements

An Oracle Cloud tenancy with the ability to manage Cloud@Customer resources.
The Exadata Cloud@Customer environment must be procured, delivered, installed, and activated (Oracle-led process).

Permissions/IAM roles

You need OCI IAM permissions to: – Manage compartments and networking objects as required for your architecture. – Manage Exadata Cloud@Customer resources (Exadata infrastructure, VM clusters, DB homes, databases).

Expect to work with policies similar to: – manage cloud-exadata-infrastructures – manage cloud-vmclusters – manage cloud-databases

Exact policy verbs/resource-types differ by OCI service naming; verify the correct policy syntax in official OCI IAM docs for Exadata Database Service on Cloud@Customer.

Billing requirements

This is not a typical pay-as-you-go service for hobby labs. It usually involves:
A commercial agreement/subscription for the on-prem Exadata system and cloud service management.
You still must monitor any OCI consumption used for integrations (Object Storage, logging, cross-region connectivity, etc.).

CLI/SDK/tools needed

OCI Console access.
OCI CLI (optional but recommended) for repeatable operations:
Docs: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
SSH client (for jump host operations if your operating model allows).
SQL tools:
SQL*Plus / SQLcl
Oracle SQL Developer
Network tools (for validation):
nslookup, dig, tnsping (if available), nc

Region availability

Availability is tied to Cloud@Customer deployments, not general OCI public regions.
Confirm your tenancy is enabled for the Cloud@Customer site and the service is available.

Quotas/limits

Service limits can apply at tenancy/compartment level.
Capacity is constrained by the installed Exadata system (CPU, storage, database server count).
Verify limits in:
OCI “Limits, Quotas, and Usage” pages for your tenancy
Exadata Cloud@Customer service documentation

Prerequisite services and infrastructure

On-prem network segmentation and IP planning (client/admin/backup).
DNS configuration appropriate for Oracle Database connectivity.
A jump host/bastion (recommended) for administrative access.
Backup target and retention policy (local or remote, as designed).

9. Pricing / Cost

Pricing model (what to expect)

Exadata Database Service on Cloud@Customer pricing is typically contract/subscription-based and can also include usage-based dimensions depending on how your agreement is structured.

Because commercial terms can vary significantly (system configuration, term length, licensing model, support, region/country), do not rely on a single “list price”. Use Oracle’s official pricing resources and your Oracle sales/partner quote for accuracy.

Pricing dimensions (commonly involved)

Expect costs to be driven by combinations of: – Exadata infrastructure subscription (the on-prem system capacity and service) – Database compute allocation (e.g., OCPU/ECPU allocation to VM clusters/databases—terminology varies by SKU) – Database licensing model: – Bring Your Own License (BYOL) vs license-included options (availability depends on the offering—verify for Cloud@Customer) – Storage capacity allocated/consumed on the system – Optional integrations that may incur OCI charges: – Object Storage for backups – Network connectivity (FastConnect, VPN) – Logging/Monitoring data ingestion or retention (if applicable)

Free tier

Exadata Database Service on Cloud@Customer is not a free-tier service.

Cost drivers (direct and indirect)

Direct cost drivers – Purchased Exadata system configuration and subscription term. – Allocated database compute (how many cores you reserve/enable). – High availability/DR features and associated licensing (e.g., Data Guard—verify licensing requirements).

Indirect/hidden cost drivers – Data center costs: rack space, power, cooling. – Network circuits and security appliances. – Backup storage (on-prem appliances or cloud object storage). – Operational staffing: DBAs, platform ops, security monitoring. – Patch testing environments (capacity overhead).

Network/data transfer implications

On-prem client traffic typically stays local and does not incur cloud egress.
If you send backups/telemetry to OCI services, you may incur:
Data transfer costs depending on connectivity and Oracle pricing rules
FastConnect port charges (if used)
Object Storage request/storage charges

Always validate against current Oracle pricing rules: – Official pricing: https://www.oracle.com/cloud/price-list/ – OCI cost estimator: https://www.oracle.com/cloud/costestimator.html

How to optimize cost (practical guidance)

Right-size VM clusters: allocate CPU based on measured load, not peak guesses.
Consolidate where safe: use multitenant PDBs for consolidation with strong isolation controls.
Use tagging and compartments to enforce chargeback/showback.
Design backup retention intentionally; avoid excessive retention in expensive tiers.
Avoid over-provisioning DR environments; consider standby sizing strategies aligned with RPO/RTO.

Example low-cost starter estimate (how to think about it)

A “starter” environment is usually not low-cost because it requires an installed Exadata Cloud@Customer system. However, you can minimize incremental cost by: – Creating a small VM cluster allocation for a non-production database. – Using minimal database storage and short retention backups. – Reusing existing jump hosts and monitoring tools.

Exact cost depends on contract terms and installed capacity—verify with Oracle pricing and your quote.

Example production cost considerations

For production, plan for: – Redundant network paths and secure connectivity. – Backup infrastructure and offsite copies. – A DR strategy (second site or alternate platform). – Monitoring/alerting and 24×7 operations. – Regular patching windows and pre-production testing environments.

10. Step-by-Step Hands-On Tutorial

This lab is designed to be realistic and executable for teams that already have Exadata Database Service on Cloud@Customer installed and enabled in their Oracle Cloud tenancy. If you do not have an active Cloud@Customer environment, you can still use this as an operational runbook to understand the workflow.

Objective

Provision a small Oracle Database on Exadata Database Service on Cloud@Customer by: 1. Preparing IAM and compartments 2. Creating (or selecting) an Exadata VM Cluster 3. Creating a Database Home 4. Creating a database 5. Connecting to the database and running a verification query 6. Cleaning up resources

Lab Overview

You will perform these tasks primarily in the Oracle Cloud Console (and optionally OCI CLI): – Create a compartment for the lab – Create IAM policies for DB admins – Confirm networking prerequisites (client subnet, DNS) – Create an Exadata VM Cluster (or use an existing one) – Create a Database Home (DB Home) – Create an Oracle Database (CDB with a PDB) – Validate connectivity using SQL*Plus or SQLcl – Tear down database resources to avoid consuming capacity

Important: In many organizations, creating/deleting VM clusters and database homes is controlled. Follow your internal change process.

Step 1: Create a compartment for isolation

Action (Console) 1. Open the Oracle Cloud Console. 2. Go to Identity & Security → Compartments. 3. Click Create Compartment. 4. Name: cocc-exadata-lab 5. Description: Lab compartment for Exadata Database Service on Cloud@Customer 6. Click Create Compartment.

Expected outcome – A new compartment exists and can be targeted for all subsequent resources.

Verification – The compartment appears in the compartments list and you can select it from the compartment picker.

Step 2: Set up IAM access (least privilege)

You typically need a group for DB admins and a policy granting access in the lab compartment.

Action (Console) 1. Go to Identity & Security → Groups. 2. Create a group, e.g. ExaCAtC-DB-Admins. 3. Add your user to the group.

Go to Identity & Security → Policies.
Create a policy in the root compartment (or as per your org model).
Use policy statements similar to the following (policy grammar can differ—verify in official docs):

Allow group ExaCAtC-DB-Admins to manage cloud-exadata-infrastructures in compartment cocc-exadata-lab
Allow group ExaCAtC-DB-Admins to manage cloud-vmclusters in compartment cocc-exadata-lab
Allow group ExaCAtC-DB-Admins to manage cloud-databases in compartment cocc-exadata-lab
Allow group ExaCAtC-DB-Admins to use virtual-network-family in compartment cocc-exadata-lab
Allow group ExaCAtC-DB-Admins to read audit-events in tenancy

Expected outcome – Users in the group can create and manage required resources.

Verification – Log out/in or re-authenticate, then confirm you can access Exadata Database Service on Cloud@Customer pages and start creation flows.

Common issue – If you get “NotAuthorizedOrNotFound,” your policy resource types may be incorrect for this service. Verify the current IAM policy reference for Exadata Database Service on Cloud@Customer in official docs.

Step 3: Confirm networking prerequisites (client access + DNS)

Before provisioning databases, confirm you have: – A client subnet/VLAN for application connectivity – An admin network path (often via a jump host) – DNS resolution for database endpoints

Action (Checklist) – Identify: – Client subnet CIDR – Gateway/router path to application networks – DNS domain and resolver used by your apps

Verification (from a jump host or a client VM) Run:

# Replace with your DNS resolver and expected domain
nslookup example.internal

If you already have a VM cluster and know the database SCAN/hostname pattern, test name resolution once created.

Expected outcome – You can resolve internal names and route to the client network.

Common issue – Provisioning succeeds but applications can’t connect due to missing routes, firewall rules, or DNS entries. Plan DNS early.

Step 4: Locate the Exadata Infrastructure (installed system)

In Cloud@Customer, the physical Exadata system is typically represented as an Exadata Infrastructure resource.

Action (Console) 1. Navigate to the database services area: – In OCI Console menus, this is commonly under Oracle Database or Databases. 2. Find Exadata Database Service on Cloud@Customer. 3. Select the cocc-exadata-lab compartment (or the compartment where infrastructure is shared). 4. Locate the Exadata Infrastructure entry.

Expected outcome – You can see an Exadata infrastructure resource in an Available/Active lifecycle state.

Verification – Open the infrastructure details page and confirm: – Lifecycle state is healthy – You can view associated resources (VM clusters, networks)

Common issue – If you see no infrastructure, your tenancy may not be linked to the Cloud@Customer site, or you are in the wrong compartment. Work with your Oracle Cloud admin.

Step 5: Create an Exadata VM Cluster (or choose an existing one)

A VM cluster provides compute allocation for your databases.

Action (Console) 1. From Exadata Database Service on Cloud@Customer, select VM Clusters. 2. Click Create VM Cluster (if allowed). 3. Choose: – Compartment: cocc-exadata-lab – Exadata Infrastructure: select your system – CPU allocation: choose a small allocation appropriate for lab (within your quotas) – Networking: choose client network settings per your environment – SSH keys: provide for admin access (if required by your model) 4. Create the VM cluster.

Expected outcome – VM cluster provisions successfully and becomes Available.

Verification – VM cluster lifecycle state: Available – Note: – Client network address/hostnames – Any SCAN/VIP endpoints (if displayed)

Common errors and fixes – Insufficient capacity: reduce CPU allocation or request capacity changes. – Network validation failures: confirm VLAN/subnet/IP pool requirements and firewall rules. – IAM errors: re-check policies for VM cluster management.

Step 6: Create a Database Home (DB Home)

A DB Home defines the Oracle Database software home.

Action (Console) 1. Go to your VM Cluster details. 2. Select Database Homes → Create Database Home. 3. Choose: – Database version (choose what your organization supports) – Display name: lab-dbhome – Maintenance/patching options (as per policy) 4. Create DB Home.

Expected outcome – DB Home enters Provisioning, then becomes Available.

Verification – DB Home lifecycle state is Available and shows version/patch level.

Common issue – If the required DB version isn’t available, it may be restricted by your service release. Use supported versions only.

Step 7: Create an Oracle Database (CDB with a PDB)

Now create a database using the DB Home.

Action (Console) 1. From the DB Home, click Create Database. 2. Provide: – Database name: LABCDB1 – DB unique name (if required) – Admin password (store securely) – Storage settings (use defaults appropriate for lab unless your DBA standards require otherwise) – Workload type (OLTP / DSS) if prompted – Database backups: configure according to your environment (local or remote). If OCI Object Storage is offered, ensure connectivity and IAM prerequisites first—verify in official docs. 3. Create the database.

Expected outcome – Database lifecycle state becomes Available.

Verification – Database details page shows: – Database status: Available – Connection strings (hostnames, service names)

Step 8: Connect to the database from a client and run a test query

Use SQL*Plus or SQLcl from a jump host or approved client segment.

Action 1. Install SQLcl (optional) or use SQL*Plus if already installed. 2. Retrieve the connection string from the database details page.

Example (SQL*Plus Easy Connect, adjust to your environment):

sqlplus admin_user@//dbhost.example.internal:1521/LABPDB1

Run verification SQL:

SELECT name, open_mode FROM v$database;

SELECT banner_full FROM v$version;

-- Create a tiny test object
CREATE TABLE lab_ping (id NUMBER PRIMARY KEY, created_at TIMESTAMP DEFAULT SYSTIMESTAMP);
INSERT INTO lab_ping (id) VALUES (1);
COMMIT;

SELECT * FROM lab_ping;

Expected outcome – You can connect and query successfully. – The table insert/select works.

Common errors – ORA-12154 (TNS could not resolve connect identifier): DNS or service name mismatch. Re-check the exact connect string from OCI console. – ORA-12514 (listener does not currently know of service): wrong service name (CDB vs PDB service) or database not fully registered. – Network timeouts: firewall rules, routing, or wrong subnet.

Step 9: (Optional) Enable basic monitoring and alerting

Your organization may use OCI monitoring integrations, Enterprise Manager, or third-party tools. A minimal baseline is: – Track database availability – Track storage usage – Track CPU utilization – Track backup success/failure

Action – Confirm what telemetry is supported in your Cloud@Customer deployment. – If OCI Monitoring is available, configure alarms on critical metrics (verify metric names in official docs).

Expected outcome – Alerts trigger to your on-call channel when thresholds are breached.

Validation

Use this checklist to confirm success: – VM Cluster: Available – DB Home: Available – Database: Available – Client connectivity: successful SQL login – Query success: SELECT banner_full FROM v$version; returns expected Oracle Database version – A test table can be created/queried

Troubleshooting

Issue: “NotAuthorizedOrNotFound” in console – Fix: Validate IAM policies, compartment selection, and group membership. Confirm the policy resource-types for Exadata Database Service on Cloud@Customer in official IAM docs.

Issue: VM cluster provisioning fails on networking – Fix: Verify IP pools, VLAN/subnet settings, MTU requirements, routing, and firewall rules. Cloud@Customer environments are sensitive to network prerequisites.

Issue: Database creation fails – Fix: Check DB Home health, available storage, and naming constraints. Review error details in the job/activity view.

Issue: Can’t connect from application host – Fix: – Confirm DNS and route to the client network – Confirm listener port open (typically 1521 unless customized) – Confirm service name (PDB vs CDB) – Validate any SCAN/VIP requirements

Issue: Performance is unexpectedly poor – Fix: – Confirm CPU allocation and instance configuration – Review wait events and I/O patterns – Ensure the app is on the correct network path (avoid hairpin routing) – Engage Oracle support for Exadata-specific diagnostics if needed

Cleanup

Cleanup depends on your organization’s capacity management rules.

Recommended cleanup (safe) 1. Drop the test schema objects: sql DROP TABLE lab_ping PURGE; 2. If this database is only for lab: – Delete the Database from the console (ensure backups are not needed). 3. If the DB Home is only for lab: – Delete the DB Home. 4. If the VM Cluster is only for lab and allowed: – Delete the VM Cluster.

What not to delete – Do not delete the Exadata Infrastructure unless you are decommissioning the entire platform and have Oracle-led procedures.

11. Best Practices

Architecture best practices

Treat Exadata Database Service on Cloud@Customer as a shared platform:
Define standard VM cluster templates (CPU allocation ranges, network profiles).
Standardize database naming and service naming.
Design for failure domains:
Even on-prem, plan for hardware failures, network failures, and operational mistakes.
Use separation of environments:
Separate prod/dev/test using compartments and (ideally) network segmentation.

IAM/security best practices

Implement least privilege:
Separate groups: DB-Admins, Network-Admins, Security-Auditors, ReadOnly.
Use compartments to enforce boundaries:
prod, nonprod, shared-infra.
Require MFA for privileged users.
Prefer centralized identity federation (IdP) if supported by your org.

Cost best practices

Track CPU and storage allocations:
Avoid idle VM clusters consuming capacity.
Consolidate responsibly:
Use PDBs for consolidation but enforce resource controls and strong tenant isolation.
Right-size DR:
Align spend to RPO/RTO and business criticality.

Performance best practices

Use database-level diagnostics:
AWR/ASH, SQL monitoring, execution plans.
Validate application connection management:
Use pools; avoid excessive session churn.
Keep statistics and maintenance jobs aligned with workload windows.
Follow Exadata-specific best practices recommended by Oracle for smart scan/offload-eligible workloads (verify per database version and feature set).

Reliability best practices

Define and test backup restore procedures (not just backups).
Maintain patch cadence:
Use a staging environment to test patches.
Use HA features where required:
RAC within the system (if configured)
Data Guard to another site (if part of the design and licensing)
Regularly test failover procedures.

Operations best practices

Use runbooks for:
Provisioning
Patching
Backup validation
Capacity expansions
Incident response
Establish change management gates for:
DB parameter changes
Network changes
Patching windows

Governance/tagging/naming best practices

Tag everything:
CostCenter, Environment, App, Owner, DataClassification
Naming standard examples:
VM cluster: exa-vmc-prod-finance-01
DB home: dbhome-19c-ruYYYYMM
Database: FINCDB01, PDB: FINPDB01

12. Security Considerations

Identity and access model

OCI IAM controls access to manage Exadata Database Service on Cloud@Customer resources.
Database access remains controlled inside Oracle Database:
Use enterprise identity integration where appropriate (e.g., LDAP/AD integration) if supported by your policies and architecture—verify in docs.
Enforce separation of duties:
IAM admin ≠ platform operator ≠ DBA ≠ auditor

Encryption

In-transit: Use TLS where applicable for clients; ensure network encryption options are aligned with your database/client versions.
At-rest: Use Oracle Database TDE where required (common for compliance).
Key management:
Determine whether keys are managed locally (HSM/KMS) or integrated with OCI Vault (if supported)—verify official docs and your compliance requirements.

Network exposure

Keep database endpoints private:
Do not expose database listeners to untrusted networks.
Use jump hosts/bastions for admin access.
Restrict management networks and use firewall allowlists.

Secrets handling

Do not store admin passwords in scripts or tickets.
Use a secrets manager approved by your organization.
Rotate database admin passwords and service credentials regularly.

Audit/logging

Enable:
OCI Audit for API activity (where supported)
Database auditing for privileged actions (Unified Auditing where applicable)
OS-level logging on hosts (if accessible per your model)
Centralize logs to your SIEM.

Compliance considerations

This service is often chosen for compliance-heavy environments. Typical controls include: – Data residency assurance (data stays on-prem) – Evidence collection (audit logs, change tickets, patch reports) – Vulnerability management (patch cadence and configuration hardening) – Access reviews for privileged groups and database roles

Common security mistakes

Overly broad IAM policies (manage all-resources in tenancy)
Shared DBA accounts and poor credential hygiene
Flat networks with overly permissive east-west access
Backups stored without encryption or with weak access controls
Lack of tested restore procedures

Secure deployment recommendations

Start with an organization-wide landing zone model (compartments, tagging, IAM boundaries).
Use network segmentation and strict firewall rules.
Implement mandatory audit controls and retention requirements.
Use hardened jump hosts with session recording if required.

13. Limitations and Gotchas

Treat this section as a practical checklist. Always confirm exact limits and supported operations in official documentation for your service release.

Known limitations (common in practice)

Not instantly self-serve: Requires Oracle-led installation and activation of the Cloud@Customer Exadata system.
Capacity is finite: You are bounded by the physical system installed on-prem.
Feature availability varies: Some OCI integrations (logging/monitoring/backups) can differ by deployment model and service release.
Patch/maintenance windows: Patching engineered systems involves coordinated planning and may require downtime depending on configuration.

Quotas and service limits

Tenancy/compartment quotas can restrict VM cluster/database creation.
CPU and storage allocations are constrained by purchased capacity.
Validate in OCI limits/quota tools and service docs.

Regional constraints

Cloud@Customer is site-specific; “region” semantics can be different from OCI public regions.
Some cross-region features may not apply or may require additional architecture.

Pricing surprises

Connectivity and backup storage can add recurring costs.
DR designs can double platform costs if you require a second site.

Compatibility issues

Older applications may not support modern TLS or connection settings.
Some database options require licensing; ensure you understand what is included vs BYOL.

Operational gotchas

DNS misconfiguration can block connectivity and cluster endpoint resolution.
Firewall rules often block ephemeral ports needed for cluster operations (verify required ports).
Inconsistent tagging/compartment design makes governance and audits difficult.

Migration challenges

Moving from self-managed Oracle on legacy hardware to Exadata can surface:
Compatibility issues with OS-level dependencies
Required changes to backup tooling
Need for standardized patching strategy
Use Oracle-recommended migration methods (Data Pump, RMAN duplicate, GoldenGate, etc.) based on downtime requirements—verify best approach per workload.

Vendor-specific nuances

This is optimized for Oracle Database on Exadata. It is not intended as a general-purpose virtualization platform.
Operational responsibilities are shared between customer teams and Oracle-managed processes; define RACI clearly.

14. Comparison with Alternatives

How it compares within Oracle Cloud

Exadata Database Service (OCI public region): Similar service model but hosted in OCI regions (not on-prem).
Autonomous Database (Dedicated or Cloud@Customer variants): More automation, less control; may or may not meet customization needs.
Base Database Service / DB Systems: Generally simpler and lower cost, but not Exadata engineered performance.

How it compares with other clouds

AWS, Azure, and Google Cloud offer Oracle Database options (including partner solutions and managed offerings), but they are not Oracle Exadata on your premises under Oracle’s Cloud@Customer model.
If your requirement is specifically “Exadata on-prem with OCI operational model,” direct equivalents are limited.

How it compares with self-managed alternatives

Self-managed Exadata on-prem: Maximum control, but highest operational burden.
Oracle on commodity servers: Lower hardware cost, potentially higher performance tuning burden and less predictable IO characteristics for demanding workloads.
Open-source databases (PostgreSQL, MySQL): Great for many apps, but not a drop-in replacement for Oracle features and ecosystem.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Exadata Database Service on Cloud@Customer (Oracle Cloud)	Regulated on-prem Oracle workloads needing engineered performance	Data stays on-prem; OCI-style governance; Exadata performance; enterprise lifecycle workflows	Requires on-prem installation; capacity fixed; commercial complexity; not “instant lab”	When you need Exadata + on-prem + cloud operating model
Exadata Database Service (OCI public region)	Cloud-first teams needing Exadata without on-prem constraints	Fast provisioning in OCI; elastic operational model	Data resides in OCI region; may not meet residency/latency constraints	When regulations allow public cloud and latency is acceptable
Autonomous Database (OCI)	Teams wanting maximum automation and minimal DBA overhead	Automated patching/tuning; simplified operations	Less customization/control; workload constraints	When you can accept platform constraints for higher automation
Self-managed Exadata on-prem	Organizations wanting full stack control	Maximum control; established on-prem procedures	High operational burden; patching complexity; slower provisioning	When you must control everything and can staff for it
Oracle Database on commodity servers (self-managed)	Smaller workloads or cost-constrained environments	Lower infra cost; flexible	More tuning burden; may not meet peak performance needs	When Exadata isn’t justified and workloads are moderate
PostgreSQL/MySQL (managed or self-managed)	New apps or modernization where Oracle features aren’t required	Cost-effective; strong ecosystem	Migration complexity; feature differences	When you can re-architect and reduce Oracle dependency

15. Real-World Example

Enterprise example: National healthcare claims platform

Problem: Claims processing databases contain protected health information; policy mandates data remain in a certified on-prem facility. Performance and availability requirements are strict (24×7, predictable batch windows).
Proposed architecture
Exadata Database Service on Cloud@Customer runs core claims Oracle databases.
Separate VM clusters for prod and non-prod (or strict resource controls).
Central IAM policies with dedicated DBA group and audit read-only group.
Backups to an approved offsite target (either another on-prem facility or OCI Object Storage over private connectivity—verify support and compliance).
Monitoring integrated into the enterprise NOC/SOC.
Why this service was chosen
Keeps data on-prem for compliance.
Provides standardized lifecycle workflows and governance aligned to Oracle Cloud.
Consolidates multiple databases onto engineered infrastructure.
Expected outcomes
Faster provisioning of new environments.
More consistent patching and governance.
Improved performance predictability for peak and batch workloads.

Startup/small-team example: Fintech with strict customer contracts

Problem: A fintech serves institutional clients who contractually require data to remain on-prem within a controlled facility. The team is small and wants managed processes rather than building everything from scratch.
Proposed architecture
One VM cluster sized for the core OLTP database plus a smaller non-prod PDB.
Strict network segmentation; only app subnets can reach database listener.
Automated database provisioning scripts using OCI CLI (where supported).
Backups with short retention for dev/test and longer retention for prod per compliance.
Why this service was chosen
Meets contractual on-prem data requirements.
Reduces operational burden compared to fully self-managed Exadata.
Provides a credible enterprise platform for audits and customer due diligence.
Expected outcomes
Stronger compliance posture with auditable controls.
Reduced time to deliver customer-specific environments.
Stable performance under customer load spikes.

16. FAQ

1) Is Exadata Database Service on Cloud@Customer the same as Exadata in OCI public cloud?

No. Exadata Database Service on Cloud@Customer runs Exadata infrastructure in your data center under a Cloud@Customer model, while Exadata Database Service in OCI public cloud runs in an OCI region.

2) Where does my data reside?

Data resides on the Exadata system on-premises. Any integration that sends data to OCI services (e.g., backups to Object Storage) depends on your configuration and must be explicitly set up.

3) Do I need an Oracle Cloud tenancy?

Yes. You typically manage the service through OCI-style console/APIs and IAM in an Oracle Cloud tenancy.

4) Can I use OCI CLI and Terraform?

OCI CLI is commonly used. Terraform support may exist via OCI provider resources, but exact resource coverage can change—verify in official OCI Terraform provider documentation before relying on it for production.

5) Is it “fully managed” like Autonomous Database?

Not in the same way. It’s a managed service for infrastructure and lifecycle workflows, but you still have DBA responsibilities (schema design, SQL tuning, users/roles, app integration, etc.).

6) Does it support Oracle RAC?

Oracle RAC is commonly associated with Exadata deployments, but the exact configuration options depend on your service setup and purchase—verify in official docs.

7) What Oracle Database versions are supported?

Supported versions depend on the service release and Oracle policy. Use only versions offered in the DB Home creation workflow and confirm with official docs.

8) How do backups work?

Backup options depend on your environment. Some deployments support backups to local targets and/or OCI Object Storage (with proper connectivity). Verify supported backup destinations and configuration steps in official docs.

9) Can I integrate with OCI Object Storage for backups?

Often possible in hybrid designs, but it depends on Cloud@Customer connectivity, IAM, network routing, and supported features. Verify in official documentation and your network/security standards.

10) How is access controlled?

Two layers: – OCI IAM controls who can manage resources (create VM clusters, DB homes, databases). – Oracle Database controls who can connect and what they can do inside the database.

11) Can applications in OCI connect to the on-prem database?

Yes, with appropriate network connectivity (FastConnect/VPN), routing, and security controls. Latency and bandwidth must be engineered.

12) What monitoring should I implement?

At minimum: – Availability checks – CPU/storage usage – Backup success/failure – Database performance metrics (AWR/ASH) Use OCI monitoring integrations where supported and/or Enterprise Manager/third-party tools.

13) Is this suitable for dev/test?

It can be, but it may be expensive capacity-wise. Many teams run dev/test in OCI public cloud and keep production on Cloud@Customer; choose based on compliance and cost.

14) What are the main operational risks?

Common risks include misconfigured IAM, fragile DNS/networking, insufficient capacity planning, and untested backup/restore procedures.

15) How do I plan DR?

DR often uses Oracle Database Data Guard or other replication methods to a second site or cloud environment, but architecture and licensing vary. Use Oracle reference architectures and validate RPO/RTO.

16) Does Cloud@Customer mean “air-gapped”?

Not necessarily. Some environments are tightly controlled, but many require connectivity for management and integrations. Your security architecture determines connectivity.

17) Can I run non-Oracle databases on it?

The service is designed for Oracle Database on Exadata. It is not intended as a general-purpose platform for arbitrary workloads.

17. Top Online Resources to Learn Exadata Database Service on Cloud@Customer

Use official sources first, then reference architectures and labs.

Resource Type	Name	Why It Is Useful
Official documentation	Oracle Cloud Infrastructure Documentation (Databases) – https://docs.oracle.com/en-us/iaas/Content/home.htm	Entry point to navigate to database services and Cloud@Customer documentation sections
Official documentation	OCI IAM Documentation – https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	Correct policy syntax, compartments, groups, federation, and least-privilege design
Official CLI docs	OCI CLI Installation – https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm	Step-by-step CLI install and authentication methods
Official pricing	Oracle Cloud Price List – https://www.oracle.com/cloud/price-list/	Authoritative pricing reference for OCI services (note Cloud@Customer is often quote-based)
Cost estimator	Oracle Cloud Cost Estimator – https://www.oracle.com/cloud/costestimator.html	Helps estimate costs for OCI services used alongside Cloud@Customer (Object Storage, connectivity, etc.)
Architecture center	Oracle Architecture Center – https://docs.oracle.com/en/solutions/	Reference architectures for Oracle workloads and hybrid patterns
Security guidance	OCI Security – https://docs.oracle.com/en-us/iaas/Content/Security/home.htm	Security services overview and best practices applicable to governance and audit
Tutorials/labs	Oracle LiveLabs – https://apexapps.oracle.com/pls/apex/f?p=133:100:	Hands-on labs; search for Exadata/OCI database labs relevant to your environment
Networking	OCI Networking docs – https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm	Hybrid networking patterns, routing, security lists/NSGs (where applicable)
Video learning	Oracle YouTube channel – https://www.youtube.com/@Oracle	Webinars, product explainers, and technical sessions (search for Exadata Cloud@Customer topics)

Tip: When searching within docs and LiveLabs, include both terms: “Exadata Database Service on Cloud@Customer” and “Exadata Cloud@Customer” to find the most relevant material, then verify naming and applicability.

18. Training and Certification Providers

The following institutes are listed as training providers. Evaluate course outlines, instructor experience, and recency before enrolling.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	Cloud/DevOps engineers, SREs, platform teams	DevOps foundations, cloud operations, automation; may include OCI-oriented tracks (check site)	check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM, CI/CD, DevOps practices; may complement cloud database ops skills	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	CloudOps practices, monitoring, reliability, operational readiness	check website	https://cloudopsnow.in/
SreSchool.com	SREs, operations engineers	Reliability engineering, SLOs, incident response, production operations	check website	https://sreschool.com/
AiOpsSchool.com	Ops teams adopting AIOps	Observability, event correlation, AIOps concepts	check website	https://aiopsschool.com/

19. Top Trainers

These sites are provided as trainer-related resources. Verify course recency and relevance to Oracle Cloud and Exadata Database Service on Cloud@Customer before engaging.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps / cloud training content (verify offerings)	Beginners to intermediate engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training services (verify OCI coverage)	DevOps engineers, platform teams	https://devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training platform (verify scope)	Teams needing short-term enablement	https://devopsfreelancer.com/
devopssupport.in	DevOps support and training (verify specialization)	Ops/DevOps teams	https://devopssupport.in/

20. Top Consulting Companies

These organizations are listed as consulting resources. Confirm scope, SOW, and references directly with the provider.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps/IT consulting (verify portfolio)	Architecture, automation, operations process	Hybrid connectivity planning; operational runbooks; monitoring integration	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and training (per site)	DevOps transformation, automation, enablement	CI/CD integration for database provisioning workflows; IaC governance	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify scope)	DevOps/SRE practices implementation	Observability pipelines; incident management processes; automation	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To be effective with Exadata Database Service on Cloud@Customer, build fundamentals in: 1. Oracle Database basics – Users/roles, tablespaces, RMAN concepts, performance basics 2. Oracle networking – Listener/service names, DNS, routing/firewalls, connection pooling 3. OCI fundamentals – Tenancy, compartments, IAM policies, tagging 4. Security fundamentals – Least privilege, secrets management, audit logging 5. Operations fundamentals – Change management, patching strategy, backup testing, incident response

What to learn after this service

Once comfortable, expand into: – Oracle Data Guard and DR design patterns (verify licensing and support model) – Enterprise monitoring and automation: – OCI Monitoring/Logging (if supported) – Oracle Enterprise Manager – Infrastructure as Code workflows (Terraform where supported) – Performance engineering: – AWR/ASH mastery, SQL tuning, indexing strategies – Hybrid architectures: – FastConnect/VPN, private DNS, zero-trust segmentation

Job roles that use it

Oracle DBA / Senior DBA
Cloud database engineer (OCI)
Platform engineer (database platforms)
Site Reliability Engineer (database reliability)
Security engineer (governance, audit, segmentation)
Solutions architect (regulated hybrid designs)

Certification path (if available)

Oracle offers OCI and database certifications, but certification availability and relevance evolve. Use Oracle University as the authoritative source: – https://education.oracle.com/

For Exadata Database Service on Cloud@Customer specifically, look for: – OCI architect foundations (IAM, networking) – Oracle Database administration certifications – Exadata administration training (where available)

Project ideas for practice

Build a compartment/IAM model for prod/non-prod with least privilege.
Create a “database provisioning runbook” including:
VM cluster allocation request
DB home selection
Database creation checklist
Post-provisioning security hardening
Implement backup validation automation:
Scheduled restore tests to a non-prod environment (where feasible)
Build a connectivity validation toolkit:
DNS checks, port checks, login checks, simple performance baseline

22. Glossary

Cloud@Customer: Oracle’s model for delivering OCI-like services in a customer’s data center. Exact implementation details vary by offering—verify for your deployment.
Compartment (OCI): A logical container for organizing and isolating cloud resources for governance and access control.
IAM (Identity and Access Management): OCI service for users, groups, policies, and authentication/authorization.
Exadata Infrastructure: The on-prem Exadata engineered system resource representation used by the service.
VM Cluster: A logical cluster of VMs on Exadata database servers used to host Oracle Database workloads.
DB Home (Database Home): Oracle Database software installation used to create databases.
CDB/PDB: Container Database and Pluggable Database model used in Oracle Multitenant architecture.
RAC (Real Application Clusters): Oracle clustering technology for database high availability and scale (availability depends on configuration).
RMAN: Recovery Manager, Oracle’s backup and recovery tool.
TDE (Transparent Data Encryption): Oracle Database feature for encrypting data at rest.
FastConnect: Oracle’s private network connectivity service between customer and OCI (used in hybrid designs where applicable).
RPO/RTO: Recovery Point Objective / Recovery Time Objective for disaster recovery planning.
AWR/ASH: Oracle performance diagnostic reports (Automatic Workload Repository / Active Session History).

23. Summary

Exadata Database Service on Cloud@Customer is an Oracle Cloud Data Management service that brings Exadata and Oracle Database to your data center with an OCI-style control plane for provisioning, governance, and lifecycle operations. It matters when you must keep data on-prem for compliance or latency, but still want cloud operating consistency.

Cost is typically driven by your Cloud@Customer subscription terms, allocated compute/storage capacity, and any hybrid integrations (backups, connectivity, telemetry). Security is a shared responsibility: use OCI IAM least privilege, strong network segmentation, database-native controls (TDE, auditing), and tested backup/restore procedures.

Use Exadata Database Service on Cloud@Customer when you need Exadata on-prem with standardized cloud management, and choose alternatives (OCI public Exadata, Autonomous Database, or self-managed options) when your constraints or operational goals differ.

Next step: read the official OCI documentation, confirm your environment’s supported workflows and limits, then implement a compartment + IAM baseline and run the provisioning lab in a controlled non-production compartment.

rajeshkumar

Category