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:

1. The Grid Infra structure software is being installed under /opt/oracle/crs/product//crs
2. 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:

After apply psu for gi :oracle@nlmysrvr/opt []# ls -al

total 101

drwxrwxr-x 19 root   root   4096 Nov 13  2013 .

drwxr-xr-x 28 root   root   4096 May 26 09:52 ..

drwxr-xr-x  3 root   root   4096 Nov 13  2013 bmc

drwxr-xr-x  4 root   hpsmh  4096 Apr  5  2012 compaq

drwxr-xr-x  5 oracle dba    4096 May  3  2012 crs

drwxr-xr-x  3 root   root   4096 Apr 12  2012 emc

lrwxrwxrwx  1 root   root     13 Apr  5  2012 eRunbook -> /opt/novaInfo

drwxr-xr-x 13 root   hpsmh  4096 Apr  5  2012 hp

drwx——  2 root   root  16384 Apr  5  2012 lost+found

drwxr-xr-x  3 root   root   4096 Apr  5  2012 lsi

drwxr-xr-x  9 root   root   1024 Dec 13  2012 networker

drwxr-x—  7 root   root   4096 Apr  5  2012 novaInfo

drwxrwxr-x  6 root   root   4096 Dec  4  2012 nsr

drwxr-x— 33 root   dba   12288 Jun 12 13:22 oracle

drwxr-xr-x  3 root   root   4096 May  3  2012 ORCLfmap

dr-xr-xr-x 25 bin    bin    4096 Jul 10  2013 OV

dr-xr-xr-x 14 bin    bin    4096 Dec 11  2012 perf

drwxr-xr-x  4 root   root   4096 Sep 12  2012 SAN

drwxr-xr-x  5 root   root   4096 Jul 20  2012 semo

drwxr-xr-x  9 root   root   4096 Jul 10  2012 SP

## During my next ssh log in i noticed this:

ssh nlmysrvr

Last login: Thu Jun 12 13:22:15 2014 from homeServer.domain

/usr/bin/xauth:  timeout in locking authority file /opt/oracle/.Xauthority

 

Logins took a long time ..

##

Solution:

As root

chown oracle:dba oracle again on the /opt/oracle directory.

 

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

1. Set up  a new standard in which the User Oracle when logging in would start in a directory like /home/oracle.
2. Set up a Software tree  for the Rdbms Admin  in an ORACLE_BASE  ( so in our case /opt/oracle would be acceptable).
3. 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 .

 

Happy reading and till we meet again in next blog.

 

Mathijs