Oracle Cloud Base Database Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Data Management

1. Introduction

What this service is
Base Database is Oracle Cloud Infrastructure (OCI) managed infrastructure for running Oracle Database on dedicated virtual machine (VM) or bare metal database systems, where Oracle manages the underlying OCI infrastructure lifecycle and you manage the database configuration and (to varying degrees) patching and operations.

Simple explanation (one paragraph)
If you want the control and compatibility of a traditional Oracle Database deployment (OS-level access on the DB host, familiar tooling, full database feature set depending on edition), but you also want cloud provisioning, cloud networking, cloud monitoring, and cloud-integrated backups, Base Database is OCI’s core “run Oracle Database on dedicated compute” service.

Technical explanation (one paragraph)
Base Database (often referenced in official docs as Oracle Base Database Service) provisions DB systems (VM or bare metal) inside your OCI VCN and subnet, creates Database Homes (Oracle software images), and then creates Databases (CDB/PDB depending on version/config). It integrates with OCI Identity and Access Management (IAM), KMS/Vault for encryption keys, Object Storage for backups, OCI networking controls (security lists/NSGs), and OCI Monitoring/Logging. You can scale compute and storage within service constraints and optionally implement higher availability and disaster recovery using Oracle database technologies (for example, Data Guard), depending on version/edition and your design.

What problem it solves
Base Database solves the gap between self-managed Oracle Database on IaaS and fully autonomous databases: it provides fast provisioning, cloud-native integration, and predictable operational boundaries while preserving administrative control, compatibility, and customization that many enterprise Oracle workloads require.

Naming note (important): In OCI, you may see this offering referred to as “Oracle Base Database Service” and the main resource type as “DB System.” Older Oracle “Database Cloud Service” terminology from Oracle Cloud “Classic” is a different generation and should not be confused with OCI Base Database. Verify the latest naming in the official docs: https://docs.oracle.com/en-us/iaas/base-database/home.htm

2. What is Base Database?

Official purpose
Base Database is the OCI service for deploying Oracle Database on dedicated VM or bare metal DB systems with OCI-managed infrastructure constructs and cloud integrations, while allowing customers to manage database configuration and day-to-day DBA activities.

Core capabilities (high level)

Provision Oracle Database on VM DB systems or Bare Metal DB systems
Create and manage Database Homes (Oracle software installations) and Databases
Configure network placement in your VCN/subnets and control access with NSGs/security lists
Use automatic backups (stored in OCI Object Storage) and on-demand backups (service-dependent)
Apply patching workflows for database and (in some cases) grid/host components depending on DB system type and your chosen approach
Integrate with OCI security and governance: IAM policies, compartments, tagging, Vault/KMS (for encryption keys), Audit, Monitoring

Major components (what you actually create/manage in OCI)

DB System: The database host(s) on VM or bare metal. This is the main infrastructure resource.
Database Home: The Oracle Database software image installed on the DB system (e.g., a specific Oracle Database version/patch level).
Database: The database instance/configuration created within a Database Home.
Networking: VCN, subnet, NSG/security lists, route tables, DNS settings, optional private endpoints and bastion patterns.
Backups: Automatic backups and related retention (stored in Object Storage; details depend on configuration and region/service capabilities—verify in official docs).

Service type
A managed database infrastructure service (sometimes described as “DBaaS on dedicated compute”)—not serverless and not multi-tenant autonomous. You typically have OS access (SSH) to the DB host for VM/bare metal DB systems and you manage many DBA tasks.

Scope (regional/global/project/account)
Base Database is regional in OCI and deployed into specific Availability Domains (ADs) (where applicable) within a region. Resources are organized by tenancy → compartment → region. Networking is within a region (VCN is regional), and DR designs may use cross-region replication/standby patterns.

How it fits into the Oracle Cloud ecosystem

Oracle Cloud Networking (VCN) provides isolation, routing, and access controls.
OCI Object Storage is commonly used for backups.
OCI Vault (KMS) can be used for key management (e.g., TDE key management patterns).
OCI Bastion provides secure administrative access patterns without public IPs.
OCI Monitoring, Logging, Events, Notifications support operational observability and automation.
Oracle Autonomous Database is a separate service for managed/autonomous operation; Base Database is chosen when you need more control.

3. Why use Base Database?

Business reasons

Licensing flexibility: Depending on your needs, you can choose Bring Your Own License (BYOL) or License Included models (availability depends on region/edition—verify in pricing and docs).
Compatibility and control: Many commercial applications require specific Oracle versions/options or DBA-level control that autonomous offerings may not fit.
Faster time to provision than building everything manually on compute instances, while still keeping a “traditional Oracle DB” operational model.

Technical reasons

Dedicated compute (VM or bare metal) for predictable performance and isolation.
OCI-native networking (private subnets, NSGs, service gateways) that aligns with enterprise landing zones.
Database Home lifecycle management (versioning and patching workflows) instead of manually managing Oracle installs on raw VMs.
Integration with Oracle database HA/DR technologies (capabilities depend on edition/version and design; verify current support in docs).

Operational reasons

Repeatable provisioning (console, API, CLI, Terraform) aligned with infrastructure-as-code.
Backups integrated with OCI (Object Storage) with policy-driven retention.
Compartment-based governance and tagging for chargeback/showback.
Monitoring via OCI services and Oracle database tooling.

Security/compliance reasons

Private networking by default (recommended): run DBs without public IPs and control access through bastion + NSGs.
Encryption: Oracle Database Transparent Data Encryption (TDE) patterns, plus OCI encryption at rest for storage, and TLS for in-transit connections (implementation depends on your configuration).
Auditability: OCI Audit for API calls and database auditing at the DB level.

Scalability/performance reasons

Scale within service constraints by selecting appropriate shapes and storage sizing.
Bare metal options for high I/O and predictable latency.
Performance tuning remains under DBA control (SGA/PGA, indexing, partitioning, etc.).

When teams should choose Base Database

Choose Base Database when you need:

Oracle Database with OS/DBA-level control
Specific Oracle versions or configurations
Private network deployment with controlled connectivity
A path to HA/DR using Oracle technologies while staying on OCI-managed infrastructure constructs
Infrastructure-as-code provisioning and standardized environments (dev/test/prod)

When teams should not choose Base Database

Avoid Base Database when:

You want minimal DBA overhead and fully managed tuning/patching (consider Autonomous Database).
You don’t require Oracle Database specifically (consider OCI MySQL HeatWave, PostgreSQL offerings, or open-source on compute).
You need serverless auto-scaling semantics or extremely simple operational model.
Your team cannot support DBA responsibilities (patch planning, backups validation, parameter tuning, upgrades).

4. Where is Base Database used?

Industries

Financial services (core banking integrations, risk systems)
Telecommunications (billing, subscriber systems)
Healthcare and life sciences (claims, EMR integrations)
Retail and e-commerce (orders, inventory, CRM backends)
Manufacturing and logistics (ERP, supply chain)
Public sector (records systems, compliance-heavy workloads)

Team types

Platform engineering teams running shared database platforms
DBA teams modernizing Oracle estates to cloud
DevOps/SRE teams operating app + database stacks with IaC
Security and compliance teams enforcing network isolation and audit controls

Workloads

