12c Cloud Control OMS and DB startup

I’ve just been having a look into the startup order of the various 12c Cloud Control components.

On this particular environment I have Cloud Control (OMS and web tier) 12.1.0.3 together with the repository database. The database is single instance and automatic startup is controlled via a standard dbora script –

#!/bin/bash
#
# chkconfig: 35 97 10
# description: Starts and stops Oracle processes
#
# Set ORA_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstart and dbshut
#
# Set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME.
#
ORA_HOME=/u01/app/oracle/product/11.2.0.3/db_1
ORA_OWNER=oracle

case "$1" in
'start')

# Start the Oracle databases:
su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart $ORA_HOME"
touch /var/lock/subsys/dbora
;;
'stop')

# Stop the TNS Listener
#su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"

# Stop the Oracle databases:
su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut $ORA_HOME"

rm -f /var/lock/subsys/dbora

;;

esac

The OMS and webtier is started via a script which is automatically installed as part of the 12c Cloud Control installation. It is placed in /etc/init.d/gcstartup and is run via the /etc/rc.d/ scripts. Unfortunately it doesn’t support chkconfig.

The interesting thing is that the chkconfig sets the dbora script to start with order S99 –

[root@oem12c rc5.d]# ls -l *dbora
lrwxrwxrwx 1 root root 15 Feb 8 17:17 S99dbora -> ../init.d/dbora

And the gcstart script has S98 –

[root@oem12c rc5.d]# ls -l S??gcstartup
lrwxrwxrwx 1 root root 26 Feb 8 14:30 S98gcstartup -> /etc/rc.d/init.d/gcstartup

This isn’t too helpful because now OMS tries to start up before the repository database has been started, which at the very least causes it to waste a lot of time hanging and waiting.

I’ve fixed this by changing my dbora script to run at S97 by modifying the configuration in /etc/init.d/dbora as follows –

# chkconfig: 35 97 10

And then updating chkconfig –

chkconfig dbora reset

This seems to work nicely – the database will now start up before OMS tries to start, and we’re happy in the knowledge that there won’t be a period of time where the webtier is running without a backend database.

I’m interested to know whether anyone else bothers with this, or has a different solution or just leaves it all to sort itself out after the initial bootup.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: