Re: Redo Log Question

Hi Howard,

The next time I make a mistake (which won't be too long I'm sure), please be gentle.

I'm very fragile and need to be handled carefully.

Please ;)

Merry Xmas !!

Richard
"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:ruRN9.9139$jM5.26326_at_newsfeeds.bigpond.com...
>
> "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 Tue Dec 24 2002 - 01:02:06 CST