Commercial packaged applications that require Oracle Database
OLTP systems with strict integrity and concurrency requirements
Mixed OLTP + reporting (with careful workload management)
Multi-schema enterprise systems with complex PL/SQL logic
Integration hubs and operational data stores

Architectures

2-tier and 3-tier enterprise applications (app servers → database)
Hub-and-spoke networks with shared services and centralized security
Multi-environment landing zones (dev/test/stage/prod separated by compartments and VCNs)
Hybrid connectivity (on-prem ↔ OCI via FastConnect/VPN) for phased migrations

Real-world deployment contexts

Lift-and-shift from on-prem Oracle to OCI with minimal changes
Re-platforming with improved network security (private subnets, bastion)
Consolidation of multiple smaller databases into fewer standardized DB systems (within resource limits)

Production vs dev/test usage

Dev/test: Smaller shapes, shorter backup retention, scheduled downtime acceptable
Production: Private endpoints, strict NSG rules, automated backups, monitoring/alerting, HA/DR design, controlled patch windows, defined RPO/RTO

5. Top Use Cases and Scenarios

Below are realistic Base Database scenarios. Each includes the problem, why Base Database fits, and a short example.

Lift-and-shift an on-prem Oracle OLTP database – Problem: You need to migrate quickly with minimal code changes and maintain DBA control. – Why Base Database fits: Traditional Oracle deployment model with cloud provisioning and OCI networking. – Example: Move a 4 TB OLTP database from on-prem to OCI VM DB system; keep same schema/PLSQL; integrate with on-prem via FastConnect.
Run a packaged enterprise application that mandates Oracle Database – Problem: Vendor requires Oracle Database version/config and rejects autonomous models. – Why this fits: You control OS/database configuration and patch cadence. – Example: ERP backend requires specific database patch level and initialization parameters; you standardize DB Homes across environments.
Private database in a regulated network zone – Problem: Compliance mandates no public DB endpoints and strict east-west controls. – Why this fits: Deploy DB system in private subnet, restrict with NSGs, administer via OCI Bastion. – Example: Claims processing database only reachable from app subnet; DB admin uses bastion port forwarding with MFA.
Standardize dev/test database provisioning – Problem: Teams wait days for DB environments; manual installs create drift. – Why this fits: Repeatable DB system + Database Home creation, consistent baseline images. – Example: Terraform module provisions a VM DB system and creates a database per team with tags for cost allocation.
Centralized shared database platform for multiple apps – Problem: Many apps need Oracle; each running a separate VM is expensive and inconsistent. – Why this fits: Consolidate multiple schemas/databases on a standardized DB system (within resource constraints). – Example: Platform team runs a DB system per environment; apps connect via private endpoints and distinct users/roles.
High-performance transactional system needing dedicated I/O – Problem: Latency-sensitive transactions require predictable performance. – Why this fits: Bare metal DB system options and dedicated resources. – Example: Trading order system uses bare metal with tuned storage and network paths.
Implement DR with standby databases (Data Guard pattern) – Problem: Business requires recovery in another AD/region. – Why this fits: Oracle HA/DR tooling can be used with OCI network design. – Example: Primary in Region A, standby in Region B; planned switchover for patching and DR drills. (Verify support matrix in docs.)
Database modernization with OCI Observability – Problem: On-prem monitoring is fragmented; you want unified alerts. – Why this fits: Integrate with OCI Monitoring/Alarms and optionally Database Management service. – Example: Alarms on CPU, storage, and DB performance KPIs; notifications to on-call.
Secure analytics staging database – Problem: You need a staging area for sensitive data before loading to analytics. – Why this fits: Private networking and encryption patterns; controlled access. – Example: Data ingestion lands in Object Storage; ETL runs on private compute; writes to Base Database staging schema.
Application migration where OS-level scripts are required – Problem: App depends on OS-level jobs, custom agents, or filesystem integrations. – Why this fits: VM/bare metal DB system supports more traditional ops patterns than fully managed services. – Example: Legacy batch jobs run on DB host with OS scheduling, generating files consumed by downstream systems. (Use caution; prefer app-tier jobs when possible.)

6. Core Features

Feature availability can depend on region, database version, edition, and whether you use VM DB systems or bare metal. Always verify specifics in the official documentation: https://docs.oracle.com/en-us/iaas/base-database/home.htm

6.1 DB Systems (VM and Bare Metal)

What it does: Provisions dedicated database servers in OCI.
Why it matters: Isolation and predictable performance.
Practical benefit: Aligns with traditional DBA operations and performance tuning.
Caveats: You are responsible for many operational tasks (patch planning, configuration, access control).

6.2 Database Homes

What it does: Manages Oracle Database software images installed on the DB system.
Why it matters: Separates software lifecycle from database lifecycle.
Practical benefit: Easier patching/upgrade workflows with reduced drift.
Caveats: Home management still requires planning; patching can require downtime depending on strategy.

6.3 Database Creation and Management

What it does: Creates database instances/configurations within a Database Home.
Why it matters: Standardized provisioning and metadata tracked in OCI.
Practical benefit: Consistent creation across environments; clear resource ownership in compartments.
Caveats: Advanced configurations (e.g., certain HA modes) may require additional steps and expertise.

6.4 Networking in Your VCN/Subnet

What it does: Places DB systems in your private network and applies OCI network controls.
Why it matters: Enterprise security boundaries and routing control.
Practical benefit: You can enforce “no public DB” designs and limit access to app tiers.
Caveats: Misconfigured NSGs/routes are a top cause of connectivity and backup failures.

6.5 Automatic Backups to OCI Object Storage

What it does: Enables scheduled backups stored in OCI Object Storage (service-managed integration).
Why it matters: Foundational for recovery and compliance.
Practical benefit: Durable storage, lifecycle policies, and cross-region strategies (where implemented).
Caveats: Backup retention and capabilities vary—verify current backup features and costs in docs/pricing.

6.6 Encryption and Key Management (TDE + OCI Vault patterns)

What it does: Supports encryption at rest using Oracle Database TDE; OCI Vault can be used for key management patterns.
Why it matters: Meets security/compliance requirements for sensitive data.
Practical benefit: Reduced risk from storage compromise; centralized key governance.
Caveats: Key rotation and wallet/key management require careful runbooks; verify exact integration steps in docs.

6.7 IAM Integration (Compartments, Policies, Tagging)

What it does: Controls who can create/manage DB systems, homes, and databases.
Why it matters: Prevents unauthorized provisioning and changes.
Practical benefit: Separation of duties (network team vs DBA team vs app team).
Caveats: Over-broad policies are common; use least privilege and compartment boundaries.

6.8 Observability (Monitoring, Alarms, Logging, Audit)

What it does: OCI Monitoring provides metrics; Logging/Audit capture events and API calls.
Why it matters: You need proactive detection (storage full, CPU saturation, failed backups).
Practical benefit: Standardize alerting into on-call workflows.
Caveats: Database-level logs/metrics may require additional configuration and services (e.g., Database Management). Verify what is included by default.

6.9 Patching and Maintenance Workflows

What it does: Supports patching of Database Homes and potentially infrastructure components depending on system type.
Why it matters: Security and stability.
Practical benefit: Oracle-provided patch images reduce manual patch friction.
Caveats: Patching can cause downtime; plan maintenance windows and test in lower environments.

6.10 High Availability / Disaster Recovery Patterns (Technology-dependent)

What it does: Enables you to implement HA/DR using Oracle database technologies (for example, Data Guard) where supported.
Why it matters: Business continuity.
Practical benefit: Better RPO/RTO than backup-only strategies.
Caveats: Configuration complexity and cost; confirm support matrix for your DB version/edition and OCI region strategy.

7. Architecture and How It Works

High-level service architecture

Base Database uses OCI resource constructs:

You choose a compartment and region.
You deploy (or select) a VCN and subnet.
You create a DB system (VM/bare metal) in that subnet.
On that DB system you create a Database Home (Oracle binaries).
Within the home you create a Database (your instance / CDB/PDB arrangement).
You connect from your application tier (Compute, OKE, on-prem) over private IP.
Backups (if enabled) are stored in OCI Object Storage, typically reached via a Service Gateway for private subnets.

Request/data/control flow

Control plane (OCI API/Console/CLI/Terraform):
Creates and updates DB system resources, applies IAM policies, tracks lifecycle states.
Data plane (SQL/Net traffic):
Application traffic flows from client/app tier to DB private IP (TCP 1521 by default for Oracle listener; your port may differ).
Backup traffic:
DB host communicates to Object Storage endpoints. For private subnet designs, traffic should go through an OCI Service Gateway (recommended) or NAT/Internet Gateway (less preferred).

Integrations with related OCI services (common ones)

Networking: VCN, Subnets, NSGs, Security Lists, Route Tables, Service Gateway, NAT Gateway, DRG (for FastConnect/VPN).
Identity and governance: IAM, Compartments, Tagging, OCI Audit.
Security: OCI Vault (KMS), Security Zones (if used), Bastion.
Operations: OCI Monitoring, Alarms, Notifications, Events, Logging.
Storage: Object Storage (backup), Block Volume (underlying DB system storage).

Dependency services

At minimum you need:

A working VCN/subnet with appropriate routing and security rules
A compartment with permissions
Quota available for database resources in that region
Network path to Object Storage endpoints if backups are enabled (service gateway recommended)

Security/authentication model

OCI IAM controls management operations (create DB system, update DB home, etc.).
Database authentication is separate (database users/passwords, optionally enterprise identity integrations depending on your setup).
OS access (SSH) is controlled by:
Whether the DB system has public IP (not recommended for production)
Subnet routing + NSGs/security lists
SSH keys and bastion patterns

Networking model

DB system is deployed into a subnet and receives private IP addresses.
Recommended: private subnet without public IPs.
Access patterns:
Application tier in same VCN or peered VCN
On-prem via DRG + FastConnect/VPN
Admin access via OCI Bastion (port forwarding for SQL*Net, SSH sessions)

Monitoring/logging/governance considerations

Enable and standardize:
OCI Monitoring alarms for CPU, storage, memory (where available), and backup failure indicators
Audit reviews for DB system lifecycle changes
Tagging for environment, owner, cost center, and data classification
For deeper database performance insights, evaluate OCI Database Management (service availability and licensing considerations may apply—verify in official docs).

Simple architecture diagram (learning/lab)

flowchart LR
  Dev[Developer Laptop] -->|SSH to Bastion| Bastion[OCI Bastion]
  Bastion -->|Port forward 1521| DB[Base Database\nVM DB System\nPrivate Subnet]
  App[Compute Instance\n(SQL client)] -->|SQL*Net 1521| DB
  DB -->|Backups| OS[OCI Object Storage]
  DB -.->|Metrics/Events| Mon[OCI Monitoring/Alarms]

Production-style architecture diagram (reference)

flowchart TB
  subgraph RegionA[OCI Region A]
    subgraph VCN[VCN - Hub and Spoke]
      subgraph AppSubnet[Private App Subnet]
        LB[Load Balancer (optional)]
        App1[App Server 1]
        App2[App Server 2]
      end

      subgraph DBSubnet[Private DB Subnet]
        DBP[Base Database\nPrimary DB System]
      end

      subgraph SecOps[Security/Operations]
        Bastion[OCI Bastion]
        Vault[OCI Vault / KMS]
        Mon[OCI Monitoring + Alarms]
        Audit[OCI Audit]
      end

      SGW[Service Gateway]
      DRG[DRG to On-Prem / Other Regions]
      OS[Object Storage\n(Backups)]
    end
  end

  subgraph RegionB[OCI Region B (DR)]
    subgraph VCNB[VCN/DR Network]
      DBS[Base Database\nStandby DB System]
      OSB[Object Storage\n(Backups/Replication)]
    end
  end

  LB --> App1
  LB --> App2
  App1 -->|SQL*Net| DBP
  App2 -->|SQL*Net| DBP

  Bastion -->|Admin access| DBP
  Vault -->|Key governance| DBP
  DBP -->|Backups via SGW| OS
  DBP -.-> Mon
  DBP -.-> Audit

  DBP -->|DR link (e.g., Data Guard)\nVerify support/config| DBS
  DBS --> OSB
  DRG --> VCNB

8. Prerequisites

Tenancy and account requirements

An active Oracle Cloud (OCI) tenancy
Access to a target region where Base Database is available
(Service availability varies by region—verify in OCI docs and the console service list.)

Permissions / IAM roles

You need IAM permissions to:

Create/manage DB systems, database homes, and databases
Create/use networking resources (VCN/subnets/NSGs) or at least select existing ones
Use Object Storage for backups (depending on how permissions are modeled)

OCI policies vary by organization. As a starting point for a lab, many teams use a compartment-scoped policy like:

Allow group <YourGroup> to manage database-family in compartment <YourCompartment>
Allow group <YourGroup> to use virtual-network-family in compartment <YourCompartment>
Allow group <YourGroup> to manage object-family in compartment <YourCompartment>
Allow group <YourGroup> to read vaults in compartment <YourCompartment>
Allow group <YourGroup> to use keys in compartment <YourCompartment>

Adjust to least privilege for production. For official IAM patterns, verify in OCI IAM documentation.

Billing requirements

A paid tenancy or credits sufficient to create DB systems.
Base Database is not generally “free” because it uses dedicated compute/storage.
OCI Free Tier eligibility for database services varies—verify current Free Tier offerings: https://www.oracle.com/cloud/free/

CLI/SDK/tools needed (for this tutorial)

OCI Console access (primary)
Optional: OCI Cloud Shell (recommended)
Includes OCI CLI preinstalled in many regions (verify in console).
A SQL client on a compute instance (recommended for private DB lab):
SQLcl, SQL*Plus, or another Oracle-compatible client
SSH client for bastion/compute access

Region availability

Base Database is available in many OCI commercial regions, but not necessarily all sovereign/government regions or new regions on day one.
Always verify in:
Console region selector
Official Base Database docs: https://docs.oracle.com/en-us/iaas/base-database/home.htm

Quotas/limits

Common blockers include:

DB system count limits per compartment/region
OCPU limits for database shapes
Block volume limits

Check OCI Service Limits in the console and request limit increases if needed.

Prerequisite services

For a secure private deployment and backups:

VCN with at least:
One private DB subnet
One private app/admin subnet (optional but recommended)
Service Gateway to Object Storage (recommended if DB subnet is private)
Route tables and security rules
OCI Object Storage (for backups, if enabled)
OCI Bastion (recommended for admin access without public IPs)

9. Pricing / Cost

Do not treat this section as a quote. Prices vary by region, shape, licensing model, and sometimes contract terms. Always validate with the official pricing pages and the OCI cost estimator.

Official pricing references

OCI pricing entry points: https://www.oracle.com/cloud/price-list/
(Navigate to Database and look for Oracle Base Database Service / DB Systems pricing lines.)
OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Pricing dimensions (how you’re billed)

Base Database cost typically includes:

Compute (OCPU) for the DB system – Billed based on selected shape and number of OCPUs. – VM vs bare metal differs.
Database software licensing model – License Included: Oracle license cost bundled into hourly OCPU price (where offered). – BYOL: You bring your Oracle Database licenses; cloud price reflects infrastructure/service costs. – Availability and rules differ—verify with Oracle pricing and your license agreement.
Storage – DB system uses storage (commonly Block Volumes) sized during provisioning. – Additional storage for datafiles, redo, and recovery area impacts cost.
Backup storage – Automatic backups stored in OCI Object Storage (charged by GB-month and requests). – Retention period directly impacts cost.
Networking – Data transfer costs may apply for cross-region transfer, internet egress, and some interconnect patterns. – Intra-region traffic within VCN is typically not billed like internet egress, but always verify OCI data transfer pricing rules.

Cost drivers (what makes bills grow)

Choosing larger OCPU counts and high-performance shapes
License Included vs BYOL differences
Over-provisioning storage “just in case”
Long backup retention or multiple full backups without lifecycle policies
DR architectures (standby systems double compute/storage footprint)
Additional admin compute instances, bastion sessions, monitoring services, and log retention

Hidden or indirect costs to plan for

High availability / DR: A standby DB system nearly duplicates cost.
Operational tooling: If you add advanced monitoring/management services, costs may apply (verify service pricing).
Data egress: Exporting backups or moving large datasets out of region can be expensive.
Patching windows: Not a direct cost, but an operational cost (downtime planning, testing).

Network/data transfer implications

Backups written to Object Storage from a private subnet typically require:
Service Gateway (best practice) to avoid public internet paths
Correct route tables and security rules
Cross-region DR replication (if used) incurs inter-region data transfer (verify pricing).

How to optimize cost

Right-size OCPUs and storage; scale after measuring utilization.
Prefer private networking and service gateways for predictable routing and security.
Set backup retention aligned to compliance (not “forever”).
Use tagging + budgets to detect runaway environments.
Use separate compartments for dev/test and enforce smaller shapes via policy and quota management.

Example low-cost starter estimate (model, not numbers)

A typical low-cost lab pattern includes:

1 small VM DB system (minimum viable OCPUs and storage)
Automatic backups enabled with short retention
1 small compute instance as SQL client (or use existing app host)
Private subnet with service gateway (no NAT traffic for backups)

To estimate: 1. Pick your region 2. Select Base Database VM DB system shape and OCPU count 3. Choose BYOL vs License Included 4. Add block storage size 5. Add expected backup storage footprint 6. Add compute instance for client/bastion (if any)

Use the OCI cost estimator: https://www.oracle.com/cloud/costestimator.html

Example production cost considerations

For production, plan line items for:

Primary DB system OCPUs + storage
Standby DB system (if DR) OCPUs + storage
Backup retention and archival strategy
Monitoring/logging retention
Network connectivity (FastConnect/VPN/DRG)
Operational headroom (CPU/storage growth, additional environments)

10. Step-by-Step Hands-On Tutorial

This lab builds a private Base Database VM DB system, connects to it securely from a compute instance in the same VCN, creates a schema and sample table, verifies connectivity, and then cleans up.

Objective

Provision an Oracle Cloud Base Database (VM DB system) in a private subnet with automatic backups enabled, then securely connect and run SQL to validate the database.

Lab Overview

You will:

Create networking (VCN, private subnets, service gateway) or reuse an existing VCN.
Create a small Compute instance as a “SQL client host” in a private subnet.
Create a Base Database VM DB system in a private DB subnet.
Connect from the compute instance to the database using SQL*Plus/SQLcl.
Create a user and sample table; validate.
Troubleshoot common issues (NSG rules, routes, wallet/listener).
Clean up resources to stop charges.

Low-cost and safety note: Base Database is not typically free. If you are cost-sensitive, stop after validation and delete the DB system and compute instance.

Step 1: Create (or select) a compartment and set tags

In the OCI Console, open Identity & Security → Compartments.
Create a compartment such as: lab-base-db.
(Recommended) Define tags you will apply to all lab resources: – Environment=Lab – Owner=<your-name-or-team> – CostCenter=Training

Expected outcome: You have a dedicated compartment to isolate access and simplify cleanup.

Step 2: Create a VCN with private subnets and a Service Gateway

If you already have a VCN, verify it meets the requirements (private subnets, routing, security rules). Otherwise:

Go to Networking → Virtual Cloud Networks.
Click Create VCN.
Choose VCN with Internet Connectivity only if you want public subnets. For a safer lab, prefer VCN with custom CIDR and build private-only routing.
Create: – VCN CIDR: e.g., 10.0.0.0/16 – Private subnet (App/Admin): 10.0.10.0/24 – Private subnet (DB): 10.0.20.0/24
Create a Service Gateway: – Networking → Service Gateways → Create Service Gateway – Select your VCN – Add service: All Object Storage Services in Oracle Services Network
Update the Route Table for the private subnets to include: – Destination: Oracle Services Network (service CIDR label in OCI) – Target: Service Gateway

Expected outcome: Private subnets can reach OCI Object Storage without using the public internet, supporting backups.

Verification: – Confirm the Service Gateway exists and route table rules are attached to the private subnets.

Step 3: Create Network Security Groups (NSGs) for app and database

Using NSGs helps keep rules targeted.

Go to Networking → Network Security Groups.
Create NSG: nsg-app-admin
Create NSG: nsg-db

Add rules:

Ingress rules for nsg-db: – Allow TCP 1521 (Oracle listener) from nsg-app-admin
(In OCI, you can reference NSG as source, not just CIDR.) – Allow TCP 22 (SSH) only from nsg-app-admin (optional; you may not need SSH to DB host in this lab)

Ingress rules for nsg-app-admin: – Allow TCP 22 from your IP (only if the app/admin subnet has a public IP path)
If you keep everything private-only, use OCI Bastion instead of public SSH.

Expected outcome: Only the app/admin host can talk to the database listener.

Verification: NSG rules show correct sources/destinations and ports.

Step 4: Create a small Compute instance as your SQL client host

This instance sits in the app/admin private subnet and is used to connect to the database privately.

Go to Compute → Instances → Create instance.
Name: sql-client
Image: Oracle Linux (or another supported Linux)
Shape: choose a small shape to reduce cost.
Networking: – VCN: your lab VCN – Subnet: private-app-admin – Assign public IP: No (recommended) – NSG: attach nsg-app-admin
SSH keys: upload your public key.

Expected outcome: Compute instance is running in the private subnet.

Verification: – Instance is RUNNING – It has a private IP in 10.0.10.0/24

