Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Redolog group Members

Re: Redolog group Members

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Tue, 30 Nov 2004 05:18:42 +1100
Message-ID: <41ab67f0$0$9113$afc38c87@news.optusnet.com.au>


Martin Doering wrote:
> On Fri, 26 Nov 2004 22:53:48 +1100, "Howard J. Rogers"
> <hjr_at_dizwell.com> wrote:
>
>

>>>So deleting a log member is not hypothetic - the same for deleting all
>>>members. So more files does not neccessarily mean more safety.
>>
>>The word "necessarily" is redundant. Of course if you are totally 
>>insane, ...

>
>
> Why that now... :-|

It's called making a point with a dramatic gesture, and only looks bad when you cut the sentence in half... so let me put it back in as it was written and as it was intended to be read:

"Of course if you are totally insane, or allow completely imbecilic people to have access to your servers, no amount of redundancy will help."

>>So I hope you won't start arguing or refuting.

>
>
> No, I won't. My problem is, that I not seem to be able guide
> (direct?!?) the discussion in a direction, that it gives me the
> answers I was searching for.

That only requires that you state a question concisely and clearly. Your question was succinct enough:

"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 experience has been as I've described. Hardware mirroring does not protect you from eager juniors who think tidying up all *.tmp and *.log and *.txt files is helpful and who wipe out a redo log member as a result. My experience has been, as I discussed, that of course performance increases when you drop log members, and equally obviously, it tends to decrease as you add them... but that is not sufficient justification for risking your data. And my recommendation has been very, very simple: three-way multiplexing.

Quite why you think, therefore, that the discussion has not gone in ways you wanted, I can't imagine.

> It is totally clear to me, that it will less often happen to delete
> exidently 2 or 3 files, than one. And it is also clear to me, that
> users and admins can make mistakes, and that more redundancy will in
> some or many cases save me from catastrophic failures. It is also
> clear to me, that redundance may be the major topic, if we talk about
> safety at all.
>
> All the discussion here is about risk. And you are totally right: I
> did not say a word about personal failures in my initial post: My
> failure. We do not need to discuss it here the way it happened.

When a poster starts telling me what needs and doesn't need to be discussed, the thread is hurtling on its way to the wastebin.

Martin, I'll try and make this as short and clear as I can. *Anyone* who states that he thinks multiple log members in a redo group is "totally stupid" absolutely needs to discuss the issue.

> Everything is totally clear here.
>
> That still things can happen, like it did happen with the big virtual
> disk I did talk about, does not relativate the above topic in any way.
> It was, as I tried to state, just a risk you can not get around by
> multiplying the log members. That's all.

Look... risk is inevitable, and you cannot *eliminate* it, buy as many hardware controllers as you will, multiplex to the nth degree as you might, or pray daily to your chosen deity though you may. What DBAs are in is the business of risk *minimisation*. Usually at the expense of cash or performance or both -and therefore actually in the business of maximising a risk minimisation whilst containing related costs (financial and performance ones) as much as possible. *That* is it all in a nutshell.

> What I wanted to hear is, if there had been other people thinking
> about their number of logfiles, and what they did choose and why. I
> definately did ask for _experiences_, two times.

And what I cannot fathom is why you think what I wrote was not based on several years of experience.

> For example I would have liked to hear about the performance topic I
> did address in my initial post, or that I (maybe) would have other
> advantages, if I have more log members. Or maybe disadvantages. Or
> "Where the costs exceed the perceived benefits.". Or why you would
> recommend 3 log members - you did not explain it.

Yes I did. 2 members gives me redundancy of 1. I sleep better at nights when I have redundancy of 2. Generally, of course, because it ultimately depends on who is paying the bills, and how persuasive I can be.

> Oracle did say two.
> Why 3 then? What did make you choose 3, when you do not know my setup
> at all?

And what, pray, has knowing your setup or not got to do with recommending a course of action which is obvious, self-explanatory, and follows on inevitably from the discussion of risk minimisation versus costs we were already having?

I made and make no assumptions about your setup. I would recommend 3 log members to anyone, for the reasons already stated. And if someone were to say, 'the performance impacts for our particular hardware are excessive', so be it. A recommendation isn't an order, you know.

>Is it a general recommendation? Because you seemed explicitely

> not to like to explain it, it got the character of some kind of: "For
> you it may be the best, if you would better take 3".
>
> At least, the corruption of logs thing was really new to me. An
> interesting thing. Although I still do not know, what this means for
> the running database, not the one I would need to recover some day.
> Does it have an influence? We had some corruptions in database files,
> and we had to recover for more than a whole day.
>
>
>>You are apparently looking for a kick in the teeth if your attitude is 
>>actually anything to go by. But no matter. Perhaps it's just a language 
>>thing. What I've written is based on experience. You are free to ignore 
>>it as much as you want. But one then questions the wisdom of soliciting 
>>the material in a public forum.

>
>
> I'm not shure, if I should be happy to not understand this perfectly.

I think that probably lies at the root of a lot of the trouble.

>>>>If you feel that way about things, of course, you could always set 
>>>>_disable_logging=true, watch your database run like a leaping gazelle, 

>
>
> Sorry, for not reading this conscientous enough. For shure I meant
> archiving, not your parameter.
>
>
>>I assume you are intelligent and capable. I assume you care about your 

>
>
> Oh, man, please tell me, that I have been written so much nonsense,
> that you need to talk with me that way.

Which way? That I assume you are intelligent and capable? You find those thoughts insulting for some reason? Of course, it doesn't help again that you have cut the relevant sentences out. Let me put back in what you snipped half-way through:

"I assume you are intelligent and capable. I assume you care about your data, and would not want to see any of it lost through error, oversight or mishap. I assume you actually want to understand the issues involved.

In which case, stop pursuing an agenda which happens to be wrong. You can dismiss it as "old knowledge" is you wish. But it isn't. Open you ears, and be prepared to listen."

Now, which bit of that do you find insulting? I meant the first paragraph, and I devoutly wish the second.

> I did hope to find some more
> answers about the archiving stuff, because in the manuals of Oracle I
> did not find too much info about the parametrization of this. And now
> here I stand like a dummy...

I don't call you a dummy. But I do think you are appearing to be a troll. Your original question stated "we have 2 members in every redolog group. But in my eyes this seams totally stupid in our configuration". I have tried to point out to you the reasons why multiple members in a group is a good idea regardless of how excellent your hardware redundancy is. I happen to usually recommend 3 members, but it's not written in stone, and the decision ultimately comes down to costs and benefits. But whatever the outcome of the decision, it is most definitely NOT "totally stupid".

You have chosen in subsequent replies to dismiss my experience as being of no account, to dismiss my knowledge on the matter as being "old school", with "the really interesting question" lying elsewhere. And to make a couple of interesting 'cuts' to my post that result in a completely different impression being given that what the entire sentences actually convey.

I suspect it is a language thing, so we should leave it there. You have had your answer, yet you seem curiously reluctant to listen to it.

HJR Received on Mon Nov 29 2004 - 12:18:42 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US