Re: Documentation for reasons to NOT use RAC?
- From: Tony Adolph <tony.adolph.dba@xxxxxxxxx>
- To: Yong Huang <yong321@xxxxxxxxx>
- Date: Thu, 20 May 2010 10:03:21 +1200
Hi Yong,
Perhaps designers then, at least thats what I think the posters are
referring to and certainly what I am.
The application would lend itself better to RAC (scale better/well) if its
data is logically partitioned and could make good make use of services. By
partitioning, I don't mean at the table level here, but at the level Gints
Plivna was referring to.
But for this to happen, its the developers/designers that need to be
thinking RAC.
Tony
On Wed, May 19, 2010 at 3:14 PM, Yong Huang <yong321@xxxxxxxxx> wrote:
> > > 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
>
>
>
>
Other related posts:
