Re: Redo Log Positioning

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

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

with only 5 disks total, you don't really have enough disks to effectively spread the i/o for the online redo log groups.

due to the sequential nature of the redo logs, RAID-5 isn't buying you much of a boost in performance. actually, if all of the other datafiles (temp, rbs, data, indexes) and the archive logs are spread over the same disks, you'll have more than enough i/o contention on the disks already.

in the "24x7 Tips" Oracle Press book, the author describes (in what seems to be an excruciating level of detail) placing the online redo logs in such a way as to minimize the contention problem that you describe in your question. but in the author's proposed solution, he uses four or more disks (and multiple controllers) dedicated solely to the online redo logs.

i understood the authors point to be that on a very active system, one that is handling a huge load of inserts/updates/deletes, where the i/o has been otherwise distributed effectively over a sufficient number of disks, the redo log files can become a bottleneck, similar to the one you describe in your original post. the placement of the redo log files he describes can alleviate that potential source of i/o contention.

for my environment, i have two disks (each disk holding one of two members from each redo log group) dedicated to the online redo log groups.

by segragating the online redo logs to their own dedicated disks, i think i have alleviated as much of the potential i/o contention problem that i can, given the number of disks i have right now. the setup i have now can be easily modified to add additional dedicated disks to allow for alternating active redo log groups between two sets of disks. Received on Mon May 08 2000 - 00:00:00 CDT