OCI

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 # [[email protected] ~] # 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 # [[email protected] ~] # 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 # [[email protected] ~] 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 # [[email protected] ~] # 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. ...

This article presents a complete, real-world migration playbook for moving an Oracle Database from an on-premises Exadata X8 to Oracle Database@Azure Autonomous Database Serverless (ADB-S). The two data centres are 70 km apart, connected via a dedicated Azure ExpressRoute circuit. We use Oracle Zero Downtime Migration (ZDM) with GoldenGate replication to achieve a sub-minute application downtime. Environment Diagram ┌─────────────────────────────────────────────────────────────────┐ │ ON-PREMISES DATA CENTRE (Frankfurt) │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ EXADATA X8 FULL RACK │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ │ │ │ │ x8db01 │ │ x8db02 │ Compute nodes │ │ │ │ │ (RAC inst1) │ │ (RAC inst2) │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ │ │ │ │ └──────── IB ─────────┘ │ │ │ │ ┌──────────────────┐ │ │ │ │ │ Storage Cells │ (8 cells) │ │ │ │ │ x8cel01–x8cel08 │ │ │ │ │ └──────────────────┘ │ │ │ │ │ │ │ │ Database: ORCL (CDB), PDB: PDB_ERPSYS │ │ │ │ Size: 3.2 TB (data) + 400 GB indexes │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ ZDM Service Host: zdmhost01.prod.example.com │ │ │ │ GoldenGate Extract: running on x8db01 (Integrated) │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ │ Azure ExpressRoute │ │ │ Dedicated, 10 Gbps, 70 km │ │ │ RTT: ~0.7 ms (measured) │ │ │ │ └─────────────────────┼──────────────────────────────────────────-─┘ │ ┌──────────────────────┼──────────────────────────────────────────┐ │ ORACLE DB@AZURE (West Europe — Amsterdam) │ │ │ │ │ ┌────────────────────▼──────────────────────────────────────┐ │ │ │ Oracle Database@Azure — ADB-S │ │ │ │ Display Name: adb-erpsys-prod │ │ │ │ DB Name: ADBERPSY │ │ │ │ Shape: 16 OCPUs, auto-scale │ │ │ │ Storage: 10 TB (elastic) │ │ │ │ TLS: mTLS (wallet-based) │ │ │ │ │ │ │ │ OCI GoldenGate (Managed Microservices deployment) │ │ │ │ GG Service: gg-erpsys-deployment │ │ │ │ Replicat: REP_ERPSYS (Integrated) │ │ │ └────────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘ Network Architecture On-Premises Exadata Azure ExpressRoute Oracle DB@Azure (Frankfurt DC) (Dedicated, 10 Gbps) (Amsterdam) 10.10.0.0/16 ───────────────────────────────────────► 172.16.0.0/16 Key Network Points: x8db01 public IP: 10.10.1.101 x8db01 SCAN IP: 10.10.1.200 (for GoldenGate source connection) zdmhost01: 10.10.5.50 OCI GoldenGate GW: 172.16.10.10 (private endpoint) ADB-S private EP: 172.16.20.5 (private endpoint in Oracle DB@Azure VNet) ExpressRoute Circuit: Provider: equinix-frankfurt Bandwidth: 10 Gbps dedicated Measured RTT (Frankfurt → Amsterdam): 0.7 ms Throughput achieved (iperf3): 9.2 Gbps (92% of capacity) Reference Environment SOURCE (On-Premises Exadata X8): RAC node 1: x8db01.prod.example.com (oracle user) RAC node 2: x8db02.prod.example.com Storage cells: x8cel01–x8cel08.prod.example.com ZDM host: zdmhost01.prod.example.com (oracle user, ZDM installed here) DB unique name: ORCL PDB: PDB_ERPSYS Data size: 3.2 TB DB version: 19.18.0.0 TARGET (Oracle DB@Azure): Region: Azure West Europe (Amsterdam) Resource Group: rg-oracle-prod ADB name: adb-erpsys-prod ADB DB Name: ADBERPSY Service name: adberpsy_high (high priority service) mTLS wallet dir: /etc/oracle/adb_wallet/ (on zdmhost01) OCI GG deploy: gg-erpsys-deployment (Microservices, managed by Oracle) OCI GG version: 21c ADMIN JUMP HOST: admin01.prod.example.com (used for OCI CLI, ZDM monitoring) Phase 1: Pre-Migration Assessment 1.1 Network Latency and Throughput Validation Before any migration work, validate the ExpressRoute circuit performance from the ZDM host: ...