Re: Redo Log Question

Howard, Sybrand, Dan

I don't think these are the things you should be proud of. Correcting incorrect information is ok. Insulting people is no part of that. (As "Syster" should be told too!)

DA Morgan <damorgan_at_exesolutions.com> schreef in berichtnieuws 3E079182.4ECC313F_at_exesolutions.com...
| "Howard J. Rogers" wrote:
|
| > "Burt" <burtpelt_at_bellsouth.net> wrote in message
| > news:98b09e2b.0212230057.6926d977_at_posting.google.com...
| > > "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
| > news:<zArN9.8420$jM5.23904_at_newsfeeds.bigpond.com>...
| > > > "Burt" <burtpelt_at_bellsouth.net> wrote in message
| > > > news:98b09e2b.0212221105.68ab19e8_at_posting.google.com...
| > > > > I just thought I would mention a few other points ...
| > > > >
| > > > > 1) Oracle's 1st recommendation is to use OS mirroring for REDO
logs. I
| > > > could
| > > > > see debating this one and using the 2nd choice.
| > > >
| > > > That's simply not true. Oracle, like others, clearly understands
that OS
| > > > mirroring protects you only from hardware failure. But it does not
| > protect
| > > > you from user stuff-ups or LGWR wobblies. If LGWR introduces some
| > corruption
| > > > into a redo log as it writes (which it has been known to do from
time to
| > > > time) then OS mirroring will simply and faithfully replicate that
| > corruption
| > > > onto the hardware mirror. Result: no good logs, but multiple copies
of a
| > > > stuffed one.
| > > >
| > >
| > > First of all, your attitude sucks big time. You need to lighten up!
| >
| > Funny. The only time I get comments about by attitude and needing to
change
| > it is when somebody posts complete and utter nonsense, and I point it
out to
| > them.
| >
| > Plus ça change.
| >
| > >
| > > I have been doing Oracle server DBA support for about 10 years.
| > >
| >
| > Badly, by the sounds of 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.
| >
| > >
| > > > 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.
| >
| > >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?
| >
| > >
| > > > 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.
| >
| > > 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.
| >
| > > 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?
| >
| > >
| > > > 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:
| >
| > "Oracle provides the capability to multiplex an instance's online redo
log
| > files to safeguard against damage. When multiplexing online redo log
files,
| > LGWR concurrently writes the same information to multiple identical
online
| > redo log files, thereby eliminating a single point of failure. You can
also
| > mirror redo logs at the operating system level, but in so doing you run
the
| > risk of operating system or hardware induced corruption. In most cases,
| > multiplexing of online logs is best."
| >
| > (From Backup and Recovery Guide, 8.1.7. It hasn't changed since 8.0, and
its
| > the same in 9i).
| >
| > By the way, the link is:
| >
| >

http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76993/data
| > stru.htm#7922
| >
| > And you might notice the last sentence there. "In most cases,
multiplexing
| > of online logs is best."
| >
| > Goodnight Gracie.
| >
| > >
| > > > > 4) These REDO logs are the "hottest" (I/O) files in Oracle .
| > > > >
| > > > > 5) You shouldn't put REDO logs on the same disk as tablespace
files.
| > > > >
| > > > > 6) Oracle writes and reads(if in archivelog mode) these files a
lot
| > but
| > > > > sequentially and so the "best" choice is to put them on a OS
mirrored
| > file
| > > > > system, not a RAID5 disk (which has a write "penalty").
| > > > >
| > > > > 7) Specify more than just 1 or 2 groups if in archivelog mode.
This
| > allows
| > > > > the LGWR (Log Writer) process time to copy the log before it is
| > reused.
| > > > >
| > > >
| > > > Uh huh. And how in God's name do you propose that anyone specifies
just
| > 1
| > > > group in the first place? You are required to have a minimum of two.
| > > >
| > >
| > > Got me there. Since I never create less than 3 or 4, I wasn't sure
| >
| > So, you've been a DBA for 10 years, and have Oracle training back to
version
| > 7, but you don't know the minimum number of required online redo logs.
| >
| > Uh huh.
| >
| > > (hence the "1 or 2" comment).
| > >
| > >
| > > > > 8) REDO log sizes I have seen used are anywhere from 8Meg to
100Meg.
| > In
| > > > > media recovery, Oracle might take a little longer to apply the
most
| > recent
| > > > > REDO log if large. But, a small size might generate too many
archived
| > logs
| > > > .
| > > >
| > > >
| > > > You actually haven't got a clue, have you? In MEDIA recovery,
Oracle
| > must
| > > > apply all redo generated since the time of the last backup, which
| > probably
| > > > means that a multiplicity of logs will have to be applied. In
INSTANCE
| > > > recovery, Oracle has only to apply the contents of the current redo
log,
| > or
| > > > the redo which was generated since the time of the last checkpoint,
| > > > whichever is the lesser.
| > > >
| > > > Therefore, the size of the logs is immaterial to INSTANCE recovery
time,
| > if
| > > > you have induced additional checkpointing to compensate.
| > > >
| > > > And as for the comment that 'a small size might generate too many
| > archived
| > > > logs', what's that supposed to mean? What number do you think is
"too
| > many"?
| > > > Oracle couldn't give a damn if you have 1000 1M archived logs, 100
10M
| > > > archived logs or 10 100M archived logs. It makes no difference to it
| > because
| > > > as soon as ARCH has written the archived log, it's finished with it,
and
| > > > doesn't care what happens to it. And there's no discernible increase
in
| > the
| > > > time it takes to apply 1000 1M logs compared to 10 100M logs.
| > > >
| > >
| > > 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.
| >
| > > 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.
| >
| > >
| > > > 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.
| >
| > In 8i, the LOG_ARCHIVE_DEST_n parameter was introduced, permitting you
to
| > have up to 5 archiving destinations, some of which could be remote
databases
| > for the benefit of automated transfer of redo to a Standby Database. But
| > only if you used the Enterprise Edition of the software. If you used the
| > Standard Edition, you had ARCHIVE_DEST and DUPLEX_DEST to fall back on.
| >
| > In 9i, you are permitted to have up to 10 DEST_n destinations. But only
if
| > you have the Enterprise Edition of the software. If you used the
Standard
| > Edition, you had ARCHIVE_DEST and DUPLEX_DEST to fall back on.
| >
| > And what any of that has to do with the appropriate size of your online
redo
| > logs, I haven't the foggiest.
| >
| > >
| > > > Honestly. I wish you a Merry Christmas and an enlightening New Year.
But
| > I
| > > > pray that when next you post, you actually know what you're talking
| > about.
| > > >
| > > > (And yes, I've been harsh here, because I don't want to see your
| > complete
| > > > distortion of the truth and half-baked misunderstandings go
unchallenged
| > in
| > > > such archives as Google... newbies use that as a resource a lot, and
| > > > shouldn't have to wade through this sort of tripe).
| > > >
| > >
| > > 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.
| >
| > 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.
| >
| > Sorry you don't like my attitude, but those are just the facts.
| >
| > HJR
|
| Brilliantly done.
|
| If you were here in Seattle I'd pop a cork and pour you a cold Chimay.
|
| Dan Morgan
|
|
Received on Mon Dec 23 2002 - 17:05:08 CST