Re: 2 Exadatas for production + disaster recovery + dev/test
Date: Thu, 6 Mar 2014 14:13:00 -0600
Message-ID: <CAFU3ey5b=bpQcdEQV+Pa-eW7y84Tw8WcayPUkrQ+ZRJVrUmz1g_at_mail.gmail.com>
I don't know what I can add other than to say that the configuration you're considering is the same as what we have been running at the U of MN for the last three years on a pair of X2-2 half racks. We run each of the prod databases as two-node RAC, and their data guard DR counterparts on the dev/test cluster are two-node. The biggest drawback with this is that we have full copies of production chewing up space on the dev/test cluster, but I don't consider that to be much of a drawback. You'll use up space no matter where you put them. And with the larger disk sizes on your X4 machines, it should be even less of a drawback.
We do not use resource manager to isolate the DR workloads from the dev/test workloads. Not to say that we couldn't, but it is not a requirement of our DR plan. In the event of a DR switch, we would manually shut down non-critical services to make sure resources are available for production.
You could always run your DR databases on another server or a vm somewhere, but in my opinion that does not gain you anything other than yet another server to administer.
I suppose one question you would want to address is the proximity of your two data centers and the type of interface you'll be employing for your redo transport. You can configure the 4th 1GbE interface on the db nodes for backup and redo traffic. But if you have 10GbE as an option it might be better to use one of those interfaces. It really depends on your specific layout and what you have available for networking. We run everything over a single 1G interface without issues. In fact, we have Advanced Compression option so we could be using redo compression, but it is not worth the effort if we don't have a problem. Your mileage may vary...
-- Andy Wattenhofer Manager, Database Administration University of Minnesota On Thu, Mar 6, 2014 at 9:55 AM, Stephens, Chris <Chris.Stephens_at_adm.com>wrote:Received on Thu Mar 06 2014 - 21:13:00 CET
> After an incredibly long wait, Exadata is finally heading this way. Two
> X4-2 quarter racks.
>
>
>
> Management is thinking about using 1 exa for production disaster recovery
> + dev/test environments. My gut reaction was … ugh … but now that I think
> about it, I’m having troubles justifying no disaster recovery and 1
> production exa + 1 dev/test exa. Oracle will be doing all the patching so
> that’s not something I/we’ll have to worry about. Initially, the database
> environment will be miniscule compared to the horsepower of these machines
> and Oracle has plenty of workload partitioning features that would allow us
> to isolate the disaster recovery activity from the dev/test activity.
>
>
>
> There is a roadmap in place to expand the Exadata environment assuming all
> goes well so this will only be temporary (relatively speaking).
>
>
>
> At this point, we don’t really know which databases/applications will
> initially transition to the Exadata environment so this may or may not even
> be a choice for us to make. It may be that disaster recovery is a
> requirement and we’ll just have to make it work for the time being.
>
>
>
> Anyways, I figured with all the expertise on oracle-l, I’d throw this out
> there and look for some advantages/disadvantages, gotcha’s, things we’ll
> need to consider and overall comments.
>
>
>
> Thanks for any input.
>
>
>
> Chris
>
>
>
> CONFIDENTIALITY NOTICE:
> This message is intended for the use of the individual or entity to which
> it is addressed and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by email reply.
>
>
>
-- http://www.freelists.org/webpage/oracle-l