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: Virtual Machine Setup

Oracle Tips by Burleson Consulting

There is but one recommendation for this level of the configuration. It would be most efficient to allocate database I/O activity disks, spindles or LUNs (logical units) as physical disks think of it as raw devices. Then use Oracle ASM to allocate, manage and control all such devices. There is no reason to add the extra level of overhead because ASM is a perfect solution for virtualization and worth recommending whether you are doing RAC or just single instance databases. In fact, at the Oracle 11g training, the Oracle instructor said that some 60+% of new RAC cluster deployments were choosing ASM, and that even 25% of all general purpose, non-RAC deployments were as well. Because VMware Server ESX is so stripped down, you should also appreciate the free LVM (Logical Volume Manager) and file system capabilities that ASM makes available to your virtualized RAC database and all for no additional cost.

Remaining Steps Same

From here on in the setup process is pretty much the same, i.e. since you have abstracted the lower levels of the configuration, the steps up to this point have covered all the bases. Now the process is like any other multi-RAC node install and configuration process. You will want to verify that each nodes hardware, bios, firmware, operating system or hypervisor, device drivers and optimizations are identical or as close as possible if there are fundamental hardware differences across your RAC nodes. You'll also need either SSH (Secure Shell) or RSH  (Remote Shell) configured so that both the Oracle Universal Installer and Database Configuration Assistant can function for all the nodes.

Other Things that Matter

When asked if other things matter, of course the answer can always be yes. That is just the nature of the beast in the Oracle world. But are there any items that specifically warrant being pointed out? Let us examine a few of the more urgent ones.

First, be careful not to create more than one virtual machine on a specific physical server that services the same RAC database. While there is actually nothing fundamentally wrong with this (refer back to our pseudo-RAC chapter), this should only occur in limited scenarios where you specifically dictate it. For example, one way to dynamically manage or allocate excess capacity for better load balancing might be to create additional RAC nodes across whatever resources are currently available even if that means creating more than one RAC instance on the same physical server. However, it might be wiser to simply allocate additional dynamic resources (e.g. CPU, RAM, priority and such) directly to the RAC instance nodes as necessary. There is software on some virtualization platforms to manage this and, in some cases, to even automate it.

Second, you might want to take some additional time to think about your computing centers network cabling and switch setup. Remember the 200 network items you would have to define in your twenty node RAC cluster? You may want your physical switches to VLAN off segments of traffic. You also might need to plan for more Ethernet segments given the increased complexity and additional moving parts such a virtualization strategy causes. The point is that your network and its wiring may be much more involved and more closely concentrated than you are generally accustomed to being. Who knows it might be that virtualization is the last straw which breaks the camels back, and finally gets you to upgrade to ten gigabit Ethernet.

For no matter what the joke may be about it size really does matter.  It is not uncommon to leverage lower cost components in the virtualized information center. But be very careful not to accidentally create any artificial bottlenecks by sizing hardware without properly accounting for the highly concurrent nature and utilization of all your virtualized resources. Most of us do not yet have enough practical experience in hardware sizing for such heavy usage, so error on the side of caution when in doubt because the entire virtual infrastructure can only be as strong as its weakest link. Hence, there are now many major, hidden interdependencies between your systems. Look again at this picture from earlier this chapter. We have two physical servers each hosting one half of two RAC clusters. This particular solution is more about freedom to allocate resources rather than fault tolerance, so it is a legitimate scenario that you may well encounter. As you think about this diagram below in Figure 8, think about the interconnect traffic and your desire to keep it humming along. That alone will be your examples Achilles heel.

If you try to reduce your now 400 network item count (200 network items per physical server, and two physical servers) and attempt to use fewer network cards or share the private network segment, you might slow down both databases. Furthermore, you might introduce sporadic and thus irreproducible performance issues where one database or its nodes causes side effects on the other RAC database. The fundamental point is virtualization means shared everything and that necessarily means more dependencies outside your normal project scope. In fact, it is not uncommon to relocate entire databases in the virtual world once such performance issues arise. But that is actually the key strategic benefit of this approach:  you can allocate whatever resources, wherever, and whenever they are needed. That increases resource utilization, reduces excess capacity, lowers total hardware costs and even yields greener information centers.

The only other key area that is significantly different is the monitoring, diagnostic and tuning efforts, but that will be addressed in the next two chapters. Just remember that in the virtualized world, you have many more moving parts, and thus, more to watch and/or tweak.


In this chapter, we discussed the real world applicability of virtualized databases specifically, for Oracle RAC. The conclusion was that virtualization and RAC are compatible. Furthermore, that this technology progression is really nothing more than finally realizing the promise of grid. The key areas to concentrate upon were the lower levels of the virtualization technology stack, and expressly to rely upon VMware Server ESX for production use for both performance and scalability reasons. Moreover, we acknowledged that the configuration of key virtual resources at this level is critical, especially when trying to limit any unplanned consequences from interdependencies. Finally, that the front and rear end processes, such as planning and monitoring, require additional effort. But not to worry, because in the true virtualized world where everything is just a resource, things can be moved as needed. So the flexibility inherent within virtualization can sometimes be the single most valuable reward and worth the price of admission all by itself.

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.