Re: 2 Exadatas for production + disaster recovery + dev/test

From: Andy Wattenhofer <watt0012_at_umn.edu>
Date: Mon, 10 Mar 2014 09:34:47 -0500
Message-ID: <CAFU3ey6uHK=3rE5ZnOPRGYWYJSC0HjQpgjnmYz7-dk08UJtpHQ_at_mail.gmail.com>

On Mon, Mar 10, 2014 at 7:49 AM, Freek D'Hooge <freek.dhooge_at_gmail.com> wrote:

> 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).

Patching the standby first is supported, as outlined in MOS doc *1265700.1: Oracle Patch Assurance - Data Guard Standby-First Patch Apply*. That doc and the Exadata bundle readmes also indicate that standby-first patch apply is supported for Exadata bundles.

The scenario is that you install the patch binaries on your dev/test/qa/DR cluster but you only run catbundle in the dev/test/qa databases. The DR databases receive catbundle updates through redo transport after you patch the prod cluster and run catbundle in the prod databases.

-- 
Andy Wattenhofer
Manager, Database Administration
University of Minnesota

On Mon, Mar 10, 2014 at 7:49 AM, Freek D'Hooge <freek.dhooge_at_gmail.com>wrote:



>  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_at_exitas.be

> 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.

>

>

>


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

Received on Mon Mar 10 2014 - 15:34:47 CET