RE: RAC and Data Guard Configuration Question
- From: "Goulet, Dick" <richard.goulet@xxxxxxxxxxxxx>
- To: <usn@xxxxxxxxx>, <dannorris@xxxxxxxxxxxxx>
- Date: Wed, 7 May 2008 11:23:45 -0400
Step number one, what is the purpose of your DR site? Is it supposed to
handle 100% of normal expected load or something less? The answer,
which has to come from management, with end user buy in, will tell you
if 3 nodes are sufficient or you really need 6.
______________________________________________________________
Dick Goulet / Capgemini
North America P&C / East Business Unit
Senior Oracle DBA / Hosting
Office: 508.573.1978 / Mobile: 508.742.5795 / www.capgemini.com
Fax: 508.229.2019 / Email: richard.goulet@xxxxxxxxxxxxx
45 Bartlett St. / Marlborough, MA 01752
Together: the Collaborative Business Experience
______________________________________________________________
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Martin Klier
Sent: Wednesday, May 07, 2008 9:32 AM
To: dannorris@xxxxxxxxxxxxx
Cc: chris.dunscombe@xxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: 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.
>>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Usn's IT Blog for Linux, Oracle, Asterisk
www.usn-it.de
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