How you will SSH to it (two common options): – Option A (recommended for private-only): use OCI Bastion to SSH into sql-client. – Option B: temporarily give the instance a public IP and restrict SSH source to your IP (less ideal).

Step 5: Create a Base Database VM DB system in the private DB subnet

Go to Oracle Database → DB Systems (naming can vary slightly by console).
Click Create DB system.
Select Base Database and choose Virtual Machine DB system.
Basic details: – Compartment: lab-base-db – DB system name: lab-basedb-vm
Configure shape and storage: – Choose a modest OCPU count and storage size for lab. – Choose database version and edition as required. (Select what is available in your region.)
Networking: – VCN: your lab VCN – Subnet: private-db – NSG: attach nsg-db – Public IP: No (recommended)
Credentials: – Set the database admin password (store securely)
Backups: – Enable Automatic backups (recommended) – Choose a short retention for lab to limit cost (if configurable)
Create.

Provisioning can take time.

Expected outcome: DB system becomes AVAILABLE (or equivalent “ready” state), and you see database details (DB name, unique name, SCAN/listener details vary).

Verification: – DB system lifecycle state is healthy/available – Note the private IP and port (commonly 1521) – Confirm the database name/service name shown in the console

Step 6: Connect to the SQL client host (via OCI Bastion) and install a SQL tool

If using OCI Bastion:

Go to Identity & Security → Bastion (or search “Bastion”).
Create a bastion in the same VCN.
Create a Managed SSH session to the sql-client private IP.
Use the provided SSH command from OCI console.

Once connected to sql-client, install SQLcl (example on Oracle Linux; verify current package steps in official sources):

sudo dnf -y install unzip

If SQLcl is not available via package manager, you can use SQL*Plus via Oracle Instant Client. Installation steps vary; follow Oracle’s official instructions for your OS and client choice.

Expected outcome: You have a SQL client available on sql-client.

Verification:

which sql
# or
which sqlplus

Step 7: Allow connectivity and resolve service name details

From the DB system details in OCI Console, collect:

DB host private IP (or SCAN address if applicable)
Listener port (commonly 1521)
Service name / DB name shown by OCI

If you cannot find the exact connect descriptor, use the OCI console’s connection panel (often shows a connect string) or verify in official docs for your DB version.

On the sql-client host, test TCP connectivity first:

nc -zv <DB_PRIVATE_IP> 1521

Expected outcome: Connection succeeds (succeeded).

If it fails: – Check NSG rules (Step 3) – Confirm route tables and subnet selection – Confirm DB system is in AVAILABLE state – Confirm listener port matches

Step 8: Connect to the database and run validation SQL

Use SQL*Plus/SQLcl. Example with SQLcl:

sql sys/<ADMIN_PASSWORD>@//<DB_PRIVATE_IP>:1521/<SERVICE_NAME> as sysdba

Then run:

SELECT name, open_mode FROM v$database;
SELECT sys_context('USERENV','DB_NAME') AS db_name FROM dual;

Expected outcome: You can query the database and see it open (typically READ WRITE for a primary).

Now create a lab user and a sample table:

CREATE USER lab_user IDENTIFIED BY "Str0ng_Password_ChangeMe!";
GRANT CREATE SESSION, CREATE TABLE TO lab_user;

CONNECT lab_user/"Str0ng_Password_ChangeMe!"@//<DB_PRIVATE_IP>:1521/<SERVICE_NAME>

CREATE TABLE hello_basedb (
  id NUMBER GENERATED BY DEFAULT AS IDENTITY,
  message VARCHAR2(200),
  created_at TIMESTAMP DEFAULT SYSTIMESTAMP
);

INSERT INTO hello_basedb(message) VALUES ('Hello from OCI Base Database');
COMMIT;

SELECT * FROM hello_basedb;

Expected outcome: You see one row returned with your message.

Step 9: Verify backups are enabled (control plane verification)

In the OCI Console:

Open the database details page.
Locate Backups section.
Confirm automatic backups are enabled and next backup window is defined (if shown).

Expected outcome: Backup configuration is visible and enabled.

Note: Backup objects in Object Storage may not be directly human-readable and may not appear as plain files in your bucket listing depending on how the service manages backup storage. Always verify using the database service backup views and OCI console.

Validation

Use this checklist:

[ ] DB system state is AVAILABLE
[ ] sql-client can reach DB private IP on port 1521
[ ] SQL login works using the service name shown in OCI
[ ] lab_user created successfully
[ ] Sample table created and query returns expected row
[ ] Automatic backups enabled (per OCI console)

Troubleshooting

Problem: DB provisioning fails or stuck – Check service limits for DB systems and OCPUs in your region. – Verify the selected shape is available in your AD/region. – Review OCI Work Requests / error messages in the console.

Problem: nc to port 1521 fails – Confirm DB system NSG (nsg-db) has ingress rule from nsg-app-admin on TCP 1521. – Confirm sql-client is actually attached to nsg-app-admin. – Ensure subnets are in the same VCN and routing is not blocking. – Confirm you used the correct DB private IP (not a display name).

Problem: SQL connection errors (ORA-12514 / service unknown) – Wrong <SERVICE_NAME> is the most common cause. – Use the connect descriptor shown in the OCI console database connection panel. – Verify listener/service configuration on the DB host (requires DBA skill and may require SSH access to DB host—use caution).

Problem: Backups failing in private subnet – Ensure a Service Gateway exists and the DB subnet route table includes a route to Object Storage via Service Gateway. – Confirm there is no restrictive egress rule blocking Oracle Services Network. – Verify backup configuration in console and check related events/logs.

Problem: You cannot SSH anywhere (private-only) – Use OCI Bastion. – Ensure bastion is in the same VCN and allowed to reach the target subnet. – Confirm your SSH key is correct.

Cleanup

To stop charges, delete resources in this order:

Delete the database (from the DB system’s database list) if required by console workflow.
Delete the DB system lab-basedb-vm.
Terminate the compute instance sql-client.
Delete NSGs nsg-app-admin and nsg-db.
Delete bastion (if created).
Delete VCN (only if created for lab and no longer needed).
Deleting the VCN will delete subnets, route tables, gateways (confirm dependencies first).

Always confirm backups and related storage are also removed if they remain billable.

11. Best Practices

Architecture best practices

Use private subnets for databases; avoid public IPs for DB systems.
Separate subnets:
App tier subnet(s)
DB subnet
Admin subnet (optional)
Use hub-and-spoke network architecture with centralized security controls for enterprise environments.

IAM/security best practices

Use compartments to separate environments (dev/test/prod).
Apply least privilege IAM policies:
DB admins manage database-family
Network team manages virtual-network-family
Security team manages vaults/keys
Use tagging standards for owner/environment/classification.

Cost best practices

Choose BYOL vs License Included intentionally (involve licensing experts).
Set backup retention to match RPO/compliance.
Use budgets and cost alerts for compartments.
Turn off/terminate dev/test DB systems when not needed (where feasible).

Performance best practices

Right-size OCPUs and storage IOPS profile (shape/storage options vary).
Place app servers close to DB (same region, low-latency subnets).
Use database tuning best practices (indexes, stats, partitioning) and avoid over-reliance on scaling.
Benchmark with realistic workload before committing to shapes.

Reliability best practices

Plan for failure:
Backup/restore procedures tested regularly
HA/DR using Oracle technologies where required (verify support)
Regularly test:
Backup restore to a new DB system (functional validation)
DR drills (if implemented)

Operations best practices

Maintain runbooks:
Patching schedule
Backup verification and restore testing
Incident response
Monitor:
Storage space (data + FRA)
CPU and memory pressure
Long-running sessions and locks
Centralize logs and alerts; integrate with incident management.

Governance/tagging/naming best practices

Naming convention example:
basedb-<env>-<app>-<region>-<seq>
Tags:
Environment, Application, Owner, DataClassification, CostCenter
Use OCI policies to enforce tagging where possible (verify current OCI governance features in your tenancy).

12. Security Considerations

Identity and access model

OCI IAM controls who can create/modify Base Database resources.
Database users/roles control data access inside Oracle Database.
Separate duties:
Cloud admins manage OCI resources
DBAs manage Oracle users, roles, schemas, and security inside the DB

Encryption

At rest: OCI storage encryption + Oracle Database TDE (common pattern for sensitive data).
In transit: Use TLS where required; client configuration depends on your chosen approach and Oracle Net configuration.

Encryption implementations vary by database version/configuration. Verify exact steps in Oracle Database and OCI Base Database documentation.

Network exposure

Prefer no public IP on DB systems.
Use NSGs with narrow rules:
Allow 1521 only from known app subnets/NSGs
Avoid 0.0.0.0/0 inbound rules
Use OCI Bastion for admin access and port forwarding.

Secrets handling

Do not store SYS/SYSTEM passwords in plaintext.
Use OCI Vault (secrets) or your enterprise secret manager for:
DB admin credentials
Application DB credentials
Rotate credentials periodically and after staff changes.

Audit/logging

Use OCI Audit to track API calls affecting DB systems.
Enable database auditing features appropriate to your compliance requirements (inside Oracle Database).
Retain logs according to policy; ensure access to logs is restricted.

Compliance considerations

Align with:
Data residency (choose region appropriately)
Encryption requirements (TDE, key custody)
Access control (least privilege)
Change management (patching windows, approvals)
For regulated workloads, consider OCI security services and governance controls available in your tenancy (verify current OCI features).

Common security mistakes

Public DB endpoints
Overly permissive NSG/security list rules
No service gateway/NAT planning, causing admins to “temporarily” open the DB to the internet
Unrotated credentials and shared SYS password usage
Not testing restore procedures (security includes recoverability)

Secure deployment recommendations

Private DB subnet + service gateway + bastion access
Dedicated compartments for prod and non-prod
KMS/Vault-based key governance where required
Automated alerts for security group changes and DB system lifecycle changes

13. Limitations and Gotchas

Treat these as common considerations; verify exact limits and supported configurations in official docs for your region and database version.

Not serverless: You provision fixed OCPUs/storage; scaling may involve downtime or operational work.
DBA responsibility remains: You manage schema design, tuning, parameter changes, and many operational workflows.
Regional/AD constraints: Some shapes or capabilities may not be available in every AD/region.
Connectivity pitfalls: Most issues come from NSGs, route tables, and incorrect connect descriptors.
Backup networking dependencies: Private subnet backups generally require correct Service Gateway routing to Object Storage.
Patching requires planning: Even with managed images, patching may require downtime and testing.
License complexity: BYOL rules and “License Included” eligibility require careful review; involve licensing specialists.
Cost surprises from retention/DR: Backups and standby systems can double (or more) total cost footprint.
Operational drift: If admins make manual OS-level or DB-level changes without IaC/runbooks, environments diverge quickly.
Migration nuance: Moving to Base Database from on-prem may require network redesign (CIDRs, DNS), identity updates, and careful performance validation.

14. Comparison with Alternatives

In Oracle Cloud (nearest alternatives)

Oracle Autonomous Database: More managed, less DBA overhead; different control model.
Exadata Database Service: Higher performance and Exadata features; typically higher cost and different scaling model.
OCI MySQL HeatWave: MySQL managed service (not Oracle Database).
Self-managed Oracle on Compute: Maximum control, but you manage everything (installation, patching, backups, automation).

In other clouds (nearest equivalents)

AWS: Amazon RDS for Oracle (managed), or Oracle on EC2 (self-managed)
Azure: Oracle on Azure VMs (self-managed); Oracle Database@Azure is a distinct offering (verify current scope and availability)
Google Cloud: Oracle on Compute Engine (self-managed)
On-prem: Oracle Database on VMware/bare metal

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Base Database	Oracle DB needing control + cloud integration	Dedicated VM/bare metal, VCN-native, DB Home lifecycle, integrated backups	More DBA ops than autonomous; fixed sizing; cost can grow with HA/DR	You need Oracle compatibility and admin control on OCI
OCI Autonomous Database	Teams wanting minimal DBA ops	Automated tuning/patching, simplified ops, elastic features (service-dependent)	Less OS-level control; not all customizations	You can accept autonomous constraints and want lower ops burden
OCI Exadata Database Service	High-performance, large-scale Oracle workloads	Exadata performance/features	Higher cost/complexity	You need Exadata capabilities and top-tier performance
Oracle on OCI Compute (self-managed)	Maximum control	Full OS and install control	You manage everything; more risk and toil	You need custom setups not supported by Base Database
AWS RDS for Oracle	Managed Oracle on AWS	Managed service model, AWS ecosystem	Feature/option constraints; license considerations	You are standardized on AWS and accept RDS constraints
Oracle on any-cloud VMs	Portability of self-managed model	Familiar VM-based operations	Highest operational burden	You must run Oracle in a specific cloud without a suitable managed offering
Open-source DB (PostgreSQL/MySQL)	New apps not requiring Oracle	Lower license costs, broad ecosystems	Migration effort; feature differences	You can redesign and do not require Oracle Database

15. Real-World Example

Enterprise example (regulated workload)

Problem
A financial services company has a customer account system on Oracle Database with strict audit requirements. They need to move from on-prem to Oracle Cloud while keeping the same Oracle features and maintaining a private network posture. They also require DR in a second region.

Proposed architecture

Base Database VM or bare metal DB system in a private DB subnet
App servers in private app subnet behind internal load balancer
OCI Bastion for admin access
Service Gateway to Object Storage for backups
DR via standby DB system in a second region (e.g., Data Guard pattern—verify support and configuration)
OCI Vault for key governance and secrets storage
OCI Monitoring/Alarms + centralized logging

Why Base Database was chosen

Maintains DBA-level control and compatibility for existing Oracle features and operational processes
Integrates with OCI private networking and governance
Supports enterprise migration strategy with controlled patching and strong isolation boundaries

Expected outcomes

Reduced data center dependency and improved provisioning speed
Improved security posture (no public DB, audited changes)
Defined RPO/RTO with tested backup restore and DR drills

Startup/small-team example (packaged app requirement)

Problem
A startup runs a B2B application that requires Oracle Database because of a vendor-provided module. They have a small team, but they need reliable backups and a secure database network.

Proposed architecture

One Base Database VM DB system in private subnet
One small compute instance for the application in private subnet
OCI Bastion for admin access; no public DB endpoint
Automatic backups enabled with short retention
Simple alarms for CPU/storage thresholds

