Re: Educating developers on RAC
- From: Job Miller <jobmiller@xxxxxxxxx>
- To: "development@xxxxxxxxxxxxxxxxx" <development@xxxxxxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 13 Jun 2012 06:24:34 -0700 (PDT)
I've seen some good presentations from Kuassi Mensah over the years:
He co-authored a white paper a couple years ago here that deals with app
failover:
http://www.oracle.com/technetwork/database/app-failover-oracle-database-11g-173323.pdf ;
where he states:
The following rules of thumb or recommendations apply:
1. When using integrated Oracle clients (JDBC, OCI, .Net etc), FAN with FCF is
highly
recommended as it provides immunity from TCP timeouts for in-flight calls, and
eagerly cleans up dead connections from connection pools to minimize
application
exposure to the failure.
2. For - read-only and read-mostly applications, TAF (in conjunction with FAN)
is the
recommended choice; it provides query failover (i.e. it allows active queries
to
continue) without disrupting the application.
3. Java containers, drivers, frameworks, or applications may use FAN API to
directly
manage FAN events themselves. OCI-based containers, drivers, frameworks or
applications (C, C++, OCCI, PreComps, PHP, Ruby, Python, Perl) may use OCI
callbacks to directly manage FAN events themselves.
________________________________
From: Martin Bach <development@xxxxxxxxxxxxxxxxx>
To: oracle-l@xxxxxxxxxxxxx
Sent: Wednesday, June 13, 2012 3:34 AM
Subject: Re: Educating developers on RAC
Hi Gabriel,
I have tried to document this twice so far in my career, and I found
this hugely challanging. In my opinion there are two types of
applications (roughly speaking):
- in house
- off the shelve
There is no clear advantage of one over the other for RAC, but let's
face it: there is hardly an application out there made for RAC. Some
have bolted on some TAF in the connection strings (and then use the jdbc
thin driver), but that's mainly where it ends. In house could be better
in theory one might think, but then your developers may have other
priorities than to change their connection pool to UCP, which they
should. Off the shelve can be brilliant too, but many big ERP systems-if
not owned by Oracle-do not really care about the underlying data "store"
and perform equally bad on all RDBMS.
Back to your developers: Like a friend once said to my great amusement:
do not try to boil the ocean. Keep it simple, unless you start a new
application from scratch. I think it's imperative for RAC to understand
workload mangement. Start with SCANs, VIPs, services. Maybe some TAF is
in order on the service level (srvctl modify service -h). Understanding
connection load balancing, server side load balancing wouldn't hurt
either. One often forgotten item is: how do you fail your application
over to the DR site? DNS changes? Two SCAN addresses in the tnsnames.ora
with failover = yes / load_balance = no, 2 retries and a timeout of 2?
When you are using the DG broker you should be able to receive an event
for a failover operation-your application /could/ in theory take
appropriate action. I have yet to see such an application.
Then you might want to consider external tables for data loads if
applicable, sequeunces and caching them, partitioning (hash!) to reduce
certain concurrency problems. Logically dividing an application into
workloads and assigning services for them also works, and you can even
use dbms_monitor to get usage statistics to charge the business for
using your cluster. ASSM has mostly taken over from freelist group
management and manual segment space management (mainly because it's the
default now), reverse key indexes for monotonically increasing values
can help etc. AQ can be a bit more tricky in RAC too.
The icing on the cake would be how to use connection pools, FAN and FCF.
You can even have session affinity and transaction affinity now, meaning
that similar sessions go to the same node to reduce cache fusion traffic.
<shameless plug>I have written a chapter in a popular RAC book about
this, it was fun doing so</shameless plug>. However I'm realistic enough
to understand that most of the cool stuff won't be implemented, ever.
And how to explain this to developers - I have no idea. Sounds like a 2
week training course with examples. Get them away from hibernate, make
them understand what a database is. Difficult-relational databases
aren't tought any more at universities it seems.
These are just the ones coming to my mind while typing, there certainly
is more to it
Off my soap box now.
Martin Bach
http://martincarstenbach.wordpress.com
On 12/06/2012 17:13, Aragon, Gabriel (GE, Corporate, consultant) wrote:
> (Sending again in plain text)
>
> Hi list,
>
> Well I think the subject speaks for itself, goal is to explain
> developers what should they be expecting when their instances are moved
> to RAC, maybe how the scan works, how rac works, etc , how their queries
> are executed..
>
> Not a RAC training maybe just a quick introducing or features for
> developers doc.. any ideas? Is it any doc already created for this? I
> don't want to invent the wheel.
>
> TIA
> Regards,
> Gabriel
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
