Re: Documentation for reasons to NOT use RAC?
- From: Yong Huang <yong321@xxxxxxxxx>
- To: Gints Plivna <gints.plivna@xxxxxxxxx>
- Date: Wed, 19 May 2010 07:24:56 -0700 (PDT)
> From: Gints Plivna <gints.plivna@xxxxxxxxx>
>
> I'm not sure what do you mean by word
> "Developers". If these are just
> plain coders building sql/pl/sql/whatever code according to
> spec then
> probably RAC is not so significant. On the other hand
> normally for new
> systems there is such a role like system architect. He has
> to think
> about the app and avoid serialization points (for example
> sessions
> table which is modified after each request from ten nodes
> for
> hundreds/thousands of users) as much as possible.
In some shops, a system architect is a separate person that does not write
code. In others, he does. Even in the second case, a system architect keeps
concurrency and scalability in mind regardless RAC or not.
This discussion has become one that emphasizes performance and scalability to
the developers. That would be an interesting discussion but is irrelevant here.
I'm asking what the developers should do differently if the database is RAC
instead of non-RAC. So far, changing code to FAN-aware is the only valid one.
Managing connection pools is not a developer's duty unless the connection pool
code is written by him. In a medium to large shop, division of labor is clear.
Admins can help developers tune SQLs and competent developers can suggest to
admins on configuration changes. But they're mostly advisories, not their duty.
Other than code change for FAN, one other change specifically due to RAC is
when the code references v$ views (and for reason of weird "buggy" Oracle
behavior such as dba_jobs_running not showing jobs on other instances). This
includes "sessions table which is modified after each request". If the table
used to record v$session.sid, it must record inst_id now. Code that reads data
that differs depending on whether it's RAC is rare.
Yong Huang
--
//www.freelists.org/webpage/oracle-l
Other related posts:
