Re: 2 Exadatas for production + disaster recovery + dev/test
- From: Freek D'Hooge <freek.dhooge@xxxxxxxxx>
- To: Chris.Stephens@xxxxxxx
- Date: Mon, 10 Mar 2014 13:49:04 +0100
Chris,
If you don't use high redundancy on the ASM layer (and as you are on a
1/4 rack, you can't do high redundancy for the diskgroup containing the
ocr / voting disks), I don't think Oracle will be willing to perform
rolling updates on the storage servers.
This means that a complete cluster downtime is required when rolling out
(storage) patches.
Depending on the business requirements that would make an argument to
actually have a DR environment to which you can switch to during
patching.
An argument contra would be that when you want to test an exadata patch,
it will affect your ability to failover to this environment (prod is
then running on a different version).
If the RTO / RPO requirements for your databases do not require a
disaster recovery environment, but it is a nice to have to limit
(patching) downtimes, I would have no problem combining test/dev with DR
(and use IORM and instance caging to set priorities).
If they do have very strict requirements, I would try to keep them
separated.
But in the end, it is all about the money. And Exadata is not cheap...
Management must just be aware of the consequences of certain choices.
Kind regards,
--
Freek D'Hooge
Exitas NV
Senior Oracle DBA
email: freek.dhooge@xxxxxxxxx
tel +32(03) 443 12 38
http://www.exitas.be
On do, 2014-03-06 at 09:55 -0600, Stephens, Chris wrote:
> 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.
>
>
Other related posts:
