Re: Educating developers on RAC

From: Martin Bach <development_at_the-playground.de>
Date: Wed, 13 Jun 2012 08:34:05 +0100
Message-ID: <4FD8426D.9000108_at_the-playground.de>



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
Received on Wed Jun 13 2012 - 02:34:05 CDT

Original text of this message