Re: Help required on Data Guard

DA Morgan wrote:
> Praveen wrote:
>

>> Hi All,
>>
>> Means, there should not be any
>> downtime in any of the locations.
>>
>> Thanks,
>> Praveen

That is either ill-defined vagueness or just rubbish.

Define 'high availability'. If it is taken to mean 'the ability to resume business operations within a few tens of seconds after a catastrophic failure on the principal database, and without loss of committed data', then of course Data Guard is a high availability solution. And a very nice one, too.

> If you seriously need zero downtime

Not even RAC provides that. There would be an instance recovery to perform, after all -during which time, all access to the rows being recovered is blocked. Which, for the users involved, most definitely doesn't feel like zero downtime.

> then you need redundancy in all components from doors to the data center
> to two diesel generators to two independent air conditioning units and,
> without question, RAC.

Have you been taking the marketing pills again? This is complete claptrap, after all.

You, presumably, have worked with RAC databases whose nodes are several tens of kilometres apart, have you?

If you have, you'll be in a minority (of about 1). Most RACs on the planet consist of multiple nodes *in the same server room*. So how that would equate to zero downtime when an earthquake, fire or 9/11 happens, you'll have to explain.

And how many databases are there in a RAC? I'll give you a clue: one. So how much redundancy is there in that? And how many databases are there in the simplest Data Guard configuration. Here's a clue again: two. Meaning that by your own definition "you need redundancy in all components", RAC has less redundancy than Data Guard.

Try and stop glossing matters with trite and simplistic treatments. RAC is most definitley the answer for many, and most definitiely not the answer for many more.

HJR Received on Sat Nov 20 2004 - 21:55:15 CST