ora-base

Migrating an Oracle database to OCI involves more than moving data — it requires selecting the correct migration toolchain, designing for cutover, and managing risk. Oracle provides multiple migration paths, and choosing incorrectly leads to extended downtime or data integrity issues. This article compares the major approaches and provides decision criteria. Migration Approach Decision Tree Is downtime during migration acceptable? ├── YES (hours or more acceptable) │ ├── Database size < 1 TB → Data Pump (expdp/impdp) over network or pre-stage to Object Storage │ └── Database size > 1 TB → RMAN duplicate or backup/restore to OCI Object Storage └── NO (near-zero or zero downtime required) ├── Source is Oracle → Zero Downtime Migration (ZDM) with GoldenGate └── Source is non-Oracle → OCI Database Migration Service (DMS) Zero Downtime Migration (ZDM) Oracle ZDM is the recommended tool for migrating Oracle databases to OCI with minimal or zero downtime. It orchestrates a combination of RMAN (initial bulk copy) + GoldenGate (ongoing replication during migration) in an automated workflow. ...

Oracle Base Database Service (formerly DB System) is OCI’s IaaS-level Oracle Database offering — you provision a VM or Bare Metal shape, OCI installs and manages Oracle Database, and you retain full DBA control. Understanding its HA architecture is essential for designing systems that meet enterprise RPO/RTO targets. Shape Selection and Its HA Implications Base Database Service runs on two shape families: VM shapes (VM.Standard, VM.Optimized) — single or 2-node RAC. Bare Metal shapes (BM.DenseIO) — single instance with local NVMe, high IOPS. For high availability, the critical shape decision is whether to provision a 2-node RAC or a single-instance + Data Guard architecture. These are not equivalent: ...

The OCI command-line interface (oci) and the Exadata/DB System management CLI (dbaascli) are the tools of choice for automating Oracle database operations on OCI. This article covers real-world scenarios with complete, runnable commands — including the complex case of creating a Data Guard standby when the primary database uses Oracle Key Vault (OKV) for TDE key management. Reference Environment All commands use the following environment: Region: eu-frankfurt-1 Compartment: prod-compartment (OCID: ocid1.compartment.oc1..aaaaxxxx) Primary DB System: prod-db-system Hostname: proddb01.prod.subnet.vcn.oraclevcn.com Database: PRODCDB (CDB + PDB: PDB_PROD) Shape: VM.Standard.E4.Flex (4 OCPUs, 60 GB RAM) DB Version: 19.22.0.0 DB Home OCID: ocid1.dbhome.oc1.eu-frankfurt-1.aaaaxxxx Database OCID: ocid1.database.oc1.eu-frankfurt-1.aaaaxxxx Standby DB System: standby-db-system (to be created) Hostname: stbydb01.stby.subnet.vcn.oraclevcn.com AD: AD-2 (primary is AD-1) OKV Server: okv01.prod.example.com (port 5695) OKV Wallet: /etc/oracle/okv/ (on each DB System compute node) Jump/Admin Host: admin01.prod.example.com OCI CLI version: 3.x.x Python: 3.9 Part 1: OCI-CLI — Foundation Commands Install and Configure OCI-CLI # [oracle@admin01.prod.example.com ~] # Install OCI CLI bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)" # Configure with API key authentication oci setup config # Prompts: # User OCID: ocid1.user.oc1..aaaaxxxx # Tenancy OCID: ocid1.tenancy.oc1..aaaaxxxx # Region: eu-frankfurt-1 # Generate new API key pair: Y # Key file location: ~/.oci/oci_api_key.pem # Upload the generated public key to OCI Console: Identity → Users → API Keys → Add Useful OCI-CLI Shortcut: Environment Variables # [oracle@admin01.prod.example.com ~] # Set frequently used OCIDs as environment variables export OCI_COMPARTMENT=ocid1.compartment.oc1..aaaaxxxx export OCI_PRIMARY_DB_SYSTEM=ocid1.dbsystem.oc1.eu-frankfurt-1.aaaaxxxx export OCI_PRIMARY_DB=ocid1.database.oc1.eu-frankfurt-1.aaaaxxxx export OCI_PRIMARY_DB_HOME=ocid1.dbhome.oc1.eu-frankfurt-1.aaaaxxxx export OCI_REGION=eu-frankfurt-1 # Also useful: set output format to table for human-readable output export OCI_CLI_TABLE_OUTPUT_STYLE=table Part 2: Creating a Data Guard Standby via OCI-CLI Step 1: Verify Primary Database Status # [oracle@admin01.prod.example.com ~] oci db database get \ --database-id $OCI_PRIMARY_DB \ --query 'data.{Name:"db-name", State:"lifecycle-state", "DB Unique Name":"db-unique-name", Version:"db-version"}' \ --output table +-------------------+--------+--------------------+-----------+ | DB Unique Name | Name | State | Version | +-------------------+--------+--------------------+-----------+ | PRODCDB | PRODCDB| AVAILABLE | 19.22.0.0 | +-------------------+--------+--------------------+-----------+ Step 2: Get the Subnet OCID for the Standby AD # [oracle@admin01.prod.example.com ~] # Find the standby subnet in AD-2 oci network subnet list \ --compartment-id $OCI_COMPARTMENT \ --query 'data[?contains("display-name",`stby`)].{Name:"display-name", OCID:id, AD:"availability-domain"}' \ --output table Step 3: Create the Data Guard Association (New DB System) This single command provisions the standby DB System, configures redo transport, and establishes Data Guard: ...

