Re: Scalable Performace - Inserts/Updates

On Thu, 21 Dec 2000 15:24:35 -0000, "Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote:

>
>The basis of your discussion is no doubt why
>Oracle has played around with parameters like:
>
> lgwr_io_slaves
> lgwr_async_io
>
>over the last few years. (Both are hidden in 8.1.7)
>In theory they allow for Oracle doing the multiplexing
>without the loss of time due to the need to serialise
>copies of each write.
>

I'm not so sure they would help. For all intents and purposes, it still needs to have two I/O's (two members) fully synced before the next write can start. While AIO is good to let the main process proceed while the write takes place, truth is with redo log writes, the redo writer can't do anything else until the write actually finishes. Which means it has to wait anyway, therefore defeating the purpose of the async I/O.

The slaves is another thing. I've played around with them but I could not measure any diff. Maybe I didn't have the right test situation or methodology? Possible and I am prepared to admit it.

What does 8i do? Async or auto-slaves? Or both?

I'm still convinced that two members per group is not needed in RAID-like environments (EMCs, Sharks, and so on). I have yet to see one redo log corruption in such an environment that can clearly be corrected by using two members.

My point being that either the corruption is caused by the ORACLE code itself in which case it will corrupt both files, or it's caused by the hardware (disk error), in which case the RAID will do its job and fix it. I'm assuming of course the hardware is reliable. If not then it's multiple members, obviously!

Of course like in anything, YMMV, IMHO, etcetc. But if I want top speed, I stay with single member per group. That, I was able to measure clearly, makes a diff.

Cheers
Nuno Souto
nsouto_at_bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Fri Dec 22 2000 - 04:27:36 CST