Re: Documentation for reasons to NOT use RAC?
- From: Gints Plivna <gints.plivna@xxxxxxxxx>
- To: TESTAJ3@xxxxxxxxxxxxxx
- Date: Mon, 22 Feb 2010 20:52:53 +0200
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@xxxxxxxxxxxxxx>:
>
> 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"
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
