Re: Redo Log Question

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

I have been doing Oracle server DBA support for about 10 years.

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.

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.

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

> Oracle multiplexing, by contrast, protects you from both these scenarios,

Uhh ? Why wouldn't Oracle put the same damn corruption in both copies? 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.

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

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.

This goes to show you all instructors don't always know what the heck they are talking about.

Of course, that is just one in my 10 to 15 classes on Oracle, so that isn't bad for Oracle.

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

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

And too large, impacts INSTANCE recovery.

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

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

> HJR
>
>
>
>
>
>
> >
> > Chucky <chuck.carson_at_syrrx.com> wrote in message
> news:<3E05D398.7010208_at_syrrx.com>...
> > > How would I add more logs per group on a database that has already been
> > > created and is up and running?
> > >
> > > Thx,
> > > CC
> > >
> > > Howard J. Rogers wrote:
> > > > "Chuckster" <chuckycarson_at_networkcloud.com> wrote in message
> > > > news:3E04A739.5020503_at_networkcloud.com...
> > > >
> > > >>When you have your redo logs created as follows:
> > > >>LOGFILE
> > > >> GROUP 1 '/u01/oradata/syrlims/redo01.log' SIZE 10M,
> > > >> GROUP 2 '/u02/oradata/syrlims/redo02.log' SIZE 10M,
> > > >> GROUP 3 '/u03/oradata/syrlims/redo03.log' SIZE 10M,
> > > >> GROUP 4 '/u04/oradata/syrlims/redo04.log' SIZE 10M
> > > >
> > > >
> > > > Correct. No redundancy. If you wanted redundancy, it would look like
> this:
> > > >
> > > > LOGFILE
> > > > GROUP 1
> > > > ('/u01/oradata/syrlims/redo1a.log','/u05/blahblahblah/redo1b.log')
> SIZE
> > > > 10M,
> > > > GROUP 2 ('/u02/oradata/syrlims/redo2a.log','/u06/bbb/redo2b.log')
> SIZE
> > > > 10M,
> > > > GROUP 3 ('/u03/oradata/syrlims/redo3a.log','/u07/bbb/redo3b.log')
> SIZE
> > > > 10M,
> > > > GROUP 4 ('/u04/oradata/syrlims/redo4a.log','/u08/bbb/redo4b.log')
> SIZE
> > > > 10M
> > > >
> > > > Extra groups buy you time before you start over-writing earlier logs
> (and,
> > > > specifically, buys ARCH time to archive the earlier logs before your
> try and
> > > > re-use them).
> > > >
> > > > Extra members per group buys you resilience and redundancy.
> > > >
> > > > And I've renamed your original files so that the number indicates the
> group
> > > > and the letter indicates the member, which I find easier to manage
> than the
> > > > 'official' recommendation of, for example, REDO0101 and REDO0102.
> > > >
> > > > Regards
> > > > HJR
> > > >
> > > >
> > > >>
> > > >>This is merely 4 different log files with no redundancy correct? If I
> > > >>wanted path redundancy, I would need to add more log files per group
> and
> > > >> make sure they are on different volume groups/spindles correct?
> > > >>
> > > >>Thanks,
> > > >>CC
> > > >>
> > > >>
> > > >>
> > > >>-----------== Posted via Newsfeed.Com - Uncensored Usenet News
> > > >
> > > > ==----------
> > > >
> > > >> http://www.newsfeed.com The #1 Newsgroup Service in the
> World!
> > > >>-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers
> > > >
> > > > =-----
> > > >
> > > >
> > >
> > >
> > >
> > > -----------== Posted via Newsfeed.Com - Uncensored Usenet News
> ==----------
> > > http://www.newsfeed.com The #1 Newsgroup Service in the World!
> > > -----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers
> =-----
Received on Mon Dec 23 2002 - 02:57:51 CST