Re: Redo Log Question

"Burt" <burtpelt_at_bellsouth.net> wrote in message [snip]

> > > I have been doing Oracle server DBA support for about 10 years.
> > >
> >
> > Badly, by the sounds of it.
>
>
> Today has been a busy day, but I had to comment one more time...
>
> You still have an attitude problem. And, you don't consider the above
> comment an insult ?
>

No I don't. If you've been managing a database for 10 years based on the level of knowledge you've exhibited in this thread, then I fear for your database.

No: a personal insult would be saying things like 'your attitude sucks'.

You know, personal stuff. Based on no knowledge of the person concerned, but just because you happen to disagree with the person involved.

The only comments I have passed have been based on your demonstrated knowledge of a subject on which you thought yourself fit to comment.

> If in your opinion, I said 1 thing in error, then does that mean I do
> my job badly ? You have no idea.
>

You said, without qualification, that Oracle recommended X when actually it recommended Y. I pointed that out to you. You at that point had the chance to say 'my mistake, I'm sorry, thanks for the enlightenment'. But no. You decided instead to suggest that it was *my* attitude that was the problem. So no, I have no idea, except that you are someone who appears to know not very much, but will defend to the death his right to say crap.

> I don't care how much you know about Oracle, I wouldn't want to work
> with you.
>

Fair enough. I'd sack you anyway.

> Just because you aren't face-to-face, you think you can insult anyone?
> You don't sound like you work too well in this environment.
>

Strangely enough, I post with my actual email address and my own name. I have absolutely no problem taking this offline and dealing with it there.

Get over it, anyway: I didn't insult you. I said you didn't know very much about Oracle. You don't. Thems the facts. Deal with it.

> >
> > > The comment about "Oracle recommends" comes out of a white paper from
> > > Oracle or from the docs . I don't have the time to check it. But, it
> > > is there. Search Metalink and docs if you have the time.
> >
> > Please see below.
> >
> > > So, if the OS can mirror corruption, why wouldn't Oracle mirror it
> > > too? I have SEEN BOTH (how about you?) the OS AND Oracle mirror
> > > "software" corruption.
> >
> > Because with OS mirroring, you have LGWR only writing once, and then
that
> > being copied by the OS to the mirror. One write. One stuff up. One
> > corruption. Mirrored. With multiplexing, LGWR writes twice (or three
times,
> > if you do 3-way multiplexing). With two (or more) writes, it is highly
> > unlikely that LGWR would introduce the same corruption at the same point
in
> > the redo stream. Therefore, multiplexing protects you against software
> > corruption.
> >
>
>
> I lost all faith in Oracle doing the 2nd write better than the OS when
> I had to do the recover mentioned below. Maybe your experience is
> better. But, my experienced recover in version 7.3.2.3 shows that
> Oracle does/did indeed mirror software corruption that Oracle
> introduced.
>
> My first choice "with unlimited budget" would be to both multiplex and
> OS mirror.
>

That's not what you originally said, where you expressed a preference for OS mirroring, said that Oracle Corporation supported you in expressing the same, and suggested that multiplexing was an optional extra.

> Now, I cannot find that paper. I know I have a hardcopy in my office,
> but I won't be there for a couple of weeks.
>

I shan't hold my breath. I've quoted you the documentation. Anything else is likely to be irrelevant.

> But, I see now in a quick check on Metalink that there is a consensus
> that the 1st choice is multiplexing. Interesting... I know I didn't
> imagine the paper from Oracle recommending OS mirroring first.
>
> Anyway, I have had some good luck with OS mirroring and the above
> mentioned bad luck with Oracle multiplexing.
>

Luck isn't science. Good DBAing is about science.

>
>
> > >
> > > > If Junior DBA is practising his Unix skills, and issues an 'rm *'
> > command,
> > > > then the OS faithfully deletes the mirrored copy of the redo log as
well
> > as
> > > > the original. Result: a totally missing redo log group.
> > > >
> > >
> > > I don't let junior DBAs touch my systems :)
> > >
> > > BTW, did you notice my comment about "debating this one". Hmmm ,
> > > probably not.
> > >
> >
> > Yes, and you missed the point: there's nothing to debate. Oracle does
not
> > recommend OS mirroring as its first line of defence. Period.
> >
> > >
> > > > Oracle multiplexing, by contrast, protects you from both these
> > scenarios,
> > >
> > >
> > > Uhh ? Why wouldn't Oracle put the same damn corruption in both
> > > copies?
> >
> > Because, with multiplexing, LGWR has to write twice. With O/S mirroring,
it
> > writes once and then the O/S is responsible for making the copy.
> >
> > The chances of LGWR introducing corruption at exactly the same spot with
two
> > different writes is pretty small.
>
>
>
> Apparently not impossible since that IS what occurred in my experience
> noted below.
>

