The
$ORACLE_HOME/bin/dbshut
script shipped with Oracle
8.1.7, which is called by all the
/etc/init.d/oracle
startup/shutdown scripts I've ever seen, basically starts svrmgrl and
does a plain "shutdown", which is equivalent to
shutdown normal.
This looks clearly wrong to me. If the machine needs to go down,
(e.g., the UPS just said "Oh, no, only 1 minute of power left,
shutdown now!"), you should be giving Oracle a "shutdown immediate" so
that it rolls back all transactions, disconnects all users, and shuts
down ASAP, rather than sitting there waiting, possibly forever, until
all connected Oracle users disconnect!
Others have
reported Oracle hanging on shutdown,
sitting at the svrmgrl prompt until AOLserver is shut down.
I've seen this problem myself now on Linux (Debian 3.0). (And since
the shutdown scripts run sequentially, Oracle getting stuck also
prevented my PostgreSQL and various other stuff from shutting down as
well.)
Interestingly, I've never seen or heard of the problem on Solaris,
including at least one equivalently configured Solaris box that I use
at work. So I suspect the shutdown order of /etc/inittab stuff and
/etc/init.d shutdown scripts differs between Solaris and Linux.
C. R. Oldhan solved the problem by putting
killall -TERM nsd
into his /etc/init.d/oracle script. That sounds wise to me. Seems to
me though, that we should both make sure we kill all
AOLservers that talk to Oracle before trying to shutdown Oracle,
and we should use "shutdown immediate".
Does anyone know of any good reason not to always use
"shutdown immediate" in your Oracle shutdown scripts? How have others
solved this problem?
How does PostgreSQL behave in this respect?