Within Reason: Shell scripting for DBMS vendors

Shell scripting for DBMS vendors

Ceri Davies — Wed, 14 Jun 2006 19:52:00 +0000

I recently had cause to arrange for Oracle’s RDBMS 10g to be started at boot time. This led me to despair somewhat at the state of shell scripting in general, and I will rant a little on that subject. This isn’t really intended as an attack on this particular script, but these are the issues that arose from it.

The Oracle installation provides a couple of scripts named dbshut and dbstart that look like they’ll do that job. Indeed, the top of dbstart states:

# This script is used to start ORACLE from /etc/rc(.local).

The corresponding RCS log from the import tells a different tale:

$ svn log -r99 dbstart
Password for 'ceri': 
-------------------------------------------------------------------
r99 | ceri | 2006-06-09 15:27:33 +0100 (Fri, 09 Jun 2006) | 5 lines

Add a bunch of scripts used for looking after our databases.
Mainly culled from our live systems, with the notable exception
of the Oracle provided utilities dbshut and dbstart, which are
as out of the box here (and therefore do not work).

-------------------------------------------------------------------

"Shell scripting for DBMS vendors" by derek

Sun, 25 Jun 2006 14:37:58 +0000

dude, looks like plenty of issues with dbstart and dbshut in recent times. you're right, the scripts won't accept parameters in solaris. This is explained in metalink Note: 1019793.6 this also explains that the init.d must su - oracle -c before running the script, this assumes that shell will be defined by "oracle" account .profile methinks. theoretically, the script goes on to process the oratab but latest verions of dbstart/shut look in wrong place in solaris. it should be looking in /var/opt/oracle but instead looks in /etc/oracle so this has to be edited as it is only correct for almost every other flavour of unix. also check that the scripts are executable (natch) and your oratab file is correctly set up with a "Y" flag for the SIDs you want restarted. if no Y flag then dbstart/shut will ignore these lines also...in oracle9i version of these scripts they wouldn't work properly if the database only used an spfile.ora rather than an init.ora, again more editing was required - add the following line: SPFILE=${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora after this line: PFILE=${ORACLE_HOME}/dbs/init${ORACLE_SID}.ora - change: if [ -f $PFILE ] ; then to: if [ -f $PFILE -o -f $SPFILE ] ; then regards listener startup, this was never automatiotically a part of the older dbstart/shut scripts and always had to be added by the dba. if your system is simple and one listener per database, per ORACLE_HOME then it's easily done. if your system is complex with multiple listeners with individual listener names with passwords per database, per ORACLE_HOME, then you're in for some fun scripting.... cheers, -derek-

"Shell scripting for DBMS vendors" by Mike Jones

Thu, 15 Jun 2006 19:14:15 +0000

Instructions? Not sure what that they are ;-)

"Shell scripting for DBMS vendors" by ceri

Thu, 15 Jun 2006 19:14:15 +0000

That seems to be a common complaint, in that he has set the ORACLE_HOME_LISTNER variable to somewhere in his own home directory.

However, step 3 of the configuration instructions in the script reads:

3) Set ORACLE_HOME_LISTNER

so I don't see it as too much of a problem ;)

"Shell scripting for DBMS vendors" by Mike Jones

Thu, 15 Jun 2006 19:14:15 +0000

I've not installed Oracle since I left Cardiff so my memory might be hazy - but on 10g isn't the dbstart script broken because the developer has hard coded some directory locations on his own system. I'm sure I had to go through making changes before it would work.