Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







VMware: True RAC Setup

Oracle Tips by Burleson Consulting


Up until now we have been examining virtualization of Oracle databases in two key modes: single instance deployments and pseudo-RAC deployments on a single virtual node. But with the obvious future slant of companies moving more aggressively towards utilizing RAC to leverage lower cost hardware, we need to explore doing true RAC in the virtual world as well. That leads us first to decide whether RAC and virtualization even belong together in the same sentence.

RAC and VM Compatibility

Some people are of the opinion that Oracle RAC and grid architecture are exclusive of virtualization. In fact, many of those people would go so far as to argue that database servers in general should not ever be virtualized. The thought is that database servers are so specialized, high demand (especially for I/O) and mission critical that they are not reasonable candidates for virtualization. That might have been true a year or two ago when virtualization was still relatively new and the hardware had not branched so pervasively into multi-core CPUs with tons of cheap memory. But times have changed and so have the limitations, if they ever actually existed at all.

Most database servers these days are overkill in terms of CPU capacity versus their average needs and often more than their peak needs as well. So, as has always been true, I/O is your limiting factor of gravest concern when dealing with databases. Even with today's powerful SAN, NAS and iSCSI disk subsystems, I/O still remains the greatest limiting factor in most cases. You still have higher bandwidth and capacity on the CPU and memory side of the equation. That is why the average database server has extra and, therefore, underutilized capacity.

What has happened is that the fundamental grid concept has been fully realized through virtualization. You really can afford to treat servers, even database servers, as nothing more than resources that can be allocated and load balanced as necessary. You no longer have to build stand-alone islands of server functionality, so you can better utilize all of your computing resources. And in the process, actually lower your total hardware costs to boot. Plus, you get a greener solution as well, which is highly desirable these days. It is truly a win-win scenario from many different angles and worth doing.

Here is a diagram (Figure 1) that just a few years ago might not have seemed too reasonable, but which has become more comfortable in the industry today. Look closely at what this picture below describes mixing database platforms and database instances across your virtualized I/O subsystem. This actually has been done for quite some time and people do not think too much about such configurations anymore other than generally agreeing that gone are the days of walking into a server room and pointing to your databases disks. So now assume for sake of argument that we can all generally agree on this picture. Note that while the I/O workload is mixed (SQL Server and Oracle on same disks); you still have the database platforms physically separated across physical servers.

Figure 1:  Mixing Database Platforms and Instances 1 Side

So what happens if you make the following very minor change to the diagram as shown in Figure 2 (next page) and now allow mixing the database platforms on the left hand side as well? Some of the people I mentioned earlier might argue that this is the first step onto a very slippery slope. I simply believe that this next level of abstraction and virtualization has already been generally accepted and you can both effectively and efficiently mix database platforms and database instances across your hardware on both sides of the equation. So please look closely at this picture, because the water is going to be muddied up a wee bit more.

Figure 2:  Mixing Database Platforms and Instances on Both Sides

The next logical step along this virtualization progression might well be something along the lines of the diagram on the following page (Figure 3). At first glance this picture may seem odd:  why would anyone host multiple RAC nodes on the same physical servers like this? But do not jump too quickly to any conclusions. If all you are primarily worried about is load balancing, then what is really wrong with this concept? My desktop computer has a quad core CPU with 8 GB memory and I built it for about $500. Many of today's servers come with dual quad core CPUs and at least 8 GB of memory with eight core and greater CPUs already being designed for next year and beyond. This growth of the gap between CPU vs. I/O bandwidth really shows no indication of slowing anytime soon. So this picture becomes a reasonable reality in the very near future, if it is not already. One should not arbitrarily try to stand in the way of hardware evolutions or revolutions occurring around us. You should embrace the picture below as being both reasonable and likely to occur sometime soon.

Thus, RAC and virtualization are indeed compatible and make sense in many and ever growing scenarios. From here, you will now learn how one would construct such a setup. As with the prior chapter, I will keep the instructions to a minimum under the assumption that you have read the prior two chapters and fully understood all the steps therein explained. Feel free to return to those chapters as you read the rest of this chapter.

This is an excerpt from
Oracle on VMWare: Expert tips for database virtualization by Rampant TechPress.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.