Re: Redo Log Positioning

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)


Sent via Deja.com http://www.deja.com/
Before you buy.