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.
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:
After apply psu for gi :oracle@nlmysrvr/opt # ls -al
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:
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 ..
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:
- 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 .
Happy reading and till we meet again in next blog.