Re: Redo Log Positioning

Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com> schreef in berichtnieuws 8f71kv$ovc$1_at_nnrp1.deja.com...
> In article <957303170.25609.0.pluto.d4ee154e_at_news.demon.nl>,
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote:
> >
> > Ed Stevens <Ed.Stevens_at_nmm.nissan-usa.com> schreef in berichtnieuws
> > 8end9q$rjo$1_at_nnrp1.deja.com...
> > > In article <957288168.15447.0.pluto.d4ee154e_at_news.demon.nl>,
> > > "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote:
> > > > IMO you have no other choice than to place the redologs on one
 raid 1
 disk,
> > > > and the hard- or software mirror on the other raid 1 disk.
> > > > As the redolog files are written sequentially there is no
 performance
 hit in
> > > > placing all three on one drive. I usually start with 4 redo log
 groups, this
> > > > layout seems less troublesome.
> > > >
> > > > Hth,
> > > >
> > > > Sybrand Bakker, Oracle DBA
> > > >
> > > > <rogerxb_at_my-deja.com> schreef in berichtnieuws
> > > > 8emjtg$t78$1_at_nnrp1.deja.com...
> > > > > I currently have two redo log files, unmirrored and sized at 2M
 each.
> > > > > When we see intense processing there is a slow down and the
 error
 log
> > > > > indicates that the bottleneck is the redo logs; they are unable
 to
> > > > > complete archiving quickly enough when switching from redo 1 to
 redo 2.
> > > > >
> > > > > So I realize I have to re-work the system to at least increase
 the
 size
> > > > > of the logs, and therefore switch less frequently.
> > > > >
> > > > > Here's my question.
> > > > >
> > > > > I have 5 physical 9.1 Gig drives - split into two raid sets -
> > > > > 2 * 9.1 Gig Raid 1 and
> > > > > 3 * 9.1 Raid 5.
> > > > > The current redo logs are placed one on each of these separate
> > > > > devices.
> > > > > I understand that my Raid 5 is going to be slower when writing
 the
> > > > > logs, but what I want to know is - how should I lay out my log
 files?
> > > > > I believe The theoretical best is to have three groups with two
> > > > > mirrored members in each, across at least three devices; but I
 only
> > > > > have two physical devices and one is quicker than the other
 ......
 any
> > > > > suggestions ??
> > > > > Should I just increase the size of my logs, and allow the
 operating
> > > > > system to do all the mirroring ???
> > > > >
> > > > > Cheers
> > > > > Rog
> > > > >
> > > > >
> > > > > Sent via Deja.com http://www.deja.com/
> > > > > Before you buy.
> > > >
> > > >
> > >
> > > While the writing from one log to the next is sequential, if you
 place
> > > them on the same physical device (regardless of any RAID or logical
> > > partitioning) wouldn't there be contention as one log file is being
> > > written while the previous one is being read for archive? Of
 course,
> > > this assume archive logmode.
> > >
> > > --
> > > Ed Stevens
> > > (Opinions are not necessarily those of my employer)
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > You would be right when you have only 2 redo log groups. Having three
 or
> > more minimizes the chance this happens. Say you have 3 online redo log
> > files, only if the third file fills, archiving will occur, and this
 is a
> > single action, so the contention should be short, instead of
 continuous.
> > I agree there are situations with occasional 'bursts' of activity,
 when all
> > online redolog files fill at the same time. IMO: you need to adjust
 the size
> > of your redo log files to prevent this happens.
> >
> > Regards,
> >
> > Sybrand Bakker, Oracle DBA
> >
> >
> Sounds like you're talking about what I refer to as "wraparound
> wait." This is when Oracle needs to start writing to a log set that
> has not finished archiving. What I was referring to was the
> contentention that occurs before this. Log1 fills up, a log switch
> occurs to start writing to log2. While activity is being written to
> log2, Log1 is being read for archiving. At this point, if both logs
> are on the same physical device, you have the physical contention
> between read operations against Log1 and the writing against Log2. Or
> is it your point that the read for archiving is generally so short as
> to not really be an issue?
> --
> Ed Stevens
> (Opinions are not necessarily those of my employer)

>
>

LGWR performs sequential appends, while ARCH does a sequential copy, so yes, read activitiy should be so short not to be an issue.

Regards,

Sybrand Bakker, Oracle DBA Received on Mon May 08 2000 - 00:00:00 CDT