Re: Redolog group Members

Martin Doering wrote:
> Hello, DBAs!
>
> What is your experience with adding members to redolog groups? We have
> a very high available disk and OS-mirroring configuration. Since the
> early days we have 2 members in every redolog group. But in my eyes
> this seams totally stupid in our configuration, because we just do not
> have disks anymore. We are operating on a big cache on the disk
> arrays. All our redolog group members are on the same disk array's
> logical disk, which has multiple gigabytes space.
>
> It seems, that oracles manuals are just copying their recommendations
> from version to version, without having an eye on new technologies.

Or it could be that you have got hold of the wrong end of the stick, and maybe the manuals know just a little bit more about it than you do.

You have wonderful hardware there. You therefore have wonderful protection against hardware failure.

But if I were to walk in to your server room, and issue an 'rm log1a.rdo' command, how much protection does all that hardware offer? Your O/S will merrily delete the first member of that group, won't it?

And what do you think will happen on the mirror?

And in similar vein, LGWR is not perfect and has been known to throw the odd bit of corruption into a log before now. What it writes to one log group will be faithfully mirrored onto the other by your wonderful hardware, won't it. At which point, you have a totally corrupt log group.

Making LGWR write more than once to separate log group members means the chances of software error corrupting an entire group are slender.

> What is your experience? We measured, that on a database with high I/O
> load you can optimize your performance by dropping group members,
> because it simply doubles the I/O. What is your recommendation??

My recommendation is that you are under-multiplexed by a factor of 1: There should be three members per group.

You should learn the mantra: hardware mirroring protects you from hardware failure. But it does nothing for software or user stuff-ups. For that, you need Oracle multiplexing.

And of course there's a performance hit. What do you want? Safety or performance? It's a valid thing, sometimes, to say 'performance every time', but don't then run crying to management when you lose half an hour's-worth of committed transactions. These things are usually a balance, and I suspect that most organisations most of the time would want to know their data was safe, provided performance was merely acceptable.

If you feel that way about things, of course, you could always set _disable_logging=true, watch your database run like a leaping gazelle, and grow grey very quickly wondering when your database is about to become completely toast.

HJR
>
> --
> Martin Doering
Received on Thu Nov 25 2004 - 13:11:38 CST