RedHat Cluster custom Oracle “Agent”/script V1.0
Working with RH Cluster quite a lot, I have decided to create an online store of customer agents/scripts.
I have not, so far, invested the effort of making these agents accept settings from the cluster.conf file, but this might happen.
Let the library be!
Oracle DB script/agent:
Although I discovered (a bit late) that RH Cluster for Oracle Ent. Linux 5.2 does include oracle DB agent, this script should be good enough for RHEL4 RH Cluster versions as well.
This script only checks that the ’smon’ process is up. Nothing fancy. This script can include, in the future, the ability to check that Oracle responses to SQL queries (meaning – actually working).
#!/bin/bash #Service script for Oracle DB under RH Cluster #Written by Ez-Aton #http://run.tournament.org.il # Global variables ORACLE_USER=oracle HOMEDIR=/home/$ORACLE_USER OVERRIDE_FILE=/var/tmp/oracle_override REC_LIST="user@domain.com" function override () { if [ -f $OVERRIDE_FILE ] then exit 0 fi } function start () { su - $ORACLE_USER -c ". $HOMEDIR/.bash_profile ; sqlplus / as sysdba << EOF startup EOF " status } function stop () { su - $ORACLE_USER -c ". $HOMEDIR/.bash_profile ; sqlplus / as sysdba << EOF shutdown immediate EOF " status && return 1 || return 0 } function status () { ps -afu $ORACLE_USER | grep -v grep | grep smon return $? } function notify () { mail -s "$1 oracle on `hostname`" $REC_LIST < /dev/null } override case "$1" in start) start notify $1 ;; stop) stop # notify $1 ;; status) status ;; *) echo "Usage: $0 start|stop|status" ;; esac |
I usually place this script (with execution permissions, of course) in /usr/local/sbin and call it as a “script” from the cluster configuration. You will probably be required to alter the first few variable lines to match to your environment.
Listener Agent/script:
The tnslsnr should be started/stopped as well, if we want the $ORACLE_HOME to migrate as well. This is its agent/script:
#!/bin/bash #Service script for Oracle DB under RH Cluster #Written by Ez-Aton #http://run.tournament.org.il ORACLE_USER=oracle HOMEDIR=/home/$ORACLE_USER OVERRIDE_FILE=/var/tmp/oracle_override function override () { if [ -f $OVERRIDE_FILE ] then exit 0 fi } function start () { su - $ORACLE_USER -c ". $HOMEDIR/.bash_profile ; lsnrctl start" status } function stop () { su - $ORACLE_USER -c ". $HOMEDIR/.bash_profile ; lsnrctl stop" status && return 1 || return 0 } function status () { su - $ORACLE_USER -c ". $HOMEDIR/.bash_profile ; lsnrctl status" } override case "$1" in start) start ;; stop) stop ;; status) status ;; *) echo "Usage: $0 start|stop|status" ;; esac |
Again – place it in /usr/local/sbin and call it from the cluster configuration file as type “script”.
I will add more agents and more resources for RedHat Cluster in the future.
Protect Vmware guest under RedHat Cluster...Tips and tricks for Redhat Cluster...
Related posts brought to you by Yet Another Related Posts Plugin.
Tags: listener, oracle db, redhat, RedHat Cluster
April 24th, 2009 at 2:42 pm
Nice.
Of course, I have some comments on the scripts:
1. You shouldn’t need “source .bash_profile” if you’re using su –
2. You could use RH’s “action” and “daemon” functions (sourced from /etc/init.d/functions) to use $ORACLE_HOME/bin/dbstart.sh/dbshut.sh for starting oracle/listener in one shot. Plus, you’ll get nice [OK]/[Failed] statuses.
+Katriel
April 24th, 2009 at 6:57 pm
Hi Katriel.
Nice to see you’re reading my blog. I am honored.
About your comments:
1. Although you are probably right, I remembered an issue with ’su -’ on Suse Linux and profile files, so I kept it in. It should cause no harm.
2. functions change with different versions. Under RHEL4 it was not LSB compatible (WONTFIX in their bugzilla), which causes RHCS to do weird things (stop-after-stop issues, etc). Using dbstart and dbshut could be a good idea, however, I don’t completely trust their exit codes. I need to verify its behavior (when the DB can’t start, when the DB is already started, etc) before I include that. This is, still, a very good idea. Still – I will need to monitor the listener myself.
On my next cluster (in a few days, I assume), I will incorporate and test your suggestions.
Thanks!