Re: RAC and Data Guard Configuration Question

Hi,

maybe it's an option to use huge nodes with a better peak performance. This will be useful for the single-instance-recovery as well.

But it's not cheaper, by far not.

Martin

Dan Norris schrieb:
> Chris,
>
> As Martin pointed out, for the "normal" case where DR is just performing
> recovery, only one instance will be used to apply all redo. However, the
> case you should be more concerned about is what happens when you
> actually activate the DR site and try to run production there. If your
> production workload requires 4 or 5 nodes in your current 6-node
> production site, then trying to place that workload on 3 nodes will
> result in a complete outage and negate any DR benefits you were trying
> to achieve. In fact, it's almost worse since you'll be trying to run on
> the DR site, failing, and likely will be troubleshooting the resulting
> issues on the DR site. Meanwhile, no one is working on trying to get the
> primary production site back up and running.
>
> In no case would I consider running two instances on the DR servers
> since that will probably just make things worse by carving up each
> server's resources (CPU, RAM, I/O) for two instances. I don't think I'd
> worry about instance naming since all applications should connect via
> services (where service_name <> instance_name) anyway. I would use the
> same service names on the DR site as I have on production, though.
> Shouldn't be a requirement, just might make things easier.
>
> GL!
>
> Dan
>
> Chris Dunscombe wrote:

>> <snip>
>> On the DR site we only have 3 nodes, we'd like 6 but 3 is all that
>> we're going
>> to get.
>>
>> The question is should we configure DR to have 1 instance per node
>> (same as
>> production) but this leaves only a total of 3 instances and hence 3
>> redundant
>> UNDO tablespaces etc or have 2 instances per node?
>>
>> Also is it best practice to have the instance names on DR the same as in
>> production.
>>
>> Any experiences, advice, "best practice" etc. for this is most welcome.
>>   

-- 
Usn's IT Blog for Linux, Oracle, Asterisk
www.usn-it.de

--
http://www.freelists.org/webpage/oracle-l