Re: Redo Log Question

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

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.

Oracle multiplexing, by contrast, protects you from both these scenarios, 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.

Thus speaks an Oracle instructor, incidentally, so where you get the idea the "Oracle" as an entity recommends one approach over the other, I have no idea.

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

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

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.

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

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 Sun Dec 22 2002 - 17:17:05 CST