Re: Documentation for reasons to NOT use RAC?

From: Gints Plivna <gints.plivna_at_gmail.com>
Date: Mon, 22 Feb 2010 20:52:53 +0200
Message-ID: <6e49b6d01002221052l687e8a70rcd5b7303168927e1_at_mail.gmail.com>



As many have already mentioned paper by Mogens, I can only tell my initial experience with RAC. About 5 years ago we developed apllication for Latvian population register. We created the app without any thinking about RAC and deployed it on 3 nodes using load balancing. When looking at wait events for the whole system top events were all due to global cache (gc) events. Only then I started to dig deeper about RAC and gather more info how to avoid that. So we were happy enough that our app consisted mainly of 3 different parts, online users, reports and users working through APIs. I proposed the idea to place each part of app on different node, as a result without any other tuning we got obvious performance increase. Unfortunately noone measured precisely, so I cannot tell how much it was but users were quite happy :) Also most of gc waits were gone. So I practically experienced myself that app for RAC HAVE TO BE DEVELOPED with RAC in mind. Accidentally we were lucky enough to have 3 nodes and 3 diffferent parts of app, so the result for us was positive. I assume not all may be so lucky, not all apps are developed with RAC in mind, so at least performance may be worse with it.

On the other hand you haven't said why such an idea? What is the reason for that? I like to compare databases with cars. For example if someone wants to deliver pizzas in a city it is quite strange to use 4WD SUV, at least here in Riga they use Smarts (http://en.wikipedia.org/wiki/Smart_(automobile)). I suppose there is valid business reason behind that. So I think the same reasons should be applied also for databases.

Gints Plivna
http://www.gplivna.eu

2010/2/22 <TESTAJ3_at_nationwide.com>:
>
> I'm being pulled into a meeting later this morning to answer why we
> shouldn't put every db in RAC?  Any white papers etc, stating why its a bad
> idea?
>
> thanks, joe
>
> _______________________________________
> Joe Testa, Oracle Certified Professional
> Senior Engineering & Administration Lead
> (Work) 614-677-1668
> (Cell) 614-312-6715
>
> Interested in helping out your marriage?
> Ask me about "Weekend to Remember"
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Feb 22 2010 - 12:52:53 CST

Original text of this message