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: SQL Statement Shutdown

Re: SQL Statement Shutdown

From: Joel Garry <joel-garry_at_home.com>
Date: 6 Mar 2003 17:04:35 -0800
Message-ID: <91884734.0303061704.58888d29@posting.google.com>


"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<pan.2003.03.05.11.09.53.139306_at_yahoo.com.au>...
> On Tue, 04 Mar 2003 16:27:19 +0000, Joel Garry wrote:
>
>
>
> > And you are saying that is somehow different than a manual recovery?
>
> Of course it's bloody well different! The user does nothing but issue the
> startup command.
>
> > Yes, the SMON recovery is fairly, no, _very_ stable on it's own, but
> > external influences such as it happening to take a _very long time_ it
> > some cases can really confuse people into doing the wrong thing.
>
> You're talking about people again. I'm not. I've seen a startup after a
> shutdown abort take 6 and a half hours. Did I get in there and start
> thinking that maybe Oracle wasn't up to the task and start buggering
> around with it? No.

So what was the reference to backed up files about? Once you say that you've brought in the manual issue.

>
> I'll say it one more time: if your database is run by complete idiots,
> then even a select statement is dangerous. Assuming it is run by
> reasonably competent people with something between their ears called a
> brain, then shutdown abort is no more inherently dangerous than shutdown
> immediate.

man ipcrm.

>
> >And
> > sometimes it can fall within the definition of "not work."
>
> So you're telling me you've had an instance recovery not work? Makes you
> one in a million Joel.

You Betcha!

>
> >
> > So what would you recommend? (What I think is dodgy isn't Oracle's
> > instance recovery mechanism, but rather all the manual tasks involved
> > in other recovery
>
> Well, then please stop trying to correct my posts!!! I wasn't talking
> about "other recovery". I was talking about instance recovery occasioned
> by shutdown aborts. If you have your own agenda, please do it in another
> thread somewhere.

Stop trying to straw-man.

>
> If Oracle's instance recovery mechanism is not dodgy, then there's nothing
> wrong with a shutdown abort. End of story.
>
> - and doing abort as a habit may lead to the other
> > recovery.)
>
> There you go again. Clearly, in all your vast experience, you have only
> ever seen Oracle databases managed by SQL Server DBAs.
>
> And my point is that even they would have to go some to stuff up a
> shutdown abort.

That's where you are wrong. Oracle can and has stuffed things up on it's own.

>
> >
> >>
> >> > You've never seen a site
> >> > where they do shutdown abort because they don't understand what is
> >> > preventing the instance from shutting down immediate?
> >>
> >> I'm not responsible for people's ignorance. If they choose to kill things
> >> off, there are plenty worse ways of doing it (kill -9 anyone?). I'm not
> >
> > If you are giving advice, you are taking some responsibility.
> > Actually I think that is a very good thing, and your advice is
> > normally excellent.
> >
>
> I have no idea what you're getting at. My advice is: use shutdown abort
> when appropriate, because it's no more dangerous than a shutdown
> immediate. I stand by that advice. I presume that my audience knows that a
> shutdown abort followed by the loss of the current redo log means data
> loss. I presume that my audience knows that having issued one command (ie
> startup) they don't necessarily get impatient and start fucking around
> doing stupid things because they want it to work faster. I presume I am
> not talking to an audience of carrots, leeks, parsnips and other assorted
> vegetables.
>
> Those aren't particularly demanding assumptions.

I think they actually _are_ pretty demanding. This is a public forum, and you don't know what young pups are reading it. You've never seen a post where someone doesn't know what a redo log is? And what is "appropriate?"

>
> > So why is kill -9 worse than abort? Guess you haven't seen defunct
> > processes that ignore kill -9.
>
> Red Herring alert. Translation "Howard hasn't seen anything" (Rebuttal:
> Joel doesn't know what I've seen).

Not a red herring. I've seen situations where a dblink from another platform hit the OOB bug, causing defunct processes that won't allow the abort to release shared memory, happily talking to themselves in memory and ignoring all pleas to stop (hmmm, sounds like usenet), requiring a system reboot to remove.

Of course, I've also seen zombies survive a reboot, but that was a non-Oracle system, so it would be a red herring (actually was a Centronics controller issue).

