Oracle RMAN → Azure Blob: Quick Setup Guide

Oracle RMAN → Azure Blob: Quick Setup Guide
Oracle RMAN → Azure Blob

Backup to Azure, the clean way

Minimal steps, Oracle JDK only, and the recommended oracle.azure library alias.

What you’ll need

  • Azure Storage account: storageaccount, sharedkey, container
  • Oracle Database 19c RU ≥ 19.28 (or 23ai RU ≥ 23.8)
  • Use the Java in $ORACLE_HOME/jdk/bin/java
  • Outbound access from DB host to Azure Blob
Tip: Prefer a dedicated wallet directory (mode 700) that survives Oracle Home patching.

At a glance

✅ Supported Works on on-prem or Azure VMs.

Reference: Oracle Database Cloud Backup Module for Azure

1) Prepare the module

# Unpack the Azure setup tool inside your Oracle Home
mkdir -p $ORACLE_HOME/lib/azmodule
cd $ORACLE_HOME/lib/azmodule
unzip -q $ORACLE_HOME/lib/az_setup.zip

2) Create wallet dir (secure)

mkdir -p /u01/app/oracle/az_wallet
chmod 700 /u01/app/oracle/az_wallet
Why: The setup writes Azure credentials into this wallet directory.

3) Run setup with Oracle JDK

# Use the Java that ships with your Oracle Home
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/lib/azmodule/az_setup.jar \
  -storageaccount "YOUR_STORAGE_ACCOUNT" \
  -sharedkey "YOUR_ACCOUNT_KEY" \
  -container "YOUR_CONTAINER" \
  -walletDir "/u01/app/oracle/az_wallet"

Outputs:

  • Wallet with Azure credentials
  • Config file: $ORACLE_HOME/dbs/az<ORACLE_SID>.ora
Optional flags (click to expand)
  • -immutable-container <name> · enable immutable backups
  • -proxyHost, -proxyPort, -proxyId, -proxyPass · behind a proxy
  • -configFile /path/az.ora · custom config location/name
  • -argFile arguments.txt · keep params in a file

4) Configure RMAN channel (recommended alias)

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
RMAN> CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
      PARMS 'SBT_LIBRARY=oracle.azure, ENV=(AZ_PFILE=$ORACLE_HOME/dbs/az<ORACLE_SID>.ora)';
Note: Using SBT_LIBRARY=oracle.azure avoids platform-specific paths and is the Oracle-recommended method.

5) Verify

RMAN> SHOW ALL CHANGED;

You should see:

CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=oracle.azure, ...';

6) Test backup

RMAN> BACKUP DATABASE;

Expected lines in output:

using target database control file instead of recovery catalog
channel ORA_SBT_TAPE_1: Oracle Database Azure Backup Service Library VER 19.xx

7) (Optional) Test restore

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;

FAQ & Gotchas

  • Direct library path? Don’t. Use oracle.azure alias instead of pointing to libaz.so.
  • Java version? Run the setup using $ORACLE_HOME/jdk/bin/java for best compatibility.
  • Multiple DBs on same host? Each DB should have its own az<ORACLE_SID>.ora or a custom -configFile.
  • Immutability? Configure an immutable container and add -immutable-container to the setup if required by policy.

© Your Team • Adjust paths/SIDs as needed. Safe travels to the cloud ☁️

Comments

Post a Comment

Popular posts from this blog

Error when Installing Some Postgresql Packages (Perl IPC-Run)

Resolving PostgreSQL 17 Dependency Error on Oracle Linux 8 Fixing perl(IPC::Run) Dependency Error When Installing PostgreSQL 17 on Oracle Linux 8 Background While preparing a fresh Oracle Linux 8 server for a PostgreSQL 17 deployment, an attempt to install all PostgreSQL packages in one go failed with an unsatisfied dependency error: Problem 1: cannot install the best candidate for the job - nothing provides perl(IPC::Run) needed by postgresql17-devel-17.4-1PGDG.rhel8.x86_64 ... Root Cause The perl(IPC::Run) module (along with several tool‑chain libraries) resides in the CodeReady Builder repository, which is disabled by default on Oracle Linux 8. Because postgresql17-devel and postgresql17-test depend on that module, dnf / yum cannot resolve the full dependency tree unless the repository is enabled. CodeReady Builder hosts developer‑oriented packages—compilers, debuggers, Perl/Python modules—that ma...
Read more

Creating Jobs With Different Users via pg_cron in Azure Postgresql Flexible Server

PostgreSQL pg_cron: Scheduling Materialized View Refresh Across Databases PostgreSQL pg_cron: Scheduling Materialized View Refresh Across Databases In this tutorial, I’ll walk you through the process of scheduling a Materialized View refresh using the pg_cron extension in PostgreSQL. Specifically, we’ll cover how to execute a scheduled SQL command in a different database using cron.schedule_in_database . Step 1: Enable the pg_cron Extension in Azure Portal On Azure PostgreSQL Flexible Server, the pg_cron extension is managed directly through the Azure portal. Follow these steps: Go to the Azure portal and navigate to your PostgreSQL Flexible Server instance. Under the Server Parameters section, locate the azure.extensions parameter. Add PG_CRON to the list of allowed extensions (as shown in the screenshot). Once enabled, the extension is automatically installed in the default `postgres` database . If you need to schedule jobs in o...
Read more

Oracle 19c Dataguard Installation with DG Broker

Oracle 19c Data Guard – Standby Creation, Switchover & Failover Oracle 19c Physical Standby Creation & Management (RMAN Duplicate + Data Guard Broker) This article walks through building a physical standby using RMAN  DUPLICATE FROM ACTIVE DATABASE , then managing switchover / failover with the Data Guard Broker. The commands were tested on Oracle Linux 8 with Oracle Database 19c . Assumptions Two hosts ( oracle1.localdomain & oracle2.localdomain ) with Oracle 19c installed. Primary instance runs on oracle1 ; standby will be created on oracle2 . Listener port 1521 is reachable in both directions (check firewalls). Primary DB name MYDBPROD ; standby unique name MYDBDG . 1 – Primary Server Preparation 1.1 Switch to ARCHIVELOG & Force Logging -- Check mode SELECT log_mode FROM v$database; -- If NOARCHIVELOG: SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCH...
Read more