Re: RAC or Large SMP...?

> You mention your company whent through 6 months of hell with RAC and
> 9i. What happened after that 6 months? Did things settle down or was the
> plug pulled? Do you know if the problems were lack of skills/experience,
> lack of resources or just due to adopting the wrong platform?

The problems we hit with RAC happened before I joined the company, but my impression is that the issues were caused by a combination of the following:

Implementing RAC on an immature version (9i) Lack of knowledge and experience
Insufficient testing

The RAC cluster would freeze up regularly and no-one could diagnose the cause of the problem. This was a severe problem because the application has very strict uptime requirements and RAC was actually significantly reducing the availability.

After 6 months the database was converted to single instance and RAC was done away with.

> For me, the difference is that in our environment, we have pretty good
> control over how the applications are configured and in many cases,
> developed. For example, if we found an application that was heavily
> based on AQ was performing poorly, we could re-configure and deploy with
> a queue on each node. On the other hand, if we were based on an SMP
> system and we determine that the problem was a critical component that
> was written in such a way that it was only able to use a single core,
> unless its a component we developed, there is little we can do, either
> because we don't have the sources or we don't have the skills/resources
> to change it.

Luckily we have 100% control over how the application is written/ architected. Also we have a very strong and open minded development team which is actually pretty rare in my experience.

> We only started migrating to RAC 12 months ago. So far, the result has
> been very positive. Of course, that dreaded cluster lock-up may be just
> around the corner, but so far we have had much better uptime stats,
> improved performance and all round better experience. Our annual support
> and license costs are so much lower that we are probably going to get
> two additional staff (because tehre hasn't been a sys admin maintenance
> blow-out, (there is some debate regarding whether the additional staff
> will be DBAs, sys admins or developers!). We are lucky in that we do
> have a couple of excellent DBAs and sys admins. To be honest, part of
> the high maintenance costs was due to the age of some of our hardware,
> which was old because replacement costs were extremely high. Moving away
> form expensive 'boom boxes' was the right decision for us.

This is the kind of feedback that I was hoping for when I posted the original question. Its good to hear about positive experiences with RAC.
I'm confident that whatever architecture we chose we have the right team to make it work. We have very experienced people in the sys admin, networking and database roles and a development team with enough knowledge and experience to modify the application to suit the configuration if required.

If we have a staging environment which can be used to test out patch installations, application upgrades, and various failure scenarios then I'm confident that we could make RAC work well for us. Based on the research I've been doing, it looks as though RAC has matured into a stable product since its release (in 9i).

Thanks again for your advice and feedback.

Cheers Received on Sun Oct 12 2008 - 18:25:53 CDT