May 2, 2025

RMAN Configuration Demystified: A Practical Deep Dive for DBAs – Part 2

 

RMAN Configuration Demystified: A Practical Deep Dive for DBAs – Part 2

 

RMAN > CONFIGURE DEVICE TYPE DISK PARALLELISM 2;

 

  • RMAN opens 2 channels to write to disk simultaneously.
  • This improves backup/restore speed, especially for large databases or multiple datafiles.
  • Each channel can operate independently, writing to different backup pieces.

 

RMAN >CONFIGURE DEVICE TYPE SBT PARALLELISM 2;

 

·         RMAN will use 2 channels to send backup data to tape drives in parallel.

·         This improves throughput (faster backups/restores) especially when:

·         You have multiple tape drives.

·         Your tape infrastructure supports concurrent streams.

 

RMAN >CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/orabackup/ora_df%t_s%s_s%p';

 

·         Sets the backup file naming format for disk backups.

·         %t represents four byte time stamp, %s with the backup set number, and %p with the backup piece number.

 

RMAN >CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;

 

·         RMAN Limits maximum size of a backup piece to 2 GB.

 

RMAN >CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/tmp/%U’;

 

·         Overrides previous disk format to /tmp/%U. (%U = unique filename)

 

RMAN >CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/disk1/%U’, ‘/disk2/%U’;

 

Defines where and how RMAN should name the backup files:

  • %U is a substitution variable that generates a unique file name.
  • RMAN will alternate writing backup pieces between /disk1/ and /disk2/ paths.
  • This provides load balancing across multiple directories/disks.

 

RMAN >CONFIGURE DEVICE TYPE <DISK | SBT> BACKUP TYPE TO COMPRESSED BACKUPSET;

 

This Configures RMAN to always create compressed backup sets instead of regular backup sets or image copies.

 

RMAN >CONFIGURE CONTROLFILE AUTOBACKUP ON;

 

This is used to enable automatic backup of the control file and the server parameter file (SPFILE) every time an RMAN backup is run or a structural change is made to the database.

 

RMAN >CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/u01/orclbackup/ora_cf%F';

 

This sets a custom format for automatic control file and SPFILE backups when the device type is DISK.

%F Combines the DBID, day, month, year, and sequence into a unique and repeatable generated name

 

RMAN >CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '+DATA/%F';

 

This is used to configure automatic control file and SPFILE backups to be stored in an Oracle ASM disk group named +DATA

 

RMAN >CONFIGURE BACKUP OPTIMIZATION ON;

 

It enables backup optimization, which helps avoid backing up files that haven't changed since the last backup.

With BACKUP OPTIMIZATION ON, RMAN will skip backing up:

  • Datafiles that are:
    • part of a previous backup of the same file
    • not changed since that backup
  • Archived redo logs that were already backed up to the same device type
  • Control files and SPFILEs that are unchanged

RMAN >CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT TO 2;

 

 

·         This command instructs RMAN to create 2 identical copies of each datafile backup when backing up to SBT (tape).

·         It will write 2 separate backup sets, each containing the same datafiles.

·         This increases redundancy — useful for offsite + onsite storage, or general fault tolerance.

 

RMAN >CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT TO 2;

 

·         This tells RMAN to create 2 identical copies of each archived redo log backup when backing up to SBT (tape).

·         It writes them as separate backup sets (not just duplicated files in the same set)

 

RMAN >CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;

 

·         It configures RMAN to create 2 identical backup copies of each datafile when backing up to disk.

·         Each copy is a complete, usable backup of the datafile.

·         This provides redundancy in case one backup file is lost or corrupted.

 

RMAN Configuration Demystified: A Practical Deep Dive for DBAs – Part 1

 

RMAN Configuration Demystified: A Practical Deep Dive for DBAs – Part 1

 

rman TARGET SYS/target_pwd@target_str

 

Explanation:

  • This command starts RMAN and connects only to the target database, using the credentials provided.
  • Since there's no CATALOG clause, this is a NOCATALOG mode backup/restore operation.
  • target_pwd is the password of the SYS user, and target_str is the TNS alias (or connection string) of the target database.

Use Case:

Used for RMAN operations without a recovery catalog. The control file is used to store backup metadata.

 

rman TARGET / CATALOG rman/rman@rcat

 

Explanation:

  • Connects to the target database using OS authentication (TARGET /) — assuming the user has SYSDBA privilege.
  • Connects to the recovery catalog database using the user rman with password rman and TNS alias rcat.

Use Case:

Used when backup metadata is maintained in a Recovery Catalog (preferred for environments with multiple databases or long backup retention policies).

 

rman TARGET / CATALOG rman/rman@rcat AUXILIARY sys/aux_pwd@aux_str

 

First let’s crack what is TARGET , CATALOG and AUXILIARY

TARGET Database :

This is the main database you want to back up, restore, or recover.

It is the primary subject of all RMAN operations.

You must always connect to a target database, even if using a recovery catalog.

E.g.

rman TARGET sys/password@orcl

rman TARGET /

 

CATALOG Database(Recovery Catalog)  :

The Recovery Catalog is an optional separate database schema (often in a dedicated database) that stores RMAN metadata.

It offers more advanced reporting, longer metadata retention, and can manage multiple target databases.

E.g.

rman TARGET / CATALOG rman/rman@rcat

rman/rman@rcat is the connection to the Recovery Catalog stored in the rcat database.

 

AUXILIARY Database:

The AUXILIARY is a secondary or temporary database used for specific RMAN operations

E.g.

rman TARGET / CATALOG rman/rman@rcat AUXILIARY sys/aux_pwd@aux_str

 

Explanation:

  • Connects to:
    • TARGET database via OS authentication.
    • CATALOG database using rman user.
    • AUXILIARY database using SYS user with password aux_pwd and TNS alias aux_str.

Use Case:

Used for operations that involve a secondary (auxiliary) database, such as:

  • Duplicating a database (cloning).
  • Tablespace point-in-time recovery (TSPITR).
  • Database point-in-time recovery (DBPITR).
  • Restore and recovery to an alternate location.

 

RMAN >CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR;

 

  • Clears any custom channel configuration for SBT (tape) backups.

 

RMAN >CONFIGURE RETENTION POLICY CLEAR;

 

  • Removes the existing retention policy setting.

 

RMAN >CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

 

·         Clears the control file autobackup format setting for disk.

 

RMAN >CONFIGURE DEFAULT DEVICE TYPE TO DISK/SBT;

 

·         Sets the default device for RMAN backups.

·         DISK: Backups go to file system.

·         SBT: Backups go to tape (e.g., via third-party software like NetBackup).

 

RMAN >CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

 

·         Redundancy in RMAN means how many copies of a distinct backup RMAN should retain at minimum.

·         When you set REDUNDANCY 3, you're telling RMAN:

"Keep at least 3 full backups of each datafile. If there are more than 3, the older ones can be marked obsolete."

RMAN >CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

 

·         RMAN will retain all backup sets (datafiles, control files, archived logs, etc.) that are required to perform a point-in-time recovery to any time in the last 4 days.

·         Older backups beyond the 4-day window are considered obsolete and can be deleted.

 

April 28, 2025

How to Configure Passwordless SSH Authentication Between Oracle RAC Nodes

 

How to Configure Passwordless SSH Authentication Between Oracle RAC Nodes

During Oracle RAC installation (especially Grid Infrastructure), the installer and tools need to execute commands across all RAC nodes automatically, without human intervention.

Password less SSH is needed because: 

During Installation Step

Why Passwordless SSH is Needed

Grid Infrastructure (GI) Installation

The Oracle Universal Installer (runInstaller) copies files, runs scripts, sets up ASM, Clusterware, CRS services across all nodes.

Cluster Verification (cluvfy)

Verifies shared storage, network config, user equivalence by connecting across nodes.

Running root.sh automatically

Installer needs to trigger root scripts remotely on all nodes.

Configuration of SCAN, VIPs

RAC configures network resources which requires access to all nodes without asking password each time.

opatchauto (patching GI or RAC)

OPatchAuto automatically connects to all nodes, stops CRS, applies patches, restarts — needs SSH access.

Database installation

Same for database binaries if installing with RAC options.

📋 As per Oracle Official Documentation :

"You must configure secure shell (SSH) for both the Oracle Grid Infrastructure software owner (grid) and the Oracle Database software owner (oracle) to enable passwordless SSH user equivalence across all cluster nodes. This is required for Oracle Universal Installer to copy and run scripts on all cluster nodes during installation."

  

Assumptions

  • Your RAC nodes: Atleast 2 node rac
  • You are configuring passwordless SSH for the following users:
    • grid user (for Grid Infrastructure)
    • oracle user (for RDBMS software)

(If you use only one user for both, steps are same.)

 

On node1(Hostname :testrac1) (as grid user):

[grid@testrac1 ~]$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/grid/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/grid/.ssh/id_rsa.

Your public key has been saved in /home/grid/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:bLXitTwHBHpFSE88BWI8pA0Bwq3Z0ifj4hb+tGvXrV4 grid@testrac1

The key's randomart image is:

+---[RSA 3072]----+

| .....o=*+=o.    |

|  ...  *+*o      |

|   =  o o.+.     |

|  + = .o o .     |

|   o +  S +      |

|  o .  o + o     |

| o o.  ...E .    |

|  +.... ...o     |

| . o+o .o.       |

+----[SHA256]-----+

[grid@testrac1 ~]$ cd ~/.ssh

[grid@testrac1 .ssh]$ cat id_rsa.pub >> authorized_keys

 

On node2(Hostname : testrac2)  (as grid user):

grid@testrac2 ~]$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/grid/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/grid/.ssh/id_rsa.

Your public key has been saved in /home/grid/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:BBrZIK8m2dhCjaH4jkPNwl9itHsx4QKVBM5PN754Hf8 grid@testrac2

The key's randomart image is:

+---[RSA 3072]----+

| o+o++.          |

|= =+.o..         |

|o* +o+  .        |

|o*B.= o.         |

|=+*O * .S        |

|.*+ * = o        |

|o .+ + . .       |

| .  o     .      |

|           E     |

+----[SHA256]-----+

 

[grid@testrac2 ~]$ cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys

 

Exchange Public Keys

From testrac1:

[grid@testrac1 .ssh]$ scp ~/.ssh/id_rsa.pub testrac2:/tmp/testrac1_id_rsa.pub

 

 

From testrac2:

[grid@testrac2 .ssh]$ scp ~/.ssh/id_rsa.pub testrac1:/tmp/testrac2_id_rsa.pub

 

 

Merge the keys into authorized_keys on both nodes

On testrac1:-

[grid@testrac1 .ssh]$ cat /tmp/testrac2_id_rsa.pub >> ~/.ssh/authorized_keys

 

On testrac2:-

[grid@testrac2 .ssh]$ cat /tmp/testrac1_id_rsa.pub >> ~/.ssh/authorized_keys

 

Perform same steps as above for oracle user if you are using oracle as RDBMS user

 

 

Test Password less authentication From Both server:-

From testrac1

[grid@testrac2 ~]$ ssh testrac1 date

Mon Apr 28 20:07:19 IST 2025

[grid@testrac2 ~]$ ssh testrac2 date

Mon Apr 28 20:07:24 IST 2025

 

From testrac2

[grid@testrac1 ~]$ ssh testrac1 date

Mon Apr 28 20:08:19 IST 2025

[grid@testrac1~]$ ssh testrac2 date

Mon Apr 28 20:08:29 IST 2025

 

This concludes the passwordless authentication between Oracle rac nodes

 

How to Configure SCAN and VIPs in Oracle RAC 19c

 

How to Configure SCAN and VIPs in Oracle RAC 19c


1. What is SCAN and VIP in RAC? (Quick intro)

  • SCAN (Single Client Access Name):
    • A single name that clients use to connect to the database.
    • Behind the scenes, SCAN resolves to three IP addresses (round-robin via DNS or GNS).
    • Advantage: No need to change client connection strings if nodes are added/removed.
  • VIP (Virtual IP):
    • Each RAC node gets a VIP in addition to its public IP.
    • If a node fails, its VIP can quickly failover to another node.
    • Helps in fast TCP/IP failover without long TCP timeout delays.

2. Network Requirements

You'll need three networks:

  • Public Network (for client/database communication)
  • Private Network (for cluster interconnect/heartbeat)
  • Optional: Backup Network (for redundancy)

Important IP planning:

IP Type

Needed

Public IPs

1 per node

VIPs

1 per node

Private IPs

1 per node

SCAN IPs

3 total (shared across the cluster)


3. DNS Setup (for SCAN and VIPs)

Before RAC installation, ensure:

  • SCAN Name points to three IP addresses in DNS.
  • VIP Names are mapped separately in DNS (or /etc/hosts for non-production setups).

Example DNS Entries:

# SCAN entries (round-robin DNS)

testrac-scan.subnet09212030.vcn09212030.oraclevcn.com IN A 10.0.0.98

testrac-scan.subnet09212030.vcn09212030.oraclevcn.com IN A 10.0.0.177

testrac-scan.subnet09212030.vcn09212030.oraclevcn.com IN A 10.0.0.112

# Public IPs

testrac1.subnet09212030.vcn09212030.oraclevcn.com IN  A 10.0.0.127

testrac2.subnet09212030.vcn09212030.oraclevcn.com IN  A  10.0.0.158

# VIPs

testrac1-vip.subnet09212030.vcn09212030.oraclevcn.com  IN  A  10.0.0.36

testrac2-vip.subnet09212030.vcn09212030.oraclevcn.com  IN  A  10.0.0.178

 

 

Note:

  • SCAN should not resolve to a single IP — must have three IPs.
  • VIPs should be in the same subnet as the public IPs.

4. /etc/hosts Example (if not using DNS)

# Public IPs

10.0.0.127 testrac1.subnet09212030.vcn09212030.oraclevcn.com testrac1

10.0.0.158  testrac2.subnet09212030.vcn09212030.oraclevcn.com  testrac2

 

# VIPs

10.0.0.36 testrac1-vip.subnet09212030.vcn09212030.oraclevcn.com testrac1-vip

10.0.0.178  testrac2-vip.subnet09212030.vcn09212030.oraclevcn.com  testrac2-vip

 

# Private Interconnect

192.168.16.18 testrac1-priv.subnet09212030.vcn09212030.oraclevcn.com testrac1-priv

192.168.16.19  testrac2-priv.subnet09212030.vcn09212030.oraclevcn.com  testrac2-priv

 

#Scan IPs

10.0.0.98         testrac-scan.subnet09212030.vcn09212030.oraclevcn.com

10.0.0.177      testrac-scan.subnet09212030.vcn09212030.oraclevcn.com

10.0.0.112      testrac-scan.subnet09212030.vcn09212030.oraclevcn.com

 


5. During Grid Infrastructure Installation

When you install Grid Infrastructure:

  • Installer will prompt for SCAN name.
  • Installer will auto-detect SCAN IPs based on DNS.
  • It will also ask for:
    • Public Interface
    • Private Interface
    • VIP names for each node.

Oracle Clusterware will configure and manage SCAN listeners and VIP listeners automatically after installation.


6. Post-Installation Checks

After installation:

  • Check SCAN listeners:

$srvctl config scan

[oracle@testrac1 ~]$ srvctl config scan

SCAN name: testrac-scan.subnet09212030.vcn09212030.oraclevcn.com, Network: 1

Subnet IPv4: 10.0.0.0/255.255.255.0/enp0s5, static

Subnet IPv6:

SCAN 1 IPv4 VIP: 10.0.0.112

SCAN VIP is enabled.

SCAN 2 IPv4 VIP: 10.0.0.177

SCAN VIP is enabled.

SCAN 3 IPv4 VIP: 10.0.0.98

SCAN VIP is enabled.

 

$srvctl config scan_listener

[oracle@testrac1 ~]$ srvctl config scan_listener

SCAN Listeners for network 1:

Registration invited nodes:

Registration invited subnets:

Endpoints: TCP:1521

SCAN Listener LISTENER_SCAN1 exists

SCAN Listener is enabled.