Of course it's not bloody impossible! What do you want? Guarantees signed in blood? The question -the REAL question- is which is MOST LIKELY to prevent a problem. A single write mirrored by the OS or multiple LGWR writes. It's a question of probabilities, and the answer isn't hard to come by.

>
>
> >
> > >It did it to me once in version 7.3.2.3 and I spent the next
> > > 27 hours recovering. Corruption got in the datafile and REDO logs and
> > > was also archived. We (myself and an Oracle analyst at Oracle support)
> > > didn't know for sure when the corruption occurred. Got lucky doing a
> > > point-in-time recovery with a guess.
> > >
> >
> > Fascinating stuff. But not relevant, is it?
> >
>
> See above comment.
>
>
> > >
> > > > and can also protect you from hardware (disk) failure, since each
member
> > is
> > > > supposed to be housed on a different disk.
> > > >
> > > > >
> > > > > 2) The 2nd choice is to use Oracle's "mirroring" by specifying a
2nd
> > member
> > > > > in each REDO group.
> > > > >
> > > > > 3) If you use OS mirroring, you shouldn't need the Oracle
mirroring
> > and
> > the
> > > > > opposite is true too.
> > > > >
> > > >
> > > > Total and complete bollocks, I'm sad to say. They are complementary,
but
> > > > your first choice should be Oracle multiplexing. By all means then
> > hardware
> > > > mirror, too. But multiplexing should be regarded as compulsory.
> > > >
> > >
> > > I appreciate your paranoid attitude. You have to be a little paranoid
> > > to be a server DBA :) I would admit in a "perfect" world, I would
> > > want 4 disks for REDO logs for EVERY database. Really, though, not all
> > > installations have the option of using 4 disks for REDO logs.
> > > Sometimes, you are limited .
> > >
> >
> > Then compromise by combining data files on what few disks you have and
> > suffering a performance hit. But don't compromise the safety of your
data by
> > not multiplexing.
> >
>
> Maybe my attitude on Oracle mirroring/multiplexing could use an
> update.

It certainly could.

>As I said above, I lost all faith in Oracle mirroring during
> the recover mentioned above.
>

It's not even called 'Oracle mirroring". It's called multiplexing. Precision, dear. Precision.

>
> > > We also have a lot of SysAdmin types who think all Oracle files
> > > should/could go on 1 RAID disk ... nuts. Anyway, purchases are made
> > > without talking to DBAs sometimes too. Stuff happens.
> > >
> > >
> > > > Thus speaks an Oracle instructor, incidentally, so where you get the
> > idea
> > >
> > > I once had an Oracle instructor tell me in an Oracle7 application
> > > tuning class that the CBO would ALWAYS make a better performance
> > > choice over the RBO.
> > >
> > > YEAH, sure.
> > >
> >
> > I smell a strawman. What some instructor told you in years gone by about
> > optimization of SQL has nothing to do with the issue at hand.
> >
>
> You mentioned first "Thus speaks an Oracle instructor" . I was only
> pointing out that doesn't always guarantee it.

Do your research, then. This Oracle instructor has been posting regularly to this newsgroup for 3 years. He's learnt lots, and corrected himself more than a few times. But can't stand idiots posting utter bullshit on things he actually knows something about.

>
> > > This goes to show you all instructors don't always know what the heck
> > > they are talking about.
> > >
> >
> > This goes to show you that *an* instructor bought the marketing spiel of
> > Oracle 7. It says nothing about the merits or otherwise of multiplexing
> > and/or mirroring.
> >
> > > Of course, that is just one in my 10 to 15 classes on Oracle, so that
> > > isn't bad for Oracle.
> > >
> >
> > It took you that many?
> >
>
> Oracle6 Introduction
> Oracle6 DBA I
> Oracle6 DBA II
> Oracle6 CASE Tailored Class
> Oracle7 DBA I
> Oracle7 DBA II
> Oracle7 Application Tuning
> Oracle7 Server Tuning
> Oracle8+8i New Features for DBAs
>
> Ok, so only 9. I suppose I was thinking of all the Unix type classes
> like Bourne programming, Pro*C, etc. .
>

"Of course, that is just one in my 10 to 15 classes on Oracle".

"Ok, so only 9".

Come off it. Post facts, please. Be precise, factual and accurate. 10 to 15 suddenly becomes 9?????

And you have the gall to question MY attitude?

> > >
> > > > the "Oracle" as an entity recommends one approach over the other, I
have
> > no
> > > > idea.
> > > >
> > >
> > > In a white paper off Metalink ... maybe I'll have time another day to
> > > dig it up for you.
> > >
> >
> > Don't bother. Here's the documentation:
> >
>
> Yeah, this appears to be the latest.

It doesn't appear to be the latest. It *is* the latest.

