Re: Educating developers on RAC

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
> --
> http://www.freelists.org/webpage/oracle-l
>
>



--
http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l

Other related posts: