Re: Average size of reads from online redo logs by ARCH process

From: Alexander Gorbachev <gorbyx_at_gmail.com>
Date: Tue, 16 Nov 2004 23:14:59 +0100
Message-ID: <c2213f6804111614145be80776@mail.gmail.com>

Bruce,
Thanks for your response. Btw, our platform is HP-UX. I put some comments inline below...

On Tue, 16 Nov 2004 13:23:22 -0700, McCartney, Bruce <bmccartney_at_talisman-energy.com> wrote:
> 1) raw devices performed better ('log file parallel write') than solaris ufs by between 10 and 20% on average time over long periods. I think this is notion is supported by steve adams notes.

We are also on raw devices - first of all, because all our DB are RAC.

> 2) the drives were mirrored in the EMC array and we were told by EMC that the array will perform sequential reads (ARCH copies) from the 'mirror' as to not introduce measurable contention. We did not confirm this technically but were unable to see any contention when ARCH was active reading. so this may not be a critical issue for you. Are you spending a lot of time in log file sync? There may be other reasons why...

Our mirroring is implemented differently for HA. We use separate storage arrays, controllers, networks, and independent physical location. So we wouldn't benefit from mirroring. I think that some of DBs have too large log_buffer that leads to extensive 'log file sync' waits.

> 3) the array provides a degree of isolation from physical writes to a point by memory caching, but there is a limit of a number of writes that can be pending on any one drive in the array. because of this behavior, our emc tech specialist advised us to stripe the redo rather than but it on a separate disk pair in the array. I can't recall the stripe size off hand...

I am not quite comfortable with understanding caching in EMC. I don't understand how it's implemented - per controller/LUN/disk... Would be greate if anyone can recommend a good paper on EMC architechture and caching implementation.

-- 
Best regards,
Alex Gorbachev
--
http://www.freelists.org/webpage/oracle-l

Received on Tue Nov 16 2004 - 16:45:04 CST