Re: Documentation for reasons to NOT use RAC?
- From: kathy duret <katpopins21@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 19 May 2010 09:28:19 -0700 (PDT)
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:
