SSH Equivalency Setup in Oracle Exadata – Step-by-Step Guide

Introduction

SSH equivalency is a mandatory requirement in Oracle Exadata environments. It enables passwordless SSH communication between database servers, storage servers (cells), and other Exadata components.

SSH equivalency is used during:

• Exadata deployment

• OneCommand setup

• Patching activities

• Exachk execution

• Automation scripts

• Cluster operations

This guide demonstrates how to configure SSH equivalency securely in an Oracle Exadata environment.

---

Environment Details

Example Exadata Environment:

Hostname	Type
db01	Database Server
db02	Database Server
cell01	Storage Server
cell02	Storage Server
cell03	Storage Server

User:

oracle

---

Step 1: Verify Connectivity

From db01, verify connectivity to all nodes.

ping db02
ping cell01
ping cell02
ping cell03

Expected Result:

64 bytes from db02
64 bytes from cell01

---

Step 2: Generate SSH Key

Login as oracle user.

su - oracle

Generate SSH key.

ssh-keygen -t rsa

Press Enter for all prompts.

Verify key files:

ls -ltr ~/.ssh

Expected:

id_rsa
id_rsa.pub

---

Step 3: Copy Public Key to Remote Servers

Copy public key to all target nodes.

ssh-copy-id oracle@db02

ssh-copy-id oracle@cell01

ssh-copy-id oracle@cell02

ssh-copy-id oracle@cell03

Enter password when prompted.

---

Step 4: Verify Passwordless Login

Test SSH connectivity.

ssh db02 hostname

ssh cell01 hostname

ssh cell02 hostname

ssh cell03 hostname

Expected Output:

db02
cell01
cell02
cell03

No password should be requested.

---

Step 5: Configure Reverse Connectivity

Perform the same steps from db02 to db01.

Generate keys:

ssh-keygen -t rsa

Copy keys:

ssh-copy-id oracle@db01

Validate:

ssh db01 hostname

---

Step 6: Validate SSH Equivalency

Execute the following command from each database node.

ssh db01 date

ssh db02 date

ssh cell01 date

ssh cell02 date

ssh cell03 date

All commands should execute without password prompts.

---

Step 7: Verify Authorized Keys

Check authorized_keys file.

cat ~/.ssh/authorized_keys

Ensure public keys from all participating nodes are present.

Permissions:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

chmod 600 ~/.ssh/id_rsa

---

Common Issues and Troubleshooting

Permission Denied

Error:

Permission denied (publickey)

Solution:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

---

Host Key Verification Failed

Error:

Host key verification failed

Solution:

ssh-keygen -R hostname

Reconnect:

ssh hostname

---

SSH Timeout

Verify:

ping hostname

nslookup hostname

Check firewall configuration.

---

Validation Checklist

Check	Status
SSH keys generated	✓
Public keys copied	✓
Passwordless login working	✓
Authorized keys validated	✓
Permissions verified	✓

---

Conclusion

SSH equivalency is a critical prerequisite for Oracle Exadata administration, patching, and automation activities. Properly configured passwordless SSH improves operational efficiency and reduces manual intervention during maintenance and deployment tasks.

Always validate connectivity and file permissions after configuration to avoid failures during patching and cluster operations.

Convert oracle standalone database to oracle ASM

Here is the sequence of operations to migrate an Oracle database from a file system to ASM (Automatic Storage Management) and register it with Oracle Clusterware.

1. Initial State & Failed Backup Attempt

First, the database instance is started in MOUNT mode. An initial attempt to back up the database using RMAN fails because the database is running in NOARCHIVELOG mode. An online backup cannot be performed on active datafiles in this state.

# Connect to the idle instance
[oracle@node1 dbs]$ sqlplus / as sysdba
Connected to an idle instance.

SQL> startup mount
Database mounted.

# Attempt backup using RMAN
[oracle@node1 dbs]$ rman target /
connected to target database: ORADB (DBID=2803372975, not open)

RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA';
...
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/12/2025 14:20:46
ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode
...

---

2. Enabling ARCHIVELOG Mode

To resolve the backup failure, ARCHIVELOG mode must be enabled. An initial attempt fails with error ORA-00265, indicating that instance recovery is required due to the previous unclean state. A clean shutdown and restart in MOUNT mode resolve this, allowing ARCHIVELOG and FORCE LOGGING to be successfully enabled.

# Attempt to enable archivelog mode fails
SQL> alter database archivelog;
*
ERROR at line 1:
ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

# Perform a clean shutdown and restart
SQL> shutdown immediate;
ORACLE instance shut down.

SQL> startup mount;
Database mounted.

# Successfully enable archivelog and force logging
SQL> alter database archivelog;
Database altered.

SQL> alter database force logging;
Database altered.

---

3. Successful Backup and Switch to ASM

With the database in ARCHIVELOG mode, the RMAN backup to the +DATA ASM disk group now succeeds. The BACKUP AS COPY command creates an image copy of the datafiles directly in ASM. Afterward, the SWITCH DATABASE TO COPY command updates the control file to point to these new datafile locations on ASM, effectively migrating the datafiles.

# RMAN backup to ASM

[oracle@node1 trace]$ rman target /
RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA';
Starting backup at 12-AUG-2025 14:27:48
...
output file name=+DATA/ORADB/DATAFILE/system.261.1208960879
...
Finished backup at 12-AUG-2025 14:29:15

# Switch database to use the new datafile copies in ASM
RMAN> SWITCH DATABASE TO COPY;
datafile 1 switched to datafile copy "+DATA/ORADB/DATAFILE/system.261.1208960879"
...

# Open the database
RMAN> ALTER DATABASE OPEN;
Statement processed

---

4. Relocating Redo Log Files to ASM

The final migration step is moving the online redo log files from the local file system to ASM. This is done by adding new log groups in ASM, switching log files until the old ones are no longer active, and then dropping the old log files.

-- Verify datafiles are now in ASM
SQL> SELECT name FROM V$DATAFILE;
NAME
--------------------------------------------------
+DATA/ORADB/DATAFILE/system.261.1208960879
+DATA/ORADB/DATAFILE/sysaux.262.1208960903
...

-- Add new redo log groups in the '+FRA' disk group
SQL> alter database add logfile group 4 ('+FRA/redo1.log') size 500M;
SQL> alter database add logfile group 5 ('+FRA/redo2.log') size 500M;
SQL> alter database add logfile group 6 ('+FRA/redo3.log') size 500M;

-- Switch logfiles to make old groups inactive
SQL> alter system switch logfile;

-- Drop old file system-based redo log groups
SQL> alter database drop logfile group 2;
SQL> alter database drop logfile group 3;

-- The current log group cannot be dropped immediately
SQL> alter database drop logfile group 1;
*
ERROR at line 1:
ORA-01623: log 1 is current log for instance oradb (thread 1) - cannot drop

-- Switch again to make group 1 inactive, then drop it
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> alter database drop logfile group 1; 

5. Registering and Managing with Oracle Clusterware

Finally, the database is registered with Oracle Clusterware using the srvctl utility. This allows the cluster to manage the database startup, shutdown, and monitoring.

# Add the database and instance to the Clusterware configuration
[oracle@node1 ~]$ srvctl add database -d oradb -o /u01/app/oracle/product/19.0.0/db_1
[oracle@node1 ~]$ srvctl add instance -d oradb -i oradb1 -n node1

# Start the database using srvctl
[oracle@node1 dbs]$ srvctl start database -d oradb

# Verify the status
[oracle@node1 dbs]$ srvctl status database -d oradb
Instance oradb1 is running on node node1

# Final check of the running processes
[oracle@node1 ~]$ ps -ef|grep pmon
oracle   21502     1 0 15:57 ?        00:00:00 ora_pmon_oradb