Why Base Database was chosen

Vendor compatibility without building a full self-managed stack from scratch
Faster provisioning and clearer operational model than DIY Oracle installs
Security controls achievable without a large security team

Expected outcomes

Stable production database with manageable operations
Predictable monthly cost with right-sized resources
Easier path to future scaling or DR if business grows

16. FAQ

Is “Base Database” the same as “Oracle Base Database Service”?
In OCI documentation, “Oracle Base Database Service” is the full name often used. In the console you may see “DB Systems” as the main construct. Treat “Base Database” as the OCI service for VM/bare metal DB systems. Verify naming in official docs: https://docs.oracle.com/en-us/iaas/base-database/home.htm
Is Base Database serverless?
No. You provision a DB system with a fixed shape (OCPUs) and storage. Scaling is possible within constraints, but it is not serverless.
Do I get OS access to the database host?
Typically, VM and bare metal DB systems allow SSH access with the right network path and keys. Exact access patterns depend on configuration and policy.
Can I deploy Base Database in a private subnet with no public IP?
Yes, and that is the recommended approach for production. Use OCI Bastion and strict NSG rules.
How do backups work?
Base Database supports automatic backups stored in OCI Object Storage. Configuration and retention options depend on the service and region. Always validate backup/restore procedures.
Do I need a Service Gateway for backups?
If your DB system is in a private subnet and you want private access to Object Storage, a Service Gateway is the standard design.
What is a DB System vs a Database Home vs a Database?
DB System is the host infrastructure, Database Home is the Oracle software installation, and Database is the actual database instance/configuration created inside the home.
What Oracle Database editions are supported?
Editions and versions vary by offering and region. Check the DB system creation wizard and pricing pages for current options.
Can I use BYOL?
BYOL is commonly offered, but rules depend on your Oracle agreement and OCI offering. Confirm with Oracle licensing guidance and official pricing pages.
How is Base Database different from Autonomous Database?
Autonomous Database reduces DBA tasks with more automation; Base Database provides more control and a more traditional DBA operating model.
How do I connect securely from my laptop if the DB is private?
Use OCI Bastion for SSH and port forwarding, or connect via a private network path (VPN/FastConnect) and use private DNS.
What ports must be open?
Oracle listener commonly uses TCP 1521, but confirm your configuration. SSH is TCP 22 if you need OS access. Keep rules narrow and source-restricted.
How do I monitor performance?
Use OCI Monitoring for infrastructure-level metrics and Oracle database tooling for DB-level metrics. OCI Database Management may provide additional capabilities (verify availability/pricing).
Can I do cross-region DR?
DR is commonly implemented using Oracle database technologies (e.g., standby databases). Support and setup steps vary—verify in official docs and plan networking carefully.
What are the most common causes of failed connections?
Incorrect service name/connect descriptor, missing NSG ingress rules, wrong subnet routing, or trying to connect from outside the VCN without bastion/VPN/FastConnect.

17. Top Online Resources to Learn Base Database

Resource Type	Name	Why It Is Useful
Official documentation	OCI Base Database documentation: https://docs.oracle.com/en-us/iaas/base-database/home.htm	Primary, current reference for features, workflows, and limitations
Official docs (OCI Database landing)	Oracle Database on OCI docs entry points: https://docs.oracle.com/en-us/iaas/Content/Database/home.htm	Broader context across DB offerings in OCI
Official pricing	Oracle Cloud Price List: https://www.oracle.com/cloud/price-list/	Source of current SKUs and pricing dimensions (region-dependent)
Official cost estimator	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html	Build scenario-based estimates without guessing
Free tier overview	Oracle Cloud Free Tier: https://www.oracle.com/cloud/free/	Confirms what is free and what is not (changes over time)
Official architecture guidance	OCI Architecture Center: https://docs.oracle.com/en/solutions/	Reference architectures (networking, DR, security) you can adapt
Official networking docs	OCI Networking documentation: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm	Required for secure private DB designs (VCN, gateways, NSGs)
Official IAM docs	OCI IAM documentation: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	How to build least privilege policies and compartment models
Official Bastion docs	OCI Bastion: https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm	Secure admin access patterns for private DB systems
Official Object Storage docs	OCI Object Storage: https://docs.oracle.com/en-us/iaas/Content/Object/home.htm	Backup storage fundamentals, lifecycle policies, access controls
Official Terraform provider	OCI Terraform Provider docs: https://registry.terraform.io/providers/oracle/oci/latest/docs	Infrastructure-as-code for repeatable DB provisioning (verify supported resources)
Official OCI CLI docs	OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm	Script provisioning and operations where appropriate
Official YouTube	Oracle Cloud Infrastructure channel: https://www.youtube.com/@OracleCloudInfrastructure	Service walkthroughs and architecture talks (verify Base Database-specific content)

18. Training and Certification Providers

DevOpsSchool.com – Suitable audience: DevOps engineers, SREs, cloud engineers, platform teams – Likely learning focus: Cloud operations, DevOps practices, automation, CI/CD (verify OCI-specific offerings on site) – Mode: Check website – Website: https://www.devopsschool.com/
ScmGalaxy.com – Suitable audience: DevOps and SCM learners, build/release engineers – Likely learning focus: Source control, CI/CD pipelines, DevOps foundations (verify OCI modules on site) – Mode: Check website – Website: https://www.scmgalaxy.com/
CLoudOpsNow.in – Suitable audience: Cloud operations and production support teams – Likely learning focus: Cloud ops practices, monitoring, incident response (verify OCI coverage on site) – Mode: Check website – Website: https://www.cloudopsnow.in/
SreSchool.com – Suitable audience: SREs, reliability engineers, operations leads – Likely learning focus: SRE principles, reliability, observability, incident management (verify database reliability topics on site) – Mode: Check website – Website: https://www.sreschool.com/
AiOpsSchool.com – Suitable audience: Ops teams exploring AIOps, monitoring automation users – Likely learning focus: AIOps concepts, event correlation, automated remediation (verify OCI integrations on site) – Mode: Check website – Website: https://www.aiopsschool.com/

19. Top Trainers

RajeshKumar.xyz – Likely specialization: Cloud/DevOps training content (verify OCI and database-specific coverage) – Suitable audience: Engineers seeking practical coaching and workshops – Website: https://rajeshkumar.xyz/
devopstrainer.in – Likely specialization: DevOps tooling and practices (verify OCI modules if needed) – Suitable audience: DevOps engineers and teams – Website: https://www.devopstrainer.in/
devopsfreelancer.com – Likely specialization: Freelance DevOps services and training resources (verify scope) – Suitable audience: Small teams needing hands-on guidance – Website: https://www.devopsfreelancer.com/
devopssupport.in – Likely specialization: DevOps support and enablement (verify OCI/database focus) – Suitable audience: Teams needing operational support patterns – Website: https://www.devopssupport.in/

20. Top Consulting Companies

