Collaborate Wrapup, RAC 11g/VMware Lab

So Collaborate is over and I’m back in Chicago… home sweet home. I thoroughly enjoyed the week in Denver, in spite of the snow! Thursday, the last day, was especially fun.

First was a panel debate “To RAC or Not To RAC: What’s Best for HA.” Dan Norris invited me to participate in this panel along with Alex Gorbachev (Pythian), Neil Greene (Predictive Technologies) and Matt Zito (GridApp) – I certainly felt privileged to take part. Here are a few of the things that I took away from the debate… feel free to discuss:

• There are no silver bullets. And if there were, RAC wouldn’t be one. :) Many RAC implementation problems can be traced to poorly set expectations; knowing your requirements and RAC’s capabilities will go a long way towards making any project successful.

• RAC really shines when solving scalability problems. The simple act of moving an application from single-instance to RAC is more likely to improve throughput than service time. (Of course, improvement isn’t guaranteed: as Dan pointed out during our conversation it depends on where the bottlenecks are.)

• There are two major application design areas that need to be addressed when moving to RAC: (1) scalability and (2) connectivity. (There are other issues too but these are probably the biggest.) Regarding scalability, small inefficiencies will become major bottlenecks when you move your app to a cluster. Look out for any points of contention or serialization whether they’re logical (like an ID field that must be sequential) or physical (like free space management). On the connectivity front, there is both initial connection and load balancing to worry about.

• When it comes to HA, I personally think that failover clusters should get more serious consideration then they do. I think that there are essentially two differences between a failover cluster and RAC: (1) a few minutes of downtown each year, and (2) the prices for licenses – probably tens or hundreds of thousands of dollars minimum. You can even still use TAF with a failover cluster – it’s not much different than using it with Data Guard. The few apps that need extremely fast failover often can’t even wait a few minutes – they commonly run parallel systems in tandem to avoid failover altogether. Most other apps can tolerate an extra 60 seconds during failover, if we’re honest.

At any rate, I thought that the debate was informative and that Alex, Neil and Matt were each very well spoken. Alex also has a good write-up on his Pythian blog.

After the debate panel I slipped over to hear Alex’s 11g New Features presentation (which was actually Christo‘s presentation but Alex delivered it since Christo wasn’t able to fly over from Dubai). The presentation went great even though Alex hadn’t written it himself and I snapped this pic with my cell phone while I was there.

Alex’s session was the last one of the conference, so afterwards we grabbed a bite to eat and spent some time catching up. Dan joined us a bit later and then we made our way to the airport to have dinner and catch our respective flights. Thanks for the great company guys!

RAC 11g/VMware Lab

One last thing: on Wednesday we had a lab session where we went through the step-by-step process of setting up 11g RAC in a VMware Server virtual environment with OEL5 and ASM. I have uploaded the class to the publications section of this website.

If you have a 2Ghz processor, 2GB of memory and 20G of disk space, then you can download all of the software for free and try out this lab for yourself:

• VMware Server – http://www.vmware.com/download/server/
• Oracle Enterprise Linux (OEL) 5 – http://edelivery.oracle.com/linux
• Oracle Database Enterprise Edition 11g – http://www.oracle.com/technology/software/products/database/index.html