ORA-32017: failure in updating SPFILE, followed by: ORA-65500: could not modify DB_UNIQUE_NAME, resource exists (12c)

I was working to setup a Data Guard in my test machine and noticed the following  error when I was trying to change the db_unique_name parameter in the primary database -

 SQL> alter system set db_unique_name=TESTPR scope=spfile sid='*';  
 alter system set db_unique_name=TESTPR scope=spfile  
 *  
 ERROR at line 1:  
 ORA-32017: failure in updating SPFILE  
 ORA-65500: could not modify DB_UNIQUE_NAME, resource exists  

umount: /u01: device is busy: even when Grid Infrastructure is down (12c)

Sometimes back, I noticed that even after shutting down GI (12.1.0.2.x) in a RAC setup, I still can't unmount the filesystem where the GI binaries are located.

This is applicable for GI version 12.1.0.2.x and even in Exadata too. Reproducible every time when GI shutdown completes.

How To: mount ISO image as yum repository

This post is just a quick how to reference about how to mount an ISO image contains Oracle Linux Installation Binaries and use that as a YUM repository to install/update the operating system.

How To: iLOM SNAPSHOT using CLI

Below is just an example on how to collect iLOM snapshot using CLI.

Huge number of Oracle Database Home/Binary in a single server

Sometimes, during database consolidation planning, people tends to plan to install one ORACLE_HOME (DB Home/Binary) for each database.

Which means: Lets say, if there are 50 databases then there will be 50 ORACLE_HOME. Specially it's been seen in Exadata/SuperCluster which has capacity to consolidate a very large RDBMS environment.

Question is, is it really a good idea or crazy ?? !!!!