Operating System - HP-UX
1752574 Members
4946 Online
108788 Solutions
New Discussion юеВ

Re: question on database start/stop run levels...

 
James Ellis_1
Super Advisor

question on database start/stop run levels...

While looking through the database forum, I noticed that one poster mentions his db startup is at run level 3 (rc3.d) and shutdown is at run level 0 (rc0.d).

I know this is subjective, on what run level the db needs to be shutdown. I have had both oracle shutdown and startup script linked to run level 2 (rc2.d).

I've also seen others have the database startup on run level 3 and shutdown on run level 2.

My question, what is the best practice to link the oracle startup and shutdown scripts to what run level? Is there a common standard? I am asking this because I don't know what the database admin's perspective is on this, and many don't know what a run level is!

Thanks for your inputs...
"In the middle of difficulty lies opportunity" -Einstein
15 REPLIES 15
Pete Randall
Outstanding Contributor

Re: question on database start/stop run levels...

Common practice is to stop your application one run level lower than where it's started. Run level 3 is multi-user mode, where the machine is truly up and available to users. That's where the DB should be started. If you stick to common practice, then, the DB should be stopped in run level 2, though I'm not sure it really makes all that much difference.


Pete

Pete
Ross Zubritski
Trusted Contributor

Re: question on database start/stop run levels...

Hi,

My opinion is that you should startup/shutdown at the same run-level, preferably run level 3.

Regards,

RZ
James R. Ferguson
Acclaimed Contributor

Re: question on database start/stop run levels...

Hi James:

The essential requirements for using the run-control ('sbin/rc?.d/') directory paradigm are that that start scripts begin with "S"; and 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.

Generally databases are started at runlevel 3 (or 4) and stopped at runlevel 2 (or 3, respectively), therby observing the above conventions. The important thing is that any other requisite services are available. Level 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.

Regards!

...JRF...
S.K. Chan
Honored Contributor

Re: question on database start/stop run levels...

You're absolutely right, it can be subjective. If you look at all the run levels closely ..
0=halted mode
S=single user mode
1=minimal OS
2=multi user mode
3=NFS starts (FS exported)
4=VUE/CDE
.. the DB can be started anywhere between run level 2 to run level 4. I know one thing that's a common practise or standard .. that is .. if you start your script at run level3 (the last one to startup in this level), then to stop it , it's usually done at run level2 (ie the first one to be stopped in this level). So when you said you had both startup/shutdown script in level2 that's a bit unusually, though it works.
Patrick Wallek
Honored Contributor

Re: question on database start/stop run levels...

The preferred, and fairly standard, practice is that if your start script runs at run-level X then your shutdown script shoud run at run-level X-1. So if you start at run-level 3 then shutdown would be at run-level 2.

Have a look at the doc /usr/share/doc/start_up.txt
Massimo Bianchi
Honored Contributor

Re: question on database start/stop run levels...

Hi,
usually i use this rule of thumb: if a service is started in runlevel x then it is closed in runlevel x-1.

With regards to oracle: i would keep level 3 for starting and level 2 for stopping, because at this level all required functionality is at its place..

Massimo
John Meissner
Esteemed Contributor

Re: question on database start/stop run levels...

I start and stop all my applications at run level 3.
The only thing you need to look at is where in run level 3 you're starting/stopping it. I start the application after network is started and usually kill it before network goes down. This is just the practice that we're using at my work. I'm sure everyone has a different opinion. Some applications may even make recommendations as to when they should start or shutdown.
All paths lead to destiny
Vicente Sanchez_3
Respected Contributor

Re: question on database start/stop run levels...

Hello,

I start Oracle at last to be sure that all system proceses are started and stop Oracle the first.

Regards, Vicente.
Steven E. Protter
Exalted Contributor

Re: question on database start/stop run levels...

Database shutdown should be done while the machine is in mulituser mode.

In production, the database starts on run level 3 and is killed at run level 2.

If I am diagnosing some sort of start/stop problem with the database or other application, I set it up to start run level 5 and stop run level 4(I change the /etc/inittab settings depending on the situation).

Under that diagnostic mode, as root I can start and stop the database without knowing the database password or su - oracle because I have to know enough passwords anyway. The best part is no other applications get bothered if the problem is on a production box.

Just an opinion of course but production run level 3 stop level 2. I'm sure that you'll probably get a clean stop at run level 1 but am unwilling to test that scenario.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com