OCI Base Database Service, in depth: DB systems, storage, backups, Data Guard and what you still operate

What a DB system is

The unit you provision is a DB system: one virtual machine, or two for Real Application Clusters (RAC), plus remote block volumes for storage, placed in a subnet of your virtual cloud network. Inside it are one or more database homes, each an Oracle Database software installation at a particular version and release update, and inside each home one or more container databases with their pluggable databases. OCI's control plane knows about all of these objects, so the Console, API, CLI and Terraform can create, back up, patch and delete them.

Three choices at creation time are hard to change later. The edition is Standard Edition, Enterprise Edition, Enterprise Edition High Performance, Enterprise Edition Extreme Performance or Enterprise Edition Developer; the higher Enterprise tiers include more database options in the licence, and two-node RAC requires Extreme Performance. The storage management is either Logical Volume Manager (LVM), which provisions faster and suits single-node systems, or Automatic Storage Management (ASM) with Grid Infrastructure, which RAC needs and which gives you Oracle's own volume management. The network placement (VCN, subnet and availability domain) decides who can reach the database and where a standby can live.

Current documentation lists Oracle Database 19c, 21c and 26ai as supported versions. 19c is the long-term support release most production estates run. It also lists VM.BaseDB.x86 as the recommended x86 shape family, replacing VM.Standard.x86, whose documented retirement date was July 31, 2026, and Ampere A1 shapes for the Developer edition. Check the shape list in your region rather than copying a shape name from an old runbook.

Compute and storage sizing

Compute is sold by CPU unit. The Terraform provider describes ECPU as the recommended compute model and OCPU as legacy; an OCPU is a physical core, which on x86 means two hardware threads. You can scale the CPU count of a running VM DB system, which triggers a restart, so size for the steady state and treat scaling as a planned change rather than an autoscaler.

Storage is remote block volumes, divided into DATA for datafiles and RECO for redo, archive logs and the fast recovery area. Oracle's service FAQ puts the ceiling at about 100 TB per VM DB system, split into up to 80 TB for data and 20 TB for recovery. Each volume has a performance mode, BALANCED or HIGH_PERFORMANCE. Block volume performance scales with size, so a small, busy database can be I/O-bound long before it runs out of space. Size for IOPS and throughput as well as capacity, and measure with your real redo rate, since commit latency depends on redo write latency more than on anything else.

Networking is ordinary OCI networking, described in OCI networking. Put the DB system in a private subnet, open port 1521 (or your listener port) only from the application's network security group, and add a service gateway so backups to Object Storage and Recovery Service never cross the internet. SSH access for operators should go through a bastion.

Defining a DB system as code

Provisioning through the Console is fine for a first look, but production systems should be declared. Attribute names below are from the Oracle provider's oci_database_db_system resource documentation; values such as the shape and version string must come from your region's lists:

resource "oci_database_db_system" "orders" {
  availability_domain = var.ad
  compartment_id      = var.db_compartment_ocid
  subnet_id           = oci_core_subnet.db_private.id
  hostname            = "ordersdb"
  display_name        = "orders-prod"

  shape             = var.db_shape          # from the shape list for your region, e.g. the current x86 BaseDB shape
  compute_model     = "ECPU"                # ECPU is recommended; OCPU is legacy
  compute_count     = 8
  node_count        = 1                     # 2 = RAC, needs ENTERPRISE_EDITION_EXTREME_PERFORMANCE
  database_edition  = "ENTERPRISE_EDITION_HIGH_PERFORMANCE"
  license_model     = "LICENSE_INCLUDED"    # or BRING_YOUR_OWN_LICENSE
  data_storage_size_in_gb         = 1024
  storage_volume_performance_mode = "HIGH_PERFORMANCE"   # or BALANCED
  ssh_public_keys                 = [file(var.ops_ssh_pubkey)]

  db_system_options {
    storage_management = "ASM"              # LVM for faster single-node provisioning
  }

  db_home {
    db_version = var.db_version             # a 19c or 26ai release update listed for your region
    database {
      admin_password = var.admin_password   # from a vault in real pipelines, never a literal
      db_name        = "ORDERS"
      pdb_name       = "ORDERSPDB"
      db_backup_config {
        auto_backup_enabled     = true
        recovery_window_in_days = 30
      }
    }
  }
}

A few details in that block carry weight. node_count = 2 creates a RAC system and only works with the Extreme Performance edition. license_model decides whether the hourly price includes the Oracle licence or you bring your own. recovery_window_in_days is the automatic-backup window, discussed next. And the admin password belongs in a secret store, passed in at apply time, not in the repository or the Terraform state in plain text. Restrict who can manage database resources in the compartment with policies, as described in OCI IAM.

Backups: Object Storage or Recovery Service

Automatic backups are the feature teams most often misconfigure, because there are two destinations with different behaviour.

Object Storage backups are standard RMAN backups written to buckets that OCI manages; the Object Storage article explains the underlying service. Recovery Service is a managed backup appliance service based on Oracle's Zero Data Loss Recovery Appliance technology. It validates backups, keeps them in a separate service with its own retention lock, and with real-time protection receives redo continuously, so a restore can reach almost the moment of failure.

Two warnings from the documentation deserve repeating. If you defer the initial backup when enabling automatic backups, the database may not be recoverable until one completes. And a backup you have never restored is a hypothesis, not a backup: schedule a quarterly restore into a scratch DB system and time it.

High availability, Data Guard and patching

A single-node DB system has no automatic failover. If the VM or its host fails, OCI restarts it, but you are down until the database opens again. There are two ways to do better. Two-node RAC protects against a node failure with both instances active on shared ASM storage, but both nodes are in one availability domain and share the same storage, so it does not protect against a storage-level or site-level failure.

Data Guard is the answer for those. OCI creates a Data Guard association between a primary database and a standby on a second DB system, in another availability domain or region, and exposes switchover, failover and reinstate as control-plane operations. Redo ships continuously, and the protection mode sets whether commits wait for the standby. Opening the standby read-only for reporting while it applies redo is Active Data Guard, which requires a licence that includes it. Data Guard is not available for the Developer edition or preview versions.

Patching has two layers: the DB system (operating system and Grid Infrastructure) and each database home. OCI publishes available updates, runs prechecks as jobs, and applies them on your schedule; on RAC it can patch node by node. The service does not choose your maintenance window or test your application against the new release update. Run the precheck first, patch the standby before the primary where you have one, and keep a record of which release update each home runs.

Day-two operations

Most routine work goes through the control plane, but you still have root and SYSDBA, and some answers are only visible from inside the VM. A minimal toolkit:

# From your workstation: inventory and an on-demand backup (OCI CLI)
oci db system list --compartment-id "$DB_COMPARTMENT"
oci db database get --database-id "$DB_OCID"
oci db backup create --database-id "$DB_OCID" --display-name "pre-release-2026-10-01"

# On the DB node: DBCLI is in /opt/oracle/dcs/bin and must run as root
sudo -i
dbcli list-databases
dbcli list-jobs            # job IDs, status and timestamps
dbcli describe-job -i <job-id>   # the step-by-step detail of one job

# As the oracle user: confirm what the database actually has
sqlplus / as sysdba <<'SQL'
select name, open_mode, database_role, log_mode from v$database;
show pdbs
select * from v$rman_backup_job_details order by start_time desc fetch first 5 rows only;
SQL

DBCLI records its operations as jobs with IDs and status, so when a lifecycle operation fails, dbcli list-jobs and dbcli describe-job on the node are a good place to look for the failing step. Monitor the database with OCI Monitoring for host metrics and with the database's own views and AWR for SQL-level performance. The service provides a managed VM, not a performance tuning service.

A worked design: an orders database

Consider an orders system with a 600 GB database, around 2,000 transactions per second at peak, a 15-minute recovery time objective and a data-loss tolerance of seconds. A reasonable design: Enterprise Edition High Performance, single node with ASM, HIGH_PERFORMANCE block volumes sized well above 600 GB for I/O headroom, ECPUs sized from a load test, and Data Guard to a standby DB system in a second availability domain. Backups go to Recovery Service under the Silver policy (35 days) with real-time protection, because Object Storage backups alone would lose up to the last archived-log backup.

Why not RAC? RAC would protect against a node failure, but the Data Guard standby already covers node, storage and availability-domain failures within the 15-minute objective, and RAC adds the Extreme Performance licence and cluster tuning. If the business later needs zero downtime for rolling patching or node loss, RAC becomes worth its cost. Why not Autonomous Database? The team needs custom init parameters, an OS-level agent and control over patch timing, all of which Base Database allows and Autonomous deliberately hides. The OCI overview places both services in the wider catalogue.

Failure modes and trade-offs

• Backups failing silently for weeks because the subnet has no route to Object Storage or Recovery Service. Add the service gateway and route rule, then alarm on backup job failures, not just on database availability.
• I/O-bound on a small volume. Performance follows volume size and mode; a 256 GB balanced volume on a busy OLTP system will show high log file sync waits. Grow the volume or switch its performance mode before adding CPUs.
• Edition regret. RAC, and several options your application may later need, depend on the edition chosen at creation. Moving editions usually means building a new system and migrating, so decide deliberately.
• Drift from hand edits. Root access means people change things the control plane doesn't know about, and later OCI operations can fail or undo those changes. Keep host changes in configuration management and record them.
• Patch skew. Primary and standby on different release updates can break switchover. Patch the pair as a unit.
• Trade-off summary. Base Database gives control and full Oracle features at the price of operating the database yourself. Autonomous Database removes most operations but also the knobs. Exadata-based services give more performance and consolidation at a higher floor cost.

What to do next

1. List the constraints that fix creation-time choices: edition features, RAC or not, LVM or ASM, and the region and availability domains for a standby.
2. Put the DB system in a private subnet with a network security group and a service gateway, and verify the backup route before loading data.
3. Choose Recovery Service or Object Storage from your RPO and retention needs, and do not defer the initial backup.
4. Declare the DB system in Terraform with the password supplied from a secret store, and keep shape and version in variables.
5. Add Data Guard to a second availability domain or region for anything with a recovery-time objective shorter than a rebuild.
6. Schedule a restore drill and a patch-precheck routine, and alarm on failed DBCLI and backup jobs.