Oracle 10G startup problems - dbstart

When oracle doesn't want to start or simply doesn't start at all, here are some things that work for me:

Check $ORACLE_HOME/bin/dbstart -- can you start it manually and everything go smoothly?
Check $ORACLE_HOME/startup.log -- did something bomb?
Check /etc/oratab -- are your desired databases flagged with Y to indicate your interest in starting them?

There is a bug/QA opportunity in Oracle 10.2g Linux in $ORACLE_HOME/bin/dbstart. Evidentally a developer left a hardcoded path for the LISTNER (also spelled wrong) variable around line 78. The path in place is /ade/vikrkuma or something to that effect. Make sure this is replaced with $ORACLE_HOME for the entire path.

Out of the box, Oracle does not provide an auto startup script to automatically bring Oracle up. There are several examples on the internet to create an init.d script. The goal is to make sure you build an ability to run $ORACLE_HOME/bin/dbstart for your database. If you have multiple instanaces, your script has to be smart enough to declare its environment variables as user ORACLE prior to running the dbstart script. I generally wrote a single shell script for each startup process and an init.d script to call each one individually. Made for alot cleaner init.d script.

Also check running processes for your oracle instance. Run cd $ORACLE_HOME and then type "pwd" to see what directory you're in. Your directory should have a unique name at some point (some structures are like /oracle/product/10.2.0/db10gR2). In this case, I would use db10gR2 as my unique name. Take this name and grep it from the running process output to see if anything at all ran. ( ps ax | grep db10gR2 ) If you have any processes running but do not have tnslsnr, you likely cannot connect to your database. I would recommend running a $ORACLE_HOME/bin/dbshut and closing everything out. Check your oratab file to make sure you have the necessary databases flagged to start, and try again. Also, your oratab should list ASM instances prior to databases since the databases rely on ASM!