Oracle Autonomous Database (ADB) is often described in marketing terms: “self-driving, self-securing, self-repairing.” For architects and senior DBAs, the more useful question is: what does it actually do automatically, how does it do it, and where do you need to intervene? This article peels back the automation layers. The Infrastructure Foundation Every ADB instance runs on Exadata Cloud Service (ExaCS). This is not incidental — it is the technical prerequisite for the automation that ADB delivers. The Smart Scan offload, HCC compression, and storage index features described elsewhere in this blog are all active beneath every ADB workload. ...

Far Sync is an Oracle Data Guard feature that lets you achieve zero data loss (SYNC transport) to a remote standby database without paying the latency penalty on primary transactions. A Far Sync instance sits in a third location between the primary and the standby, receives redo synchronously from the primary (low-latency hop), and then ships it asynchronously to the standby (long-distance hop). 1. Reference Architecture 1.1 Environment Overview Role Hostname DB Unique Name Location OS Primary DB (RAC, 2 nodes) prim01.fra.example.com, prim02.fra.example.com ORCL_FRA Frankfurt DC (AZ-1) OL 8.9 Far Sync Instance farsync01.fra.example.com ORCL_FS Frankfurt DC (AZ-2) OL 8.9 Physical Standby (RAC, 2 nodes) stby01.ams.example.com, stby02.ams.example.com ORCL_AMS Amsterdam DC OL 8.9 DGMGRL / Observer host observer01.fra.example.com — Frankfurt DC (AZ-3) OL 8.9 Oracle version: 19c (19.23 RU) Primary ↔ Far Sync network: Dedicated 10 GbE VLAN, round-trip latency ≈ 0.4 ms Far Sync ↔ Standby network: WAN link, round-trip latency ≈ 8 ms DB_NAME: ORCL (same for all members); DB_UNIQUE_NAME differs per member 2. Live Redo Information Flow The diagram above shows the full geographical redo flow. Below is the step-by-step explanation of how zero data loss is achieved: ...

The redo transport configuration is the most consequential architectural decision in a Data Guard deployment. It determines the data loss exposure (RPO), the performance overhead on the primary, and the recovery point after a failover. Choosing SYNC or ASYNC without understanding the mechanics leads to either unacceptable data loss or unnecessary primary database degradation. Redo Transport Mechanisms ASYNC Transport (ARCN-based) In ASYNC mode, the primary database commits without waiting for the standby to acknowledge receipt of redo. The ARCn background process archives completed log groups and ships them to the standby. ...

Oracle Database In-Memory (DBIM) adds a columnar representation of data alongside the existing row-based buffer cache. The key architectural insight is that both formats coexist — OLTP operations continue using the row-store (buffer cache) for optimal single-row performance, while analytical scans use the column store for optimal aggregation performance. The optimizer decides which format to use per operation. The Dual-Format Architecture Traditional databases force a choice: row format for OLTP, column format for analytics. Oracle’s approach avoids this by maintaining both simultaneously: ...

Oracle Database Vault (DBV) restricts highly privileged database accounts (DBA, SYSDBA) from accessing application data. On Exadata, this is particularly important: Exadata DBAs have elevated OS access (root on compute nodes, cellcli on storage cells), making privilege separation inside the database itself critical for compliance frameworks such as SOX, PCI-DSS, and HIPAA. This guide implements DB Vault entirely via command line — no OEM Cloud Control. All steps apply to Oracle Database 19c on Exadata in both CDB and non-CDB deployments. ...

The Oracle Exadata Deployment Assistant (OEDA) is the mandatory tool for configuring and deploying Oracle Grid Infrastructure and Oracle Database on Exadata hardware. It generates the configuration XML that drives the automated install.sh deployment script, eliminating manual installation error. This article covers the full OEDA workflow — from GUI configuration through XML generation to deployment execution — with real-world examples. What OEDA Does and Does Not Do OEDA does: Configure networking (public, private/InfiniBand/RoCE, management/ILOM, admin) Define cluster nodes, ASM disk groups, and storage configuration Configure Grid Infrastructure (GI) and Oracle Database parameters Generate the install.sh script and all supporting XML/config files Validate the configuration before deployment (via --check) OEDA does not: ...

Oracle GoldenGate is the industry standard for heterogeneous, real-time data replication and change data capture (CDC). Despite being in use for decades, its internal mechanics are frequently misunderstood, leading to poorly tuned deployments that bottleneck at the wrong layer. This article dissects the architecture from the redo log all the way to the target apply. Architecture Overview A GoldenGate pipeline has three logical tiers: Capture — the Extract process mines redo/archive logs on the source database. Distribution — the Data Pump (a secondary Extract) reads local trail files and transmits them to a remote trail on the target host. Apply — the Replicat process reads the remote trail and applies changes to the target database. Each tier operates independently, connected only through trail files — sequential, compressed binary files that serve as a persistent, durable queue between processes. ...