Re: disks for redo logs
Date: Wed, 11 Feb 2009 18:19:38 -0800 (PST)
Message-ID: <1d859786-e531-41dd-84f1-3897b662e6b7_at_r41g2000prr.googlegroups.com>
On Feb 12, 6:26 am, joel garry <joel-ga..._at_home.com> wrote:
> > I've got two database - rac and single - and two RAID groups - 4 disks
> > in RAID 10 and two disks in RAID 1 on storage array. At this time I'm
> > using RAID 10 for RAC database redo and RAID 1 for single instance
> > database redo.
I hope you mean 4 mirrored pairs in RAID10, because if it is just 4 disks in total, what you got is a 2 mirrored device stripe which achieves little in terms of speed-up.
> > RAC is producing about 100% percent more redo then single db.
> > I am wondering if it would be more efficiently to make one RAID 10 from
> > 6 disks and use it for both database ? I have no possibilty to test
> > this configuration so that is why I am asking You. Thanks for any advices.
>
What you need is a heap more disks, if you want to mess around with IO configurations. 6 disks is not enough for any decent amount of tuning in a SAN for 2 databases.
I've now got two stripes of 8 mirrored pairs each for our main DW and I'm *starting* to see *some* IO throughput improvement.
> 10.2.0.4 (and I would guess above) check out the ${ORACLE_SID}
> _lgwr*trc trace files, it spits out a message whenever log writes take
> more than .5 seconds or something, compare to your performance
> monitoring.
Interesting! Thanks for that, Jgar!
>I was a bit surprised when I first noticed what's in
> those traces, haven't quite figured out how to translate that for
> management. The surprising part was the size of writes versus the
> waits - apparently quite unrelated. Which I guess makes sense if the
> waits are caused by other things than the log writes.
What span of sizes are you seeing?
> I used to think having different volume groups would help, but I've
> been disabused of that notion. Now I don't understand it at all. SAN
> cache makes it all strange, too.
One thing I've found makes a huge difference: jack up the priority of the lgwr and arcn processes. They are mainly IO bound processes, hardly accumulating any CPU, they are perfect candidates for higher priority so that IO gets initiated asap.
> But hey, if users aren't complaining, everything is peachy. Right?
Bingo! ;) Received on Wed Feb 11 2009 - 20:19:38 CST