oratab, dbstart & dbshut

The oratab, dbstart and dbshut files don’t get much attention and to the best of my knowledge Oracle hasn’t changed them in a long time. But from what I can tell somewhere in 10g Release 1 Oracle added the ability to start and stop a listener in dbstart and dbshut. And it appears that in the 10.2.0.2.0 patch set for 10g Release 2 that Oracle has added a new “W” flag to the third field for databases in the oratab file and added ASM support for that flag in dbstart and dbshut.

Oracle added ASM support in the base release of 10g Release 1 and now in the 10.2.0.2.0 patch set for 10g Release 2 they further enhanced this support by recognizing an additional “W” flag in the third field for databases in the oratab file.

The support for listener startup and shutdown is pretty crude. Both dbstart and dbshut accept an input parameter designating the listener ORACLE_HOME. This parameter is then used to set an $ORACLE_HOME_LISTNER variable (note that is not a typo, that is how it is spelled in the script) that is used to determine if there is a tnslsnr executable in the $ORACLE_HOME_LISTNER/bin directory. If so then the version is checked to insure that it is a “Version 10 listener”. If all of this is successful then a $ORACLE_HOME_LISTNER/bin/lsnrctl start command is issued. This of course is better than nothing but probably doesn’t help sites that run multiple listeners and earlier versions.

I think the more interesting developments are with the ASM support and the changes to the oratab file. I was initially hopeful that the “W” flag would help solve some of the startup problems with ASM dependent databases. Unfortunately it is only meant for single instance databases that depend on “an ASM server that is auto-started by CRS”. It doesn’t help the site that is running ASM dependent databases and an ASM instance on a single node. In fact, there is still no good way that I have found to differentiate ASM dependent databases from non-dependent ones, if for example you ran multiple databases on a single node and not all were using ASM features.

Oracle has had code in dbstart since 10g Release 1 to handle a “delayed” startup until the ASM instance is up before starting the other databases listed in the oratab file. Now in 10.2.0.2.0 they have added code to check an ASM server to see if it is up before attempting to start any ASM dependent databases with a “W” flag in their third field. The code uses a call to the srvctl utility to determine the ASM status and waits for up to 5 minutes for the ASM service to start.

One of the byproducts of all of this is that databases with a “W” flag need to be treated as if they had a “Y” flag during environment setup. This really means that a utility needs to set the ORACLE_SID environment variable. Utilities like “orasetup” treat database entries with a “N” flag as “remote” databases and therefore set TWO_TASK rather than ORACLE_SID. This has all sorts of advantages over just setting ORACLE_SID, but it also means that the utility has to be updated. Custom startup scripts, like dbcontrol, also need to aware of what the “W” flag means so those databases are treated appropriately. Both orasetup and dbcontrol have been updated to fully support these new changes.