cotocus.com – Likely service area: Cloud and DevOps consulting (verify OCI and Oracle database experience on site) – Where they may help: Cloud migration planning, landing zones, DevOps pipelines, operational readiness – Consulting use case examples: Designing private network architecture for Base Database; setting up monitoring and backup validation runbooks – Website: https://cotocus.com/
DevOpsSchool.com – Likely service area: DevOps consulting and corporate training (verify offerings) – Where they may help: CI/CD, infrastructure automation, operational practices for cloud platforms – Consulting use case examples: Terraform-based provisioning for Base Database environments; building patching and deployment workflows – Website: https://www.devopsschool.com/
DEVOPSCONSULTING.IN – Likely service area: DevOps and cloud consulting (verify OCI/database scope) – Where they may help: Cloud operations, automation, monitoring, and reliability improvements – Consulting use case examples: Standardizing IAM and tagging for database compartments; building alerting and incident response integration for database operations – Website: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Base Database

OCI fundamentals:
Tenancy, compartments, IAM policies
VCN, subnets, route tables, NSGs, gateways
Linux basics:
SSH, packages, basic troubleshooting
Oracle Database fundamentals:
Users/roles, tablespaces, undo/redo basics
Backup concepts (RMAN basics are helpful even if OCI manages parts)
Basic performance concepts (indexes, execution plans)

What to learn after Base Database

Oracle HA/DR patterns (as applicable):
Standby databases/DR runbooks (verify specific support for Base Database)
Infrastructure as Code:
Terraform modules for DB systems, networking, and tagging
Observability:
OCI Monitoring/Alarms + centralized log management
Database performance monitoring tooling (OCI Database Management where applicable)
Security hardening:
Vault/KMS key governance patterns
Secure bastion access patterns and just-in-time access

Job roles that use it

Cloud Solutions Architect (OCI + database workloads)
DBA / Cloud DBA
DevOps Engineer (database platform automation)
SRE / Production Engineer (monitoring, incident response, reliability)
Security Engineer (network isolation, encryption, audit)

Certification path (if available)

Oracle certifications change over time. For OCI, check Oracle University and official Oracle certification listings and choose tracks related to:

OCI Foundations
OCI Architect
OCI operations specialties
Oracle Database administration (as needed for Base Database operations)

Verify current certification names and requirements in official Oracle certification portals.

Project ideas for practice

Build a private Base Database environment with bastion-only access and strict NSGs.
Implement automated provisioning with Terraform and enforce tags/policies.
Create a backup/restore drill: restore to a new DB system and validate application connectivity.
Build monitoring: alarms for storage thresholds and CPU, notifications to email/Slack (via integration).
Implement least-privilege IAM for DB admins vs app operators.

22. Glossary

AD (Availability Domain): A physically isolated data center within an OCI region (in regions that use ADs).
Base Database: OCI service for Oracle Database on VM/bare metal DB systems with OCI integration.
Bastion: Managed service to provide secure access to private resources without public IPs.
Block Volume: OCI persistent block storage used by compute and DB systems.
BYOL: Bring Your Own License; you supply Oracle Database licenses under your agreement.
CDB/PDB: Container Database / Pluggable Database architecture used in modern Oracle Database versions.
Compartment: OCI logical container for resources and access control boundaries.
DB System: The Base Database compute resource (VM/bare metal) hosting Oracle Database.
Database Home: Oracle Database software installation (version/patch level) on a DB system.
DRG: Dynamic Routing Gateway for connecting VCNs to on-prem or other networks (VPN/FastConnect).
IAM Policy: Text rules defining who can do what in OCI.
KMS/Vault: OCI services for key management and secret storage.
NSG (Network Security Group): Virtual firewall rules applied to VNICs/resources.
OCPU: Oracle CPU unit used for OCI compute billing.
Object Storage: OCI durable object store used commonly for backups.
Oracle Services Network: OCI service endpoints reachable via Service Gateway.
RPO/RTO: Recovery Point Objective / Recovery Time Objective.
Service Gateway: Enables private subnet access to Oracle Services Network (e.g., Object Storage) without internet.
SQL*Net: Oracle database network protocol used by clients to connect to the listener.
TDE: Transparent Data Encryption, Oracle Database feature for encrypting data at rest.
VCN: Virtual Cloud Network, OCI’s virtual network construct.

23. Summary

Base Database in Oracle Cloud (OCI) is the core Data Management service for running Oracle Database on dedicated VM or bare metal DB systems with cloud-native provisioning, networking, and backup integration—while preserving the administrative control many Oracle workloads require.

It matters because it provides a practical middle ground between self-managed Oracle on raw compute and fully managed autonomous services: you gain OCI governance, private networking, and integrated backups without giving up DBA control.

From a cost perspective, the biggest drivers are OCPUs, storage, licensing model (BYOL vs License Included), backups retention, and DR footprint. From a security perspective, the strongest baseline is private subnets, bastion-only access, strict NSGs, encryption (TDE + key governance), and audit/monitoring.

Use Base Database when you need Oracle compatibility and control on OCI; choose alternatives like Autonomous Database when you want less DBA responsibility, or Exadata Database Service for specialized Exadata performance needs.

Next step: Re-run the hands-on lab using Terraform for repeatability, then add monitoring alarms and a backup/restore drill to make your deployment operationally production-ready.

rajeshkumar

Category

1. Introduction

2. What is Base Database?

3. Why use Base Database?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose Base Database

When teams should not choose Base Database

4. Where is Base Database used?

Industries

Team types

Workloads

Architectures

Real-world deployment contexts

Production vs dev/test usage

5. Top Use Cases and Scenarios

6. Core Features

6.1 DB Systems (VM and Bare Metal)

6.2 Database Homes

6.3 Database Creation and Management

6.4 Networking in Your VCN/Subnet

6.5 Automatic Backups to OCI Object Storage

6.6 Encryption and Key Management (TDE + OCI Vault patterns)

6.7 IAM Integration (Compartments, Policies, Tagging)

6.8 Observability (Monitoring, Alarms, Logging, Audit)

6.9 Patching and Maintenance Workflows

6.10 High Availability / Disaster Recovery Patterns (Technology-dependent)

7. Architecture and How It Works

High-level service architecture

Request/data/control flow

Integrations with related OCI services (common ones)

Dependency services

Security/authentication model

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram (learning/lab)

Production-style architecture diagram (reference)

8. Prerequisites

Tenancy and account requirements

Permissions / IAM roles

Billing requirements

CLI/SDK/tools needed (for this tutorial)

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Official pricing references

Pricing dimensions (how you’re billed)

Cost drivers (what makes bills grow)

Hidden or indirect costs to plan for

Network/data transfer implications

How to optimize cost

Example low-cost starter estimate (model, not numbers)

Example production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Create (or select) a compartment and set tags

Step 2: Create a VCN with private subnets and a Service Gateway

Step 3: Create Network Security Groups (NSGs) for app and database

Step 4: Create a small Compute instance as your SQL client host

Step 5: Create a Base Database VM DB system in the private DB subnet

Step 6: Connect to the SQL client host (via OCI Bastion) and install a SQL tool

Step 7: Allow connectivity and resolve service name details

Step 8: Connect to the database and run validation SQL

Step 9: Verify backups are enabled (control plane verification)

Validation

Troubleshooting

Cleanup

11. Best Practices

Architecture best practices

IAM/security best practices

Cost best practices

Performance best practices

Reliability best practices

Operations best practices

Governance/tagging/naming best practices