On Mon, Mar 10, 2014 at 7:49 AM, Freek D'Hooge <freek.dhooge@xxxxxxxxx> 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@xxxxxxxxx>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@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. > > >