Re: Documentation for reasons to NOT use RAC?
- From: kathy duret <katpopins21@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 19 May 2010 09:40:51 -0700 (PDT)
Sorry this was sent out too fast...
If you have small non critical applications I am not sure why you would bother
with RAC
RAC costs alot of money in terms of software and licenses.
Rac costs more to implement and maintain as you need people qualified to be
able to implement , maintain it, patch it.
You now have added clustered software, VIPS, ASM, Services, Srvctl, complex
datasources, load balancing and all the glory that goes with patching and
maintaining all of it?
And in my opinion, I think RAC still has more downtime than a regular db with a
standby.
There are many patches that still require the whole RAC to be down then
patched. With a normal db you don't have cluster and ASM patches. More
complexity, more bugs, more patches.
You have to have developers would DO understand how to connect to RAC else why
bother. If node 1 goes down and the datasources are all pointing to one, guess
what... apps not failing over. No load balancing. So why did you even bother
with all that expense of the duplicate hardware, software in the first place?
Don't get me wrong, I have RAC and I am not afraid to use it.
But RAC isn't the whole story. You may still need a standby for off site
recovery,
Rac is getting easier to set up and maintain and more rolling patches are
coming out.
Lots of thought and testing needs to go into RAC. For me RAC is mission
critical, large and you can separate apps into services on the nodes PLUS you
need people who can implement and maintain it from the network, sys admins,
dba, developers and managers.
Is it worth it? Depends on your application and how much you can afford to be
down and the company can afford to invest.
My 3 cents worth (it is rac so I threw in an extra penny)
K
--- On Wed, 5/19/10, kathy duret <katpopins21@xxxxxxxxx> wrote:
From: kathy duret <katpopins21@xxxxxxxxx>
Subject: Re: Documentation for reasons to NOT use RAC?
To: oracle-l@xxxxxxxxxxxxx
Date: Wednesday, May 19, 2010, 11:28 AM
Ok now that my name has been called out... I guess I will add my 3 cents worth
1) The decision to go RAC is a BIG decision monetarily, time, skill
If your applications aren't mission critical why would you bother?
If you can get away with a db and standby
--- On Tue, 5/18/10, Yong Huang <yong321@xxxxxxxxx> wrote:
From: Yong Huang <yong321@xxxxxxxxx>
Subject: Re: Documentation for reasons to NOT use RAC?
To: "Tony Adolph" <tony.adolph.dba@xxxxxxxxx>
Cc: oracle-l@xxxxxxxxxxxxx
Date: Tuesday, May 18, 2010, 10:14 PM
> > I don't see how developers should write code differently
>> if the code needs to be deployed to RAC.:
>
> Its not just being TAF/FAN aware, see Gints Plivna's comments
> earlier in this thread.
Tony,
I understand Gints Plivna's and kathy duret's responses at
//www.freelists.org/post/oracle-l/Documentation-for-reasons-to-NOT-use-RAC,23
They both proposed great ideas for application server admins. The only thing
developers should do a little differently is perhaps "Use of parallel in
queries to take advantage of the Rac power", but that's not really RAC-specific.
In short, the developers don't need to do anything special for RAC. DBAs and
mid-tier administrators do.
Yong Huang
--
//www.freelists.org/webpage/oracle-l
Other related posts:
