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).

?Download oracle.sh
#!/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:

?Download lsnr.sh
#!/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: , , ,

2 Responses to “RedHat Cluster custom Oracle “Agent”/script V1.0”

  1. Katriel Says:

    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

  2. admin Says:

    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!

Leave a Reply