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