Clone Oracle Database Home

Cloning Oracle RAC Database Home to Single Instance and vice versa

In this blog post, I will provide the detailed steps for cloning an Oracle Database Home (Oracle Database Software) from an already running Oracle Home to another database server. This approach is commonly used to standardize environments, deploy identical patch levels, and significantly reduce installation time. It applies to both Oracle RAC Database Homes and Single Instance Database Homes. You may ask why we need to do this instead of simply creating a brand-new Oracle Database Home.

The answer is simple:

The world ain’t all sunshine and rainbows

Even though Oracle 26ai is on its way to on-premise environments, many organizations are still running dozens of old-version Oracle Homes that continue to serve critical applications. And in real life, there are solid reasons for cloning instead of reinstalling. Some of the most common scenarios are:

  • You can’t find the installation setups anymore for your specific PSUs or one-off patches. They may have been archived or removed from internal repositories and may be password protected on Oracle Support.
  • In ExaCC environments, you don’t have the option to provision old 12c releases through the GUI, and dbaascli cannot deploy a legacy Oracle Home either.

In my case, we had a 12c database running in a RAC environment with lots of one-off patches applied. The requirement was to create a Data Guard environment for that database , but there was no setups.

Although the required commands are quite straightforward, I could not find any clear information in the official Oracle documentation about whether it is supported to clone an Oracle Home from RAC to Single Instance or from Single Instance to RAC. Because this creates uncertainty , I decided to write a dedicated blog post to demonstrate the exact steps and considerations for both directions.

Because the 12c preinstall package is not available in the Oracle Linux 8 repository, we will proceed with the 19c preinstall package.

One important point worth mentioning is this: when you clone an already-used Oracle Database Home, you are also copying all the “mess” that accumulated over the years. This includes installation logs, audit files, network configuration files (tnsnames.ora, sqlnet.ora, listener.ora), and anything else living under that home.

For this reason, clean up the source Oracle Home as much as possible before creating the tar archive. Remove unnecessary log files, old patching logs, temporary files, backups of listener configurations, and anything else that doesn’t need to travel with you. Also consider cleaning up the .patch_storage files, you may use Opatch to clean up inactive patches. (opatch util deleteinactivepatches)

Also be extremely careful with password files under the dbs directory. These files will be copied into the new home as well, which may not be what you want.

On the source Oracle Home, create a tar file.

Create the target home directories.

If you don’t have any installed Oracle software on the target server, be careful about the central inventory location, use INVENTORY_LOCATION option, otherwise you central inventory will be /home/oracle which we will not prefer.

First, we will define the ORACLE_BASE and ORACLE_HOME variables. Additionally, if this is the first Oracle product installed on the server, we must also define INVENTORY_LOCATION. If it is not explicitly defined, Oracle will default to using /home/oracle as the central inventory location.

After the cloning process is completed, verify that the patch level of the cloned Oracle Home matches the source home.

If you encounter any issues at this stage, you should check the local inventory file (oraInst.loc under the new ORACLE_HOME) and verify that it points to the correct central inventory location. Otherwise, you may encounter the error shown below.

Now, we will validate the Oracle Home binaries to ensure that they are functioning correctly. At this stage, while invoking sqlplus, I encountered the error shown below.

Since the error was related to missing libraries, I set the LD_LIBRARY_PATH variable and checked again.

The error changed but was not resolved; relinking the Oracle Home binaries looks like a good fix.

After investigating the relink.log file and the log files located under the install directory, I identified the root cause of the error.

According to the log files, since we used the 19c preinstall package, the package dependencies for 19c and 12c are not the same. As a result, we need to install two additional RPM packages to ensure that everything works properly.

After the required packages are installed, we will run the relink command again. This time, everything works smoothly.

The steps are essentially the same and the overall process is very similar. The only difference is that the clone command flags are slightly different. In this case, we must specify the CLUSTER_NODES and LOCAL_NODE parameters. Additionally, all relevant steps must be executed on all RAC nodes.

You can use the olsnodes command under $GRID_HOME to determine the cluster nodes.

On server 1:

On server 2:

Run root.sh on both nodes.

Cloning an Oracle Database Home is a practical and reliable solution when reinstalling is not possible especially in environments running legacy Oracle versions with numerous one-off patches. As demonstrated, Oracle Home cloning works successfully in both directions: RAC to Single Instance and Single Instance to RAC, as long as inventory configuration, OS dependencies, and relinking steps are handled carefully.

Hope it helps.


Discover More from Osman DİNÇ


Comments

Leave your comment