>
> >
> > There is a functional difference, and that is whether recovery has to
> > take place.
>
> No. I've defined what I mean by functional difference: commiteds are safe,
> uncommitteds are lost. They are functionally identical.

If your instance isn't coming up, do you have your commiteds?

>
> >If a very large transaction was in process you may have
> > issues.
>
> Bollocks.
>
> >If someone has taken tablespaces off and online you may have
> > issues.
>
> Bollocks.
>
> >If you intend to take a cold backup you may have issues,
> > perhaps in the future at the worst possible time.
>
> Bollocks.
>
> >I haven't thought
> > it through, but I suspect temp tablespaces could cause issues.
>
> Bollocks.
>
> There are zero issues with instance recovery. If it wasn't reliable and
> robust, Oracle wouldn't be in business. If you have issues with any of the
> above, you need to migrate to Access.

You are just plain nuts.

>
> >I have
> > vague memories of distributed issues. You are setting yourself up for
> > problems if you don't take any of this into account, and doing
> > willy-nilly shutdown abort flips over from being an innocent quirk to
> > a nasty habit.
>
> I didn't say, and I have quite categorically stated Not-To, shutdown abort
> "willy-nilly". What I took issue with was the statement that it was
> somehow "dangerous" or that it should only be used in an "emergency". As
> ever, straw men.
>
> > Apparently, you've never seen the situation.
>
> (Translation: "Howard hasn't seen anything". Rebuttal: Joel is talking
> crap and in any cse doesn't know what I've seen).
>
> > So what is the difference between yanking the plug and shutdown abort?
>
> Absolutely nothing. So are you saying that yanking the plug causes Oracle
> to lose committed data? It doesn't.
>
> > No, I'm not targetting you specifically, sorry you feel that way, I
> > can perhaps understand why you do. This is usenet, it is carved in
> > stone for the Universe.
>
> Your posts speak for themselves. You throw red herrings around like you
> have a trawler. Little non sequiteurs such as "Apparently, you've never
> seen the situation" give your game away. You've given no facts,
> Joel, but plenty of bile. Shutdown abort is not "dangerous": end of story.
> Prove it otherwise. Do me a demo that shows the loss of committed data
> using shutdown abort that doesn't involve also deleting your current redo
> log. I'll bet you a potatoe and parsnip you can't do it.

Since I've already seen it, I won't bother. It's difficult to reliably replicate such problems, since they are so often dynamic in nature, and in a production environment you are more worried about getting things working than in doing Oracle's QA work. Some articles on metalink come close to admitting these things happen. But the support people necessarily have to shield developers from problems that are difficult to replicate. That does not mean they do not exist, it may not mean the developers don't know about them. It means when software gets to a certain level of complexity, anomalies happen.

However, if you want to learn something rather than just do a bunch of hairy chest beating, get yourself an hp-ux 9.0 box running 7.3.4 and a Solaris box running 8.x, dblink the 8 to the 7 without the OOB fix in sqlnet.ora, and run a script to bounce the 7 repeatedly while another script on the Solaris box repeatedly attempts to log in. Off the top of my head, YMMV. Of course, that's not an "Oracle error" according to Oracle. It just makes things happen that you say don't happen. And don't give me that "current software" grief, if you've never seen a bug reintroduced in a patch, you haven't been paying attention.

>
> > Isn't SMON just automatically doing a subset of restoration?
> >
>
> What THE HELL is a "subset of restoration"?????? Either the f'ing database
> is restored or it isn't. And yes, as I posted originally, SMON does the
> *entire* recovery after an instance failure or a shutdown abort. Not a
> bleeedin' subset, whatever that may be.

That would be the stuff it does automatically, as opposed to all the other stuff that is implied by having to have backed up files.

>
> Now: either post some facts or figures, or please just stop it. Give me
> dates, and spool files that show a shutdown abort being "dangerous".

How the hell do you expect a spool file from a locked up db?

>
> Otherwise, get of the old yawn about what I might or might not have seen,
> because you haven't got a clue about either. Start talking facts, and I'll
> start listening. But you're talking crap right at the moment.

Just the same crap that Oracle has given me.

jg

--
@home.com is bogus.
Oracle is the worst software ever devised by man, except for most all
the others.
Received on Thu Mar 06 2003 - 19:04:35 CST

Original text of this message

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