ORACLE DATABASE

 When managing Oracle Database deployments on Exadata Dedicated Infrastructure—including Oracle Database@AWS —backup throughput is directly influenced by how Recovery Manager (RMAN) allocates channels across compute nodes. By default, the automated tooling computes parallel channels based on available compute capacity (OCPUs or ECPUs). However, smaller test or QA databases with modest compute allocations often need faster backup windows. Understanding how Oracle allocates channels during backup versus restore operations is critical for sizing your environment and avoiding unnecessary CPU scale-up costs. OCPU vs. ECPU: Default RMAN Channel Allocation Rules Oracle’s managed backup frameworks dynamically calculate the default number of channels per compute node based on provisioned core capacity: ECPU vs. OCPU Metric Conversion:  1  OCPU = 4 ECPUs. Default Channel Formula:   Compute Ratio & Default Channel Sizing Oracle Database@AWS uses the following standard cor...

 Connecting to the ARS Recovery Catalog with RMAN When using Oracle Autonomous Recovery Service (ARS / DBRS) for database backups, the connection to the recovery catalog is secured via an auto-generated Oracle Wallet and configured TNS alias. To run manual RMAN operations (such as maintenance, reporting, or manual validation), you need to point your environment to the directory containing the ARS wallet/TNS configuration and connect via the catalog alias. Step 1: Locate and Set the TNS_ADMIN Directory First, identify the directory where your ARS configuration files ( tnsnames.ora , sqlnet.ora , and wallet files like cwallet.sso ) reside. On OCI Database environments (such as Base Database Service or Exadata), these are typically stored under the database cluster file system (ACFS) path. Export the TNS_ADMIN environment variable so RMAN knows where to look for network configuration and credential artifacts: # Verify the directory path containing your ARS credentials [oracle@dev-f...

  A real-world troubleshooting log detailing root-cause investigations, Oracle Support escalations, and clean-up workarounds on Oracle Database@AWS. Migrating and managing Oracle workloads on Oracle Database@AWS (OCI Exadata Database Service on AWS) brings native cloud elasticity to enterprise-grade database hardware. However, when working with cross-cloud automation, Transparent Data Encryption (TDE), and managed backup workflows, hitting automation edge cases is part of the journey. Recently, our team worked through a complex database restore scenario via the "Create Database from Backup" feature. Along the way, we navigated multiple failure points across TDE wallet handling, OCI/AWS object storage media managers, and metadata synchronization between the web console and the OS layer. Here is the step-by-step breakdown of the errors encountered, the mitigations applied, and key takeaways for cloud DBAs. Failure 1: The Null TDE Wallet Password Bug Our initial attempt was st...

Automation in the Oracle ecosystem is a double-edged sword. When systems like Autonomous Recovery Service (ARS)  work, they are absolute lifesavers - offloading heavy background lifting, ensuring zero-data-loss protection, and preventing manual human error. However, when an automated mechanism hits a database restore failure issue, an unhandled corner case, or a misconfigured VCN/policy, it can quietly stall, block recovery pipelines, or trigger subtle background wait event spikes. Issue 1: During a database restore from backup, the creation process failed with: the password of TDE wallet cannot be null . The root cause turned out to be a UI/orchestration gap: the console failed to prompt for the TDE wallet password during setup, causing the automated restore job to immediately fail when attempting to open the wallet. The Root Cause: A Identity Crisis Between Oracle Wallet and AWS KMS So, what actually went wrong behind the scenes? As part of an infrastructure modernization effor...

In the world of high-availability database management, we have long been forced to accept a painful trade-off: Performance or Protection. If you want "Zero Data Loss" (Synchronous transport), your standby must be physically close to the primary leaving you vulnerable to regional disasters. If you move your standby a thousand miles away for true safety, you’re forced into "Asynchronous" mode, accepting the risk of data loss if the primary goes down. While Oracle offers a robust suite of options from Physical and Logical standbys to the queryable power of Active Data Guard - none of them truly solve this distance-versus-latency dilemma on their own. Enter Oracle Data Guard Far Sync. Far Sync isn't just another standby type; it is a lightweight, high-speed relay that acts as the "missing link" in your architecture. It allows you to achieve the holy grail of DBA goals: Synchronous-level protection over Asynchronous-level distances. In this post, we’ll ex...

Modern enterprises increasingly require centralized identity management and seamless single sign-on (SSO) across cloud platforms. Oracle addresses this need by enabling Microsoft Entra ID (MS‑EI) integration for Oracle Databases running on Oracle Exadata Database Service on Dedicated Infrastructure . This blog walks through how MS‑EI authentication and authorization works , key prerequisites , networking and TLS requirements , and the supported authentication flows - from a DBA and cloud architect perspective. Why Integrate Microsoft Entra ID with Oracle Exadata? By integrating Oracle Database with Microsoft Entra ID (formerly Azure AD), organizations can: Centrally manage database users and access policies in MS‑EI Enable SSO-based database authentication Eliminate local database passwords Use modern OAuth2 token-based authentication Align Oracle access controls with enterprise identity governance This integration is supported for: ...