[snip]
> > >
> > > You ever tried to do an "ls" command on a directory with 1000's of
> > > files ... pipe it to grep and you get strange errors... scripts start
> > > failing ... etc.
> > >
> >
> > So, manage the archive destination properly.
> >
>
> Yeah, don't make the log too small right ? Of course, clean up after
> backing up twice too.
>

Don't be ridiculous. Clean up when it is suitable to 'clean up' if by 'clean up' you mean deleting archive logs. I sincerely hope you don't think that because you've backed up twice you can delete all prior archives without compunction.

> >
> > > And too large, impacts INSTANCE recovery.
> > >
> >
> > No. Too long an interval since your last checkpoint affects the time it
> > takes to perform an Instance recovery, not the size of your redo logs
per
> > se. It is perfectly possible to have enormous online redo logs, and have
a
> > perfectly respectable instance recovery time. That's what
> > LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, FAST_START_IO_TARGET,
> > DB_BLOCK_MAX_DIRTY_TARGET and FAST_START_MTTR_TARGET are all about.
> > Depending on your version.
> >
>
> Seems easier to just size the REDO at a good time for checkpointing,
> since checkpoints occur when the log switches.
>

Yes, well. We know what you think easier: stating things which just aren't true.

> Why complicate things when you can make them simpler?
>

Because there are a rich variety of tools avialable to you to make sure that instance recovery times are NOT dependent on the size of your online redo logs. So what's the point in pretending that size makes all the difference?

> Does anyone really tweak these parameters?

Er, yes actually. Good DBAs do.

>I usually just set the
> interval real high to force checkpointing at log switch time.
>

What you 'usually just set' and what is good practice might just happen to be two completely different things. Oh: and in this case, they just happen to be two completely different things.

>
> > >
> > > > DBAs forever have to worry about the AMOUNT of redo generated,
because
> > an
> > > > archive destination that uses up all its available space is a
problem
> > > > waiting to happen: but that's a function of size, not of number.
> > > >
> > >
> > > And you didn't even mention since 8i you can have multiple
> > > destinations :)
> > >
> >
> > You can't even get this correct, either. Multiple destinations was
actually
> > introduced as a feature of 8.0, not 8i. LOG_ARCHIVE_DEST and
> > LOG_ARCHIVE_DUPLEX_DEST.
> >
>
> We skipped 8.0 .
>

Uh huh. So that makes it alright to post to these newsgroups with statements which are false, misleading and totally erroneous?

I don't think so.

>

[snip]
> > > My current newsgroup is not allowing me to post for some stupid
> > > reason. So, I use Google to post and my normal Bellsouth newsgroup to
> > > read.
> >
> >
> > Another total non sequitur. All newsgroup posts, made from wherever, are
> > archived at Google.
> >
>
> Again, you mentioned "such archives as Google". I was only pointing
> out that I don't use it normally.
>

And I was pointing out that it doesn't matter one iota: Google will archive you and the completely fallacious nonsense you posted, wherever you posted it from.

>
> > Putting it bluntly, you may have been doing this stuff for 10 years, but
> > your knowledge and understanding are demonstrably weak, and your initial
> > statement that "Oracle's 1st recommendation is to use OS mirroring for
REDO
> > logs" is totally untrue, as a cursory glance at the documentation would
have
> > shown you.
> >
>
> I might have spoke too soon with mentioning the phrase "Oracle
> recommends"

Correction. You spoke too soon, erroneously, and without the slightest scintilla of evidence to back you up. And you were wrong in any case.

>, although I do have a paper from Oracle stating that .

Can't wait for the evidence.

> And, yes I lost faith in Oracle multiplexing back when I had to do the
> recover mentioned above.

OK. I respect the fact that your experience has exposed you to recovery scenarios I couldn't dream of. And you are entitled to your opinions as a result. What you are not entitled to do is post your opinions here (and at Google for the forseeable future) AS THOUGH THEY WERE FACT.

You stated that Oracle advises X when in fact it advises Y. I pointed out that Oracle didn't advise X at all, and get a stream of abuse about my 'attitude' as a result. When it comes to insults, you cast the first stone.

If you could but admit that what you posted was your opinion, I'd back off immediately. Everyone's entitled to their opinion. Just don't pretend that your opinion (which on the physical facts is slightly dodgy anyway) is factual or meaningful.

I take absolutely zero pleasure in pointing out factual errors like this. But Oracle software is too good to let shit myths and opinions stuff up its implementation. And the facts are too easily discernible to warrant the dissemination of errors, at least in this particular area.

As I said originally, I wish you a joyful Christmas and a happy new year, because I am not an ogre or a piss-artist, and actually care that anyone who invests time and effort in Oracle should come up trumps.

I hope we can move on from this and leave the world a wiser place.

End of thread
HJR
>Oracle put corruption in the REDO and
> mirrored it. I was multiplexing and it was useless.

>
> > Sorry you don't like my attitude, but those are just the facts.
> >
> > HJR
Received on Mon Dec 23 2002 - 22:45:29 CST