Re: Redolog group Members

On Fri, 26 Nov 2004 06:11:38 +1100, "Howard J. Rogers" <hjr_at_dizwell.com> wrote:

>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?

But what, if I rm all logs? I once did exactly that with a bad online backup script. I did save all members, than delete it - though, this was planned just for the archived logs. They had the same ending. :-|

So deleting a log member is not hypothetic - the same for deleting all members. So more files does not neccessarily mean more safety.

>And what do you think will happen on the mirror?

This mirror is done by the OS, oracle again does mirror for itself. The question is:

>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.

And the logwriter does mirror it's corruption the all members? BTW, if I could not trust oracle's engine, I would need to multiplex all database file too, right? Our real live experience is, that I never had a corruption in a logfile, when needing a log file since now. Alhtough we had corruptions in the database files.

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

Why? Is that a hope, or an experience? And at all: In the end, the online redo's get archived, and that's it. So what means software corruption? Just, if I want to roll forward my database in very rare cases, if will feel this corruption, am I right?

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

Where should I stop then? Why 3, not 4 or 5? Am I safer, if I can make 3 user errors?

>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.

Hm, this is old shool knowledge. This is always true. The really interesting question is, where to stop with safety? Where to make the cut. I'm searching for your experiences about this, not for THE solution.

>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.

Safety vs. performance are not always contrahents. For the OS based mirroring for example, the mirroring gives you a better read performance, because the fastest mirror does answer first.

We want, for shure, safety and performance - both as much, as is possible. And, you are right, we might need to find the right compromise.

>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.

We have such databases. But for several production databases this is not an option for us. Though, the database just get's rid of the archiving processes (may be some bigger amount of I/O), but the online redo-logs are written the same way and still od have their I/O.

--
Martin Doering