Search my Blog

Follow me on Twitter

Changing Directory privileges The story of the ORACLE_BASE in Psu patching with Opatch in 11.2.0.2.0

Introduction

This week i have applied psu patches both on Real Application Cluster and Oracle Restart environments and that brought me to an interesting observation again. The way we set up the environments in Linux had consequences with regard to Privileges to my directories changing. Lets go into more detail and see if reading this post is of interest to you too.

Details.

First let us take a look at the way the servers i work on are set up:

When the oracle user logs in on the Linux box his HOME ( the home of the Oracle user) is set to /opt/oracle.

Long ago ( long time before having experience with Rac environments the Company standards dictated that the ORACLE_BASE should always be the /opt/oracle. These standards are still alive for our current installations ( with or without Real Application Clusters) and that is something i have to respect and have to deal with.

When installing the Oracle software for an Oracle Rac environment two Main software trees are important:

The Grid Infra structure software is being installed under /opt/oracle/crs/product//crs

The Rdbms software is installed in /opt/oracle /product/_ee_64/db

The Grid Infra ( aka GI ) (1) has its own software tree because in that required way Root owner ship of the Software can be guaranteed during setup and while running, not impacting the normal Oracle Database software and Software use . ( after all we would not want to run all as root right ( even when that sounds tempting some times 🙂 ).

The Normal Oracle software (2) is installed in the ORACLE_BASE which is correct ( because it does not need root privileges to run) .

However installing and patching a GI environment is going to be an issue if you keep the ORACLE_BASE to /opt/oracle and it is the same as the HOME of the Oracle user since after applying psu patch to the Grid Infra i all over sudden had issues in various ways:

I spoke to Oracle consultants on this and they recommended that best practice would be:

Set up a new standard in which the User Oracle when logging in would start in a directory like /home/oracle.

Set up a Software tree for the Rdbms Admin in an ORACLE_BASE ( so in our case /opt/oracle would be acceptable).

Install the GI software in its own directory since it will run as root and it would be out of the ORACLE_BASE ( i learned would be best to unset the environment variable ORACLE_BASE).

As we all know , old habits or standards die-hard . So at moment i will settle for every scenario to unset the ORACLE_BASE variable , do my checks before , and after installation ( always keep a few sessions ope) and i would tweak the privileges were needed after applying the psu patch or after running root(upgrade).sh for the GI installation. But i would not only check :

/opt/oracle privileges after running a psu patch

would even when things look ok go into /opt/oracle/.ssh and make sure that the .. has 755 as a value .

if not the case would chown and or chmod to fix things .

As always there is never a one solution fits all purposes here . In an ideal world indeed would love to see the home of the Oracle User in /home/Oracle and have an ORACLE_BASE under /opt/oracle. But as always we don’t always live in an ideal work so it is better to be aware of possible side effects like the ones i describe here and make it part of your plans to look at the situation before and after applying patches or installing software . One of the nice quotes i came to appreciate was success just loves preparation . Make it part of plan to check things when starting to patch .