SCAN Listener LISTENER_SCAN2 exists

SCAN Listener is enabled.

SCAN Listener LISTENER_SCAN3 exists

SCAN Listener is enabled.

 

  • Check VIPs:

[oracle@testrac1 ~]$ srvctl config nodeapps

Network 1 exists

Subnet IPv4: 10.0.0.0/255.255.255.0/enp0s5, static

Subnet IPv6:

Ping Targets:

Network is enabled

Network is individually enabled on nodes:

Network is individually disabled on nodes:

VIP exists: network number 1, hosting node testrac1

VIP Name: testrac1-vip.subnet09212030.vcn09212030.oraclevcn.com

VIP IPv4 Address: 10.0.0.36

VIP IPv6 Address:

VIP is enabled.

VIP is individually enabled on nodes:

VIP is individually disabled on nodes:

VIP exists: network number 1, hosting node testrac2

VIP Name: testrac2-vip.subnet09212030.vcn09212030.oraclevcn.com

VIP IPv4 Address: 10.0.0.178

VIP IPv6 Address:

VIP is enabled.

VIP is individually enabled on nodes:

VIP is individually disabled on nodes:

ONS exists: Local port 6100, remote port 6200, EM port 2016, Uses SSL true

ONS is enabled

ONS is individually enabled on nodes:

ONS is individually disabled on nodes:

 

You should see VIPs and SCAN listeners running fine.


7. Troubleshooting Tips

  • If SCAN listeners aren’t working, check:
    • DNS settings (or /etc/hosts)
    • Firewall rules blocking SCAN IPs
    • Network interface binding issues
  • If VIP fails to start:
    • Ensure the VIP is in the correct subnet.
    • Check the public network card configuration.

 

April 27, 2025

ocrcheck commands in Oracle RAC 19c

 

ocrcheck commands in Oracle RAC 19c

 

In Oracle RAC (Real Application Clusters), ocrcheck is a command-line utility used to check the status of Oracle Cluster Registry (OCR) in a cluster environment. The OCR stores important configuration data for Oracle Clusterware, such as cluster node information, voting disk locations, and other configuration details.

Check OCR Status: To check the status of the OCR and verify its integrity, use the following command:

[root@testrac1 ~]# cd /u01/app/19.0.0.0/grid/bin/

[root@testrac1 bin]# ./ocrcheck

Status of Oracle Cluster Registry is as follows :

         Version                  :          4

         Total space (kbytes)     :     901284

         Used space (kbytes)      :      84572

         Available space (kbytes) :     816712

         ID                       : 2059301600

         Device/File Name         :      +DATA

                                    Device/File integrity check succeeded

 

                                    Device/File not configured

 

                                    Device/File not configured

 

                                    Device/File not configured

 

                                    Device/File not configured

 

         Cluster registry integrity check succeeded

 

         Logical corruption check succeeded

 

To check the local OCR copy on the node where you run the command.

[root@testrac1 bin]# ./ocrcheck -local

Status of Oracle Local Registry is as follows :

         Version                  :          4

         Total space (kbytes)     :     491684

         Used space (kbytes)      :      83324

         Available space (kbytes) :     408360

         ID                       : 1502315622

         Device/File Name         : /u01/app/grid/crsdata/testrac1/olr/testrac1_19.olr

                                    Device/File integrity check succeeded

 

         Local registry integrity check succeeded

 

         Logical corruption check succeeded

 

 

Check OCR Configuration: If you need more detailed information about the OCR configuration, including its location, you can use:

[root@testrac1 bin]# ./ocrcheck -config

Oracle Cluster Registry configuration is :

         Device/File Name         :      +DATA

 

Check OCR local location

[root@testrac1 bin]# ./ocrcheck -local -config

Oracle Local Registry configuration is :

         Device/File Name         : /u01/app/grid/crsdata/testrac1/olr/testrac1_19.olr

 

 

Oracle Database 26ai Installation Using RPM on Oracle Linux 9 (OEL 9) – Step-by-Step Guide

  In this post I will describe the installation of Oracle Database 26ai 64-bit on Oracle Linux 9 (OL8) 64-bit. The installation requires a m...