How to delete an RAC Database Using DBCA silent mode

During a recent Proof of Concept (POC) involving the migration of a RAC non-CDB to a CDB, I ran into a few snags that made me want to clear the slate and start fresh. To do that, I needed to completely remove the newly created RAC CDB.

While you could click through a GUI, using the Command Line Interface (CLI) is much faster and fits better into an automated workflow. Here is the process I used to identify, delete, and verify the removal of the database.

1. Assessing the Current Database State

Before running any deletion commands, it is vital to confirm exactly what is running and ensure your environment variables are pointing to the correct target.

Verifying Running Instances and Environment

First, I checked for the pmon processes to confirm the instances were active. I then loaded the environment variables for the CDB I intended to scrap.

[oracle@racnode-dc2-1 ~]$ ps -ef|grep pmon oracle 11786 1 0 16:04 ? 00:00:00 asm_pmon_+ASM1 oracle 13727 1 0 16:05 ? 00:00:00 mdb_pmon_-MGMTDB oracle 18674 1 0 17:19 ? 00:00:00 ora_pmon_hawkcdb1  [oracle@racnode-dc2-1 ~]$ . /media/patch/hawkcdb.env ORACLE_UNQNAME=hawkcdb ORACLE_SID=hawkcdb1 ORACLE_HOME=/u01/app/oracle/12.2.0.1/db1 Oracle Instance alive for sid "hawkcdb1" 

Next, I verified the cluster status using srvctl to make sure both nodes in the RAC were open and recognized.

[oracle@racnode-dc2-1 ~]$ srvctl status database -d hawkcdb -v Instance hawkcdb1 is running on node racnode-dc2-1. Instance status: Open. Instance hawkcdb2 is running on node racnode-dc2-2. Instance status: Open. 

2. Executing the Silent Deletion with DBCA

Once I was 100% sure I was targeting the right database, I used the Database Configuration Assistant (DBCA) in silent mode. This command handles the unregistration from Oracle Clusterware and the physical removal of data files in one go.

[oracle@racnode-dc2-1 ~]$ dbca -silent -deleteDatabase -sourceDB hawkcdb \ > -sysDBAUserName sys -sysDBAPassword YourPassword \ > -forceArchiveLogDeletion 

The process moves through several stages:

• Connecting to the database.
• Updating network configuration files.
• Deleting instances and datafiles.

After reaching 100%, I checked the configuration again with srvctl to ensure the resource was removed from the cluster registry.

[oracle@racnode-dc2-1 ~]$ srvctl config database hawkcdb # (No output returned, confirming the resource is gone) 

3. Post-Deletion Verification and Cleanup

Even after DBCA says it’s finished, a good DBA always double-checks the "footprints" left behind in the process monitor, the oratab file, and the ASM storage.

Checking Processes and Oratab Entries

I checked the pmon processes again to ensure the ora_pmon_hawkcdb1 process was terminated

[oracle@racnode-dc2-1 ~]$ ps -ef|grep pmon oracle 11786 1 0 16:04 ? 00:00:00 asm_pmon_+ASM1 oracle 13727 1 0 16:05 ? 00:00:00 mdb_pmon_-MGMTDB 

I also checked /etc/oratab. While DBCA usually cleans this up, it’s worth noting that manually added entries might persist even if the software removal was successful.

Confirming Removal in ASM

Finally, I hopped over to the Grid Infrastructure environment to check the ASM disk groups via asmcmd

[oracle@racnode-dc2-1 ~]$ . /media/patch/gi.env [oracle@racnode-dc2-1 ~]$ asmcmd ls DATA hawk/ hawkcdb/  [oracle@racnode-dc2-1 ~]$ asmcmd ls DATA/hawkcdb/ # (Empty output) 

As shown above, the hawkcdb directory remained, but the underlying datafiles, control files, and logs were successfully purged.

Conclusion

Using DBCA in silent mode is a quick and efficient way to tear down a RAC database, especially when you're in the middle of a POC and need to iterate rapidly. It handles the "clutter" of cluster management for you, ensuring that you don't have lingering ghost resources in your Grid Infrastructure.

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?