Re: RAC for dev env

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Wed, 3 Feb 2010 15:10:48 -0600
Message-ID: <ad3aa4c91002031310k4c27d259n5ebc2e5195b1fd1f_at_mail.gmail.com>

Are you using enterprise or standard edition? Depending on feature usage, is it possible for you to save money by using SE on a dev/test cluster set up with couple of VM's? Even if you need some EE features, it might be possible to test some features on an SE cluster. That would be better than no testing at all.

On Wed, Feb 3, 2010 at 2:44 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

> So I believe your management dictated constraints are: RAC for prod,
> single instance databases for everything else.
>
>
>
> I would review the following points in written form at the highest level
> in your company to which you have access:
>
>
>
> Do you have a business continuation site? (That is, a site where you intend
> to be able to quickly move operations and key personnel in the event of
> something going splat at your primary site and actually attempt to continue
> business as if no incident had taken place.)
>
>
>
> If so, and you intend to continue all operations as usual AND you actually
> need RAC in the first place, then your business continuation site also needs
> to be RAC. So it is your responsibility to inform management that if they
> think operations at the business continuation site will be normal, then it
> needs to be RAC.
>
>
>
> Do you have a data recovery site? (That is, a site where you have Dataguard
> or some other near realtime remote depository of data from which your
> transactions up to very close or to the point of “SPLAT!” can be
> constructed.) As distinct from business continuation, that doesn’t really
> need to be RAC.
>
>
>
> Can you tolerate not being able to test software that affects the “cluster”
> pieces of the RAC stack? If you think so, then make sure management
> understands that even if you test patches and upgrades on single instance
> databases ‘til the cows come home, something might go SPLAT! when it is
> applied to the multiple instance environment that worked fine on a single
> instance. So this is where you lobby for at least one test environment that
> matches production in number of nodes, exact OS and other software at the
> start of any patch or upgrade test. Ideally the nodes are configured to
> match production and then the test is suitable for capacity verification as
> well as preventing patch surprise.
>
>
>
> Being able to minimize the chances of “patch surprise” on the production
> database is probably a minimum requirement for compliance with various types
> of legal and fiduciary responsibilities at most publicly traded companies.
>
>
>
> You really can probably live with single node instances for everything
> else. And as you’ve alluded, you might simply be told “No.” in consideration
> of the above negotiating points. If you’re clear in your presentation of the
> limitations and the potential pitfalls, then you have adequately discharged
> your responbility to inform management of what they have and what they don’t
> have.
>
>
>
> Regards,
>
>
>
> mwf
>
>
> ------------------------------
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Ram Raman
> *Sent:* Tuesday, February 02, 2010 10:37 PM
> *To:* Guillermo Alan Bort
> *Cc:* Thomas Roach; ORACLE-L
> *Subject:* Re: RAC for dev env
>
>
>
>
>
> Thanks for all your inputs. I am aware of the issues that the decision can
> create, but that is where we stand. I have to work within those parameters,
> so I want to know if there is a way to do that.
>
>
>
> <snip>
>
>
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

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

Received on Wed Feb 03 2010 - 15:10:48 CST