The oratab usage comment is not correct… or it’s a bug in dbstart/dbshut (sort of)…

I’m talking about the ‘third’ field in the database entries. Field number three. Which indicates there could be a fourth, fifth etc… right?

A customer where I came (who went from AIX to Linux), who had interpreted this comment and therefore expanded the oratab with an extra column, to datapump the database (y/n).

When I shut down the databases, there was some unexpected behaviour when I invoked dbshut… Strange, but the extra (last) field ‘for datapump’ was read, not the third!

From oratab file:

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.

The entries ‘of the form’ also ends with a colon, something I did noticed before, but never used.

From the dbshut script (dbstart is similar):

# This script will shutdown all databases listed in the oratab file
# whose third field is a "Y" or "W".  If the third field is set to "Y" and
# there is no ORACLE_SID for an entry (the first field is a *),
# then this script will ignore that entry.

(...)

# To configure, update ORATAB with Instances that need to be shutdown
#    Entries are of the form:
#    $ORACLE_SID:$ORACLE_HOME:<N|Y>:

Again, the entries ‘of the form’ ends with a colon…

BUT… in the dbshut script, where the entries are looped:

# Loop for every entry in oratab file and and try to shut down
# that ORACLE
#
# Following loop shuts down 'Database Instance[s]' with 'Y' entry

  # Proceed only if last field is 'Y' or 'W'
  if [ "`echo $LINE | awk -F: '{print $NF}' -`" = "Y" ] ; then

There is this {print $NF} in awk… it means returning the LAST field (or a bit more precise: The number of fields in the current input record)! Is this where the bug is?

Should this be changed to {print $3}, the third field or should all the comments be corrected to say ‘last field’ or should we need to stay away from (mis)using the oratab…?!

The customer now is using the ‘third’ field for their ‘(datapump the db y/n)’. The last field is defaultly used to stop/start the database.

Be careful, happy shutting!

Tagged , . Bookmark the permalink.

5 Responses to The oratab usage comment is not correct… or it’s a bug in dbstart/dbshut (sort of)…

  1. Tom Bouwman says:

    Never use Oracle’s oratab file (/etc/oratab or /var/opt/oracle/oratab on Solaris) for your own purpose.
    If you need functionality like Oracle’s oratab file, please create your own!
    Add a comment like to Oracle’s oratab to keep both files consistent.

    • Ian Hoogeboom says:

      Thank you for your clear view Tom.

      “or should we need to stay away from (mis)using the oratab…?!” is your preferable choice ;)

  2. Kiwi Nick says:

    I would like to add a different issue with /etc/oratab (or /var/opt/oracle/oratab).

    Scenario: I have two databases on the machine. I auto-start one of them, by having Y in the third field. The other one has N.

    I sometimes need access to the other one for several days, so I start it manually. Someone then needs to (urgently) reboot the server, and the shutdown script executes dbshut.

    Problem: the dbshut only shuts down the auto-start database, leaving the other database to be brutally killed by machine shutdown.

    Solution: I modify my ‘dbshut’ script (like all good DBAs do, to insert “shutdown immediate”) and I get it to do another loop for all non Y|W databases. That way, all databases are shut down.

    The various scripts from Oracle are so buggy, I’ve altered oraenv, dbhome, and Oracle’s dbora (/etc/init.d/dbora) script to take account of various problems that I won’t mention here.

    To answer your question … yes I mess with the scripts, but no, I don’t mess with /etc/oratab’s format.

    • Ian Hoogeboom says:

      Thanks for sharing your thoughts!
      Yes, completely true about shutting down, but we are lucky Oracle handles instance crashes very well…
      Changing scripts, just like oraenv… it would be so great if is would just take one parameter… the SID!
      In my case, for the oratab, the ‘third’ and ‘last’ is even different on different OS-es.

  3. Ryszard says:

    Good comments.
    I’d like to add one of mine. I have more that one database version on the same UNIX box and “dbstart” “dbshut” scripts cannot handle that situation simply because you need to use versions of “shutdown” from the right database version. Running “dbshut” from oracle10 will also shutdown the oracle11 version. I had to correct this by amending the “dbshut/dbstart” scripts – the loop responsible for checking “oratab” has a flaw, so this is what I’ve done:

    OLD version:
    cat $ORATAB | while read LINE
    do

    NEW version:
    grep oracle11 $ORATAB | while read LINE
    do

    In my case I have Oracle10g installed as the UNIX user oracle10 and oracle11g installed as the UNIX user oracle11. As you see “oracle11” is hard-coded, but the scripts can filter which database version is used.
    Oracle would be wise to add another parameter to “dbshut”, although I could do it myself, but I stick to the rule “keep it simple”.

Leave a Reply

Your email address will not be published. Required fields are marked *