Re: Average size of reads from online redo logs by ARCH process
- From: Alexander Gorbachev <gorbyx@xxxxxxxxx>
- To: bmccartney@xxxxxxxxxxxxxxxxxxx
- Date: Tue, 16 Nov 2004 23:14:59 +0100
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@xxxxxxxxxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
