Re: suspicious standard Oracle Linux start/stop script

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message news:<3edb5f82$0$10623$ed9e5944_at_reading.news.pipex.net>...
> "Joel Garry" <joel-garry_at_home.com> wrote in message
> news:91884734.0306011239.5e427b7f_at_posting.google.com...
> > "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message
> news:<3ed91f36$0$966$cc9e4d1f_at_news.dial.pipex.com>...
> > > How many of these refer to instance recovery rather than media recovery?
> > >
> >
> > Does it make a difference? If you need media recovery, how can you
> > avoid instance recovery?
>
> It makes a difference because I'm suggesting that I'm happy for instance
> recovery to take place. I'm not positing anything about media recovery - in
> this instance, though isn't really an area where bugs are acceptable as a
> more general point.

I'm happy when it works. But never forget, it is necessary because of the optimistic writing that is going on, Oracle is assuming that things will be committed and so writes, then worries about it later if it shouldn't have (ie, rollback). This is generally a Good Thing (TM), but can make for some complicated situations in recovery. And I mean instance recovery, when people are standing around staring at you waiting for you to get it going.

>
> > If any of them affect instance recovery,
> > then the simple act of doing a shutdown abort as opposed to shutdown
> > immediate stuffs you.
>
> I agree, however I can't see that any of them do imply this.Unless I have
> misread it 2645378+ does indeed refer to media recovery - which is why it
> gets picked up in standby. It is also somewhat esoteric in that the
> underlying bug applies only to LOBS and only seems to occur under high load.

From the bug:

"The recovery with the redo log will cause the data corruption on the LOBs."

I sorta thought you guys were all convinced I don't know the difference because media recovery is based on applying archived logs and instance recovery is based on applying redo logs. If something corrupts your redo logs,

you

are

stuffed

for

instance

recovery.

And really, your definition of esoteric collides with my definition of something some db I am responsible for might run into - after all, I'd _like_ to be on a high volume SAP db. Oracle does trumpet scalability.

>
> > There is nothing wrong with scripts doing a shutdown abort followed by
> > a bounce, _as long as there is something in there to notify someone
> > right away if it doesn't work_ and the DBA takes responsibility for
> > any problems.
>
> I' d have thought that the DBA ought to be aware of ANY shutdown of the
> database/server no?

Well, yeah! But the usual deal with a scripted abort is either someone wants cold backups in the middle of the night, or a dependable reboot. I would definitely prefer scripts to go around and identify, log and kill known things (which is how I do it), rather than just aborting. The essential problem with aborting is that you don't know what you are aborting. The fact that it might screw you is just the scary part. No matter how careful I write the kill scripts, I always wind up having to keep a record of who's on before the shutdown, because you just never know what new things will come up (which is more a management issue than a technical one). Oracle seems to think they can't advise people to learn how their OS interacts with Oracle, they think everything _should_ be done from OEM. I think that is counterproductive.

>
> > I still maintain it is extremely bad advice to tell
> > newbies that there is nothing different between shutdown abort and
> > shutdown immediate. That's just macho posturing to prove you aren't
> > afraid of Oracle's recovery mechanism.
>
> I'll accept that, since I didn't go through this whole debate when I made my
> initial quick post. There *are* differences between the two.
>
> Shutdown Abort
>
> Happens quickly, implies instance recovery on startup.

And skips the checkpoint, which is difficult to prove will mess the redo logs, since they are written before the db buffers, but I _still_ don't trust the mechanism. I've seen too much strangeness with the various v8 recoveries.

>
> Shutdown Immediate
>
> Happens slowly, doesn't imply instance recovery.
>
> In an automated script at machine shutdown I'd much rather the former, than
> risk the latter not completing. I'd also rather never reboot the db server
> if possible.

Well, yeah, I'd rather never reboot the server either, but tell that to the small mammals that always seem to find power cables tasty - and the apps that want more and more memory.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/wed/business/news_1b4qcom.html