RE: RAC for dev env
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <veeeraman@xxxxxxxxx>, "'Guillermo Alan Bort'" <cicciuxdba@xxxxxxxxx>
- Date: Wed, 3 Feb 2010 15:44:00 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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>
Other related posts:
