shutdown process

[David Dangerfield_1]

I have a N-Class Unix Box with an oracle database on it. When I do the shutdown -ry 0 to reboot it. It hangs and I have to do control B and then RS to restart the machine. But if I shutdown the databases manually before rebooting it will reboot fine. I look at the k100dbora and s990dbora files and they look fine. Any suggestion and also is there a shutdown log that I can look into. Thanks David

[Rui Soares]

Hi David,

Please test the shutdown of your databases with:

k100dbora stop

And then check if there are any oracle processes left. It looks like you have some oracle connection still up when shutting down Oracle.

Also, check /var/adm for shutdown.log file, it may be there (it-s configurable).

Good Luck!

Rumagoso

[Darrell Allen]

/etc/rc.log records output from the rc scripts. Upon booting, it is moved to /etc/rc.log.old and a new rc.log is created.

So after you reboot, look at /etc/rc.log.old to see the output from K100dbora. It will also contain output from S990dbora from the previous system boot.

Sounds like there's something wrong in the K100dbora script. Can you successfully run it manually?

By the way, I assume you have a typo in your post and that your rc scripts actually start with "S" and "K".

Darrell

[S.K. Chan]

Two files came to mind..
1)/etc/rc.log
2)/etc/shutdownlog
I know 2 will simply show the timestamp and command used to shutdown system but no details of the shutdown scripts in here. 1 on the other hand is for during startup log. When you shutdown the DB manually did you use the script that you put in /sbin/init.d ? It would help if you can post the "oracle shutdown" script here for someone to look at.

[Helen French]

Hi,

Which 'rc' level are you using for shutting down the oracle ? The order in which oracle shuts down can be a problem here. While shutting down oracle with the rc script, it may be looking for some resources/processes which has been already stopped.

You can check two log files - /etc/shutdownlog and for rc scripts - /etc/rc.log

HTH,
Shiju

[Craig Rants]

How does the K100ora script tell oracle to shutdown?

shutdown abort, shutdown immediate, ...

That may be the reason you database is hanging the shutdown proceedure.

Just my guess,
C

[David Dangerfield_1]

The level for k100dbora is rc0.d and the level for s990dbora is rc2.d.

Also they both K100 & s990 looks exactly alike.

[Mark Vollmers]

David-

the startup and kill should be at the same level. By the time it gets down to rc0, there's not much left running. Try copying the kill script into rc2.d, comment out (or backup and remove) the one in rc0.d, and give it a go.

Mark

[Darrell Allen]

Hi again,

Is the system default run level 3? If so, I'd put the "S"tart script in rc3.d and the "K"ill script in rc2.d. I don't know what Oracle relies on but I'd still think it best to start my databases as one of the last things I do when booting and stop them first when shutting down. Just my opinion.

Hate to ask again, but your rc scripts do start with capital K and S, right?

Did you see in /etc/rc.log or /etc/rc.log.old if the scripts ran? Any help from that output?

Darrell

[Roger Baptiste]

hi,

the S and K files are links to the /sbin/init.d/oracle file. (it may be another name in your system). To make sure this file is ok, try running it manually:

/sbin/init.d/oracle stop
-> When this is running, check your oracle log files to see whether the database is going down correctly. (tail -f on the file).

if this does not work, then there is a problem with the file. Edit it and make sure the sequence of steps under STOP of the case statement is correct.

Also, try the start :
/sbin/init.d/oracle start
If this works and stop does not work, make sure the stop sequence is correct.

If the oracle file is ok, make sure the links to S and K are correct and in order.

The /etc/rc.log.old file holds the info on shutdown sequence, since the file gets renamed on every reboot. But, it will only give you information on whether the script failed or was successful. For details, you would need to dig into the oracle log files.


HTH
raj

[David Dangerfield_1]

Both are upper case K and S.
It does fine when starting the database. Only when shutting it down. If I log in with Oracle user and cd \sql and do db_stop_all.sh the databases shut down fine. The file the the K and S links to looks ok to me. Our DBA is looking at it. I will attach the K100dbora to this and then attach S990 to another reply if anyone wants to check it out.

Thanks for everyone help
David

[David Dangerfield_1]

Attached is the S990dbora file

[James R. Ferguson]

Hi David:

You should shutdown the Oracle Listener *before* you shutdown the database. Stated differently, shutdown should occur in the opposite sequence from startup.

Craig's point of using a shutdown "immediate" is quite germane as is Darrell's guide to placing the startup script at rc3 and the shutdown (kill) script at a *lower* level.

By way of the guidelines for constructing startup and shutdown scripts, If you haven't, read either version of the document below. I???ll summarize the key points here.

/usr/share/doc/start_up.txt

http://docs.hp.com/hpux/onlinedocs/os/startup.html

The file /sbin/init.d/template is a good starting place for making your own start/stop scripts.

The /sbin/init.d directory contains all scripts used to startup and shutdown various subsystems.

Each script under /sbin/init.d should perform BOTH the startup and shutdown functions. In order to control the functionality within the script, each must also support standard arguments and exit codes. Scripts must be written for the POSIX shell. A template script may be found in /sbin/init.d/template.

There is no reason why the startup and shutdown script cannot start/kill multiple, but related processes. Remember to choose the appropriate rc.d directory -- one (1) is for core services; two (2) is for multiuser run-state; three (3) is for networked, multi-user; and four (4) is for graphical interfaces. Depending on the processes you are starting, or stopping, you want to make sure prerequisite services exist.

Each script in /sbin/init.d performs BOTH the startup and shutdown functions, and each will have two links pointing towards the script from /sbin/rc*.d: one for the start action and one for the stop action.

Start scripts begin with "S"; Kill (stop) scripts begin with "K". The order of execution for kill scripts is the reverse of the startup ones.

if a start script is placed in directory '/sbin/rc{X}.d' then its corresponding kill script is put in directory '/sbin/rc{X-1}.d'

A general rule-of-thumb is that the sequence number of the start script plus the sequence number of the kill script should add to 1000.

Subsystems should be killed in the opposite order they were started. This implies that kill scripts will generally not have the same numbers as their start script counterparts. If two subsystems must be started in a given order due to dependencies (e.g., S200sys1 followed by S300uses_sys1), the counterparts to these scripts must be numbered so that the subsystems are stopped in the opposite order in which they were started (e.g., K700uses_sys1 followed by K800sys1). The '1000' rule leads to this behavior.

Regards!

...JRF...

[Tom Danzig]

I believe the Oracle supplied dbshut script does a "shutdown normal" on all DB's listed in the /etc/oratab. If necessary, you could modify (or roll your own scripts like we do) to do a "shutdown immediate" (or shutdown abort).

IMO, database should be shudown prior to rebooting the server so the shutdown can be monitored and confirmed. The script we have in place does a "shutdown abort" on any DB's left up only in case someone forgets.

Normal shutdowns (and even immediate shutdowns) can hang for quite a while sometimes if large transactions need to finish or rollback.

[Ulf Lipski]

Sorry, but this is a common problem for shutting down a database. The normal shutdown will wait for all sessions to complete. In this case all transactions are finished, the
database is clean. If any oracle process is still alive the shutdown of the db will not proceed and will wait forever. To avoid this the usual way is todo a shutdown immediate.