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: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Wed, 05 Mar 2003 22:09:53 +1100
Message-Id: <pan.2003.03.05.11.09.53.139306@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.

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.

>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.

>
> 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.

If Oracle's instance recovery mechanism is not dodgy, then there's nothing wrong with a shutdown abort. End of story.

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.

>
>>
>> > 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.

> 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).

>
> 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 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.

>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.

> 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.

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".

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.

HJR Received on Wed Mar 05 2003 - 05:09:53 CST

Original text of this message

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