Re: SQL Statement Shutdown

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0303061704.58888d29_at_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.

Figment of your imagination, Joel. I mentioned multiplexing files. Not backing them up. Or are you saying that multiplexing things is the same as backing them up? I bet you use RAID 5 if so.

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

Feeble. You claim I recommend shutdown aborts. You claim I talked about backing things up. And you say *I* do the straw-men!

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

Right. So you don't trust Oracle to perform Instance Recoveries. so when are you migrating to DB2, Informix, Sybase or SQL Server??

On your own, out on a limb, and looking like a complete idiot. That's you.
> >
> > 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?"

Clutching at straws as ever.

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

I'm not the only one who has posted: when was the last time you didn't see an Oracle instance come up after a shutdown abort?

And as for your dblinks issue: presumably it all worked just fine and dandy if you did a shutdown immediate? Or what??

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

But not quite as ignorant nor as untruthful as you.

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

Gosh. Am I surprised, or what?

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

Blather, blather, blather, blather. Translation: I can't do what you ask, but if I type enough words, perhaps you'll forget that you've asked me for evidence.

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

What I've seen in this thread, Joel, is someone wilfully misreading my posts in order to make a personal point, and lying and prevaricating in the process.

Go and play in a sand-pit somewhere else. End of thread, and the first killfile addition I've ever made.

Plonker.
HJR Received on Fri Mar 07 2003 - 09:29:50 CST