ora-base

This article covers the host-level setup of a purpose-built AMD EPYC 9124 tower server for Oracle workload virtualisation using Proxmox VE 9.1. The hardware was purchased with BIOS pre-configured for IOMMU, SR-IOV, and Global C-States. Before creating a single VM, the network bridges, VLANs, and ZFS storage pools must be correct — mistakes here cascade into every VM that follows. 1. Hardware Reference Component Detail Case Fractal Design Define 7 XL Motherboard Supermicro H13SSL-N (E-ATX, AMD SP5) CPU AMD EPYC 9124 — 16C/32T, 3.1 GHz, 125W cTDP RAM 8× 32 GB DDR5-4800 ECC Registered = 256 GB OS NVMe 2× Samsung 990 PRO 1 TB M.2 PCIe 4.0 (ZFS mirror) VM NVMe 4× Samsung PM9A3 1.92 TB U.2 PCIe 4.0 (ZFS pool) 1GbE NICs 2× onboard (H13SSL-N) 10GbE NICs 1× Intel X550-T2 PCIe → 2 ports (SR-IOV capable) PSU SilverStone VERTEX PX-1000 (1000W, 80+ Platinum) BIOS IOMMU on · SR-IOV on · Global C-States on · cTDP 125W 2. Proxmox VE 9.1 Installation 2.1 Boot and Install Download the Proxmox VE 9.1 ISO from https://www.proxmox.com/en/downloads and write to USB: ...

AWR reports are simultaneously the most powerful and most misread performance tool in Oracle’s arsenal. Most DBAs jump straight to Top SQL, copy the SQL_ID, and start tuning — skipping the sections that tell them why that SQL became a problem in the first place. This case study walks through a realistic AWR from a production Exadata system, section by section, using a deliberately constructed problematic scenario. Every number is fabricated for illustrative purposes; every diagnostic conclusion is grounded in real Oracle internals. ...

Performance diagnostics without a methodology is archaeology — you dig until you find something interesting, not necessarily something important. Oracle’s AWR and ASH provide an extraordinarily detailed record of database activity, but interpreting them requires a structured approach. This article presents a top-down methodology that moves from macro to micro: DB Time → Wait Profile → Top SQL → Root Cause. The Foundation: DB Time DB Time is the total time all sessions spent working in the database (on CPU or waiting for database resources) during a snapshot period. It is the single most important number in the AWR report. ...

Switchover and failover are the two role-transition operations in Oracle Data Guard. Switchover is a planned, graceful transition (both databases remain available throughout). Failover is an emergency response to primary failure. Having a tested, documented playbook for both is a MAA operational requirement — discovering the procedure on the night of a failure is not a plan. Terminology Recap Term Trigger Data Loss? Primary State Afterward Switchover Planned maintenance None Becomes standby (online) Failover Primary failure Possible (ASYNC) or None (SYNC) Unavailable (failed) Reinstate After failover N/A Failed primary becomes new standby Always use the Data Guard Broker (DGMGRL) for role transitions. Direct SQL*Plus procedures are error-prone and lack the consistency checks the Broker provides. ...

When multiple VM Clusters share the same Exadata storage cells on ExaCC, storage I/O becomes a shared resource that can interfere between workloads. Oracle’s I/O Resource Manager (IORM) is the mechanism for controlling how storage I/O is distributed across VM Clusters, databases, and consumer groups. Without IORM configuration, a single runaway workload on one VM Cluster can starve others. IORM Architecture on ExaCC IORM operates at two levels: Inter-VM Cluster IORM (configured via OCI): Controls storage I/O allocation between VM Clusters sharing the same physical Exadata infrastructure. Intra-database IORM (configured via DBCA or DBRM): Controls I/O between databases within a single VM Cluster and between consumer groups within a database. Because ExaCC does not give customers cellcli access, inter-VM Cluster IORM is configured through the OCI Console or API — Oracle’s management layer pushes the configuration to the storage cells. ...

Exadata Cloud@Customer (ExaCC) delivers the Oracle Cloud control plane experience on Exadata hardware that physically resides in the customer’s data centre. For organisations with data residency requirements, latency-sensitive applications that cannot tolerate public cloud networking, or regulatory constraints that prohibit off-premises data, ExaCC is the path to Autonomous Database and managed Exadata without public cloud. Understanding ExaCC’s architecture — particularly the control plane / data plane separation and the VM Cluster model — is essential for architects sizing, operating, and troubleshooting the platform. ...

Migrating from Exadata X7 to X11M is not a simple hardware swap — it is a generational architectural shift. The X11M introduces RoCE (RDMA over Converged Ethernet) replacing InfiniBand, PCIe Gen5 NVMe replacing earlier NVMe tiers, and a new compute architecture with AMD EPYC processors. This article provides an in-depth, end-to-end playbook for architects and senior DBAs planning this migration. Reference Environment All commands in this article use the following concrete hostnames and roles. Every code block identifies which server and user account the command runs from. ...

Active-active replication — where two or more databases accept writes simultaneously and replicate to each other — is one of the most powerful but also most operationally complex GoldenGate topologies. Without a robust conflict detection and resolution (CDR) strategy, you will silently corrupt data on one or both sides. This article covers CDR mechanics, built-in GoldenGate resolution handlers, and architectural patterns that minimise conflict occurrence in the first place. Why Conflicts Occur In a bidirectional topology, any row can be updated on either site concurrently. A conflict occurs when: ...

Oracle GoldenGate ships in two distinct deployment architectures: the Classic Architecture (the original GGSCI-based model) and the Microservices Architecture (introduced in 18c, fully mature from 21c). Both replicate data using the same trail-file and process model under the hood, but they differ substantially in how processes are deployed, managed, and monitored. Choosing the wrong one for your use case adds unnecessary operational complexity. The Fundamental Difference Dimension Classic Microservices Management interface GGSCI command-line REST API + Web UI Process model OS-level processes managed by Manager Microservices managed by Service Manager Configuration storage Flat parameter files (.prm) Internal repository (configurable) Deployment unit Single installation per host Service-based; multiple deployments per host OCI/Cloud-native fit Requires custom automation Native REST/API; integrates with OCI GoldenGate Security Parameter-file credentials Credential store + wallet Multi-tenancy (CDB) Limited Full PDB-level pipeline isolation Classic Architecture: Operational Model In Classic, the Manager process is the parent for all Extract, Pump, and Replicat processes. You interact with the system via GGSCI (GoldenGate Software Command Interface). ...

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. ...