Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: suspicious standard Oracle Linux start/stop script

Re: suspicious standard Oracle Linux start/stop script

From: Brian Peasland <oracle_dba_at_remove_spam.peasland.com>
Date: Thu, 29 May 2003 19:46:04 GMT
Message-ID: <3ED6637C.ECA8AE1@remove_spam.peasland.com>


> What I'm saying (and you can't argue it) - you can't predict everything.

I'm not saying that you can predict everything. But does this mean that you don't script *anything* because of a one-in-a-million chance that *something* could go wrong? Or can you predict every possibility and code your script to handle that? I'm not talking about just shutdown/startup scripts. What about scripts to do some maintenance or reorganization?......

> And if something unpredicted happens, such sqlplus can't be started for some
> odd reason (someone has changed env for example), what will your script do
> then? Terminate, to allow shutdown to proceed? Or just hang there?

In the case of shutting down the server, if SQL*Plus can't start for some odd reason that is very unlikely to happen, then I guess my instance will just crash and have the equivalent of an instance failure. But that's not the end of the world and it's really not that much different than a SHUTDOWN ABORT. In any case, the instance will come up just fine when the server is booted up.

> Do whatever you want at home or in your test environment, but in production
> you should have so rare reboots anyway, that you can afford doing that one
> extra step to manually shut down db *and deal with any unexpected
> conditions*.

Reboots are rare in production. And they are almost always scheduled. But why do I have to be involved? Maybe I just work with good SysAdmins. But in our shop, when our SysAdmin needs to reboot the server, I don't have to be there. If there is a problem (which is very rare), then I'll deal with that "unexpected condition" at that time.

> A lot of people (including me) won't put db start up scripts to init.d,
> because in case of crash for example *you* want to be in control, not some
> script which is designed only for certain circumstances.

And I know a lot of people (not including you) who do put startup/shutdown scripts in init.d. And this saves us headaches. We run a 24x7 shop. When our SysOps have to power down the computer room in the middle of the night due to a power outage that the UPS won't handle, I don't need them to call me just to shutdown the database. And, I don't need them to call me a few hours later when the power returns just to start up the database. In our situation, they shutdown the server, wait for the power to return, and then boot the server. The database comes right up without anyone's intervention. In a properly configured environment, this works almost every time. Why should I be called in the middle of the night when the task can be automated for me? It only adds to downtime if I don't have these scripts, something my SLA won't like. If you worry about every little possibility that could go wrong, then you'd need to have a DBA on-site 24x7 just to handle every eventuality. Either that, or you'd get no sleep.

Automate and start living I say!!!!!

Cheers,
Brian

-- 
===================================================================

Brian Peasland
oracle_dba_at_remove_spam.peasland.com

Remove the "remove_spam" from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"
Received on Thu May 29 2003 - 14:46:04 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US