Think of the virtual machine (VM) as your planning-level hardware platform. Most DBAs would historically have had input or feedback on hardware platform selection and sometimes even work with hardware vendors to properly size a machine for its intended database demands. Hence, DBAs should be interested in defining the VM configuration parameters for these settings will define the hardware universe within which the guest operating system will function. If a limit is posed at the VM settings level, there will be little to no operating system or database tuning which can compensate for these selections. It is that important, so do not skip or make light of this step!

So now we will examine the process of defining a VM and the options presented which have significant database performance ramifications. The first step to creating the VM is to specify what the guest operating system will be as shown below in Figure 1.

Figure 1:  Guest Operating System Choices

This step seems fairly straightforward. But remember your mantra of erring on the side of optimism. Most servers? CPUs are 64-bits these days, so why limit yourself to 32-bits and its restrictive memory limitations? Unless you know of a specific hardware or software incompatibility, go with 64-bit operating systems. This includes Windows 2003 Enterprise Edition R2 because there is an optimized version of the Oracle database for that specific platform.

The second step is also very simple and relatively straightforward. You specify the name and location of the virtual machine (i.e. its metadata and location of its base install for the OS). This step is shown below in Figure 2.

Figure 2:  Naming the Virtual Machine

The only consideration here is to name the VM something that is both appropriate and memorable and to place this information in a place that is easy to backup or zip. The default is to place this information in ?My Documents\My Virtual Machines?. But like many default settings, it is not advisable to use this value. It is much better to define a standard for your organization, such as:

• Windows                      D:\Virtual Machines

• Linux/Unix                   /VirtualMachines

This means that anybody working on the VM infrastructure will know exactly where to find VM images regardless of the host operating system. In all the above cases, it is also advisable to place these VM images on a second, non-system and non-swap disk drive. I?ll cover placement of the actual database content files later in this chapter.

The third step covers networking. While VMware offers many options, it is advisable to again stick with one enterprise wide standard that is easy to implement, generally accessible, readily remembered and straightforwardly portable. The best choice here is NAT: Network Address Translation, as shown on the next page (Figure 3).

Figure 3:  Network Type

Think of NAT as simply DHCP (Dynamic Host Configuration Protocol) between your host server and its guest operating systems. That means it is both generally accessible and readily portable. Plus, it is really nothing more than an extension of an existing network technology standard (i.e. DHCP) already in use by many organizations. By using a network technology based upon abstraction, you achieve a very logical and natural fit to your virtualized environment.

A logical question is ?why none of the other choices??. The fourth choice, no network, obviously makes little sense since an Oracle database needs to be accessible to the outside world. The first choice, bridged network, requires each guest to have its own IP address and many organizations have tried to move away from this network infrastructure model for both security and manageability reasons. The third choice, host-only network, could be used, but only under the following circumstances: the host server implements DHCP to route/redirect public network traffic to its own private network. But now you are assuming a host operating system that readily provides such capability - and further assuming no hypervisor. Both assumptions fly contrary to our keep it ?generic? and portable ideals.

The fourth step is to create the disk space necessary to hold the guest operating system base install (and just that space), as shown in Figure 4.

Figure 4: Creating Disk Capacity

You should choose the disk capacity to hold your guest operating system install, swap space, OS patches or updates, temporary work space, and Oracle install. With disk space being so cheap these days, err on the side of too big. I find that most operating systems and Oracle can fit nicely in 30-40 GBs of disk space and the cost for this allocation amount is acceptable, even if it does err on the side of being, relatively speaking, excessively wasteful.

During this fourth step, we encounter our first obvious and critical performance alternative: preallocate or virtually allocate the disk space? Since I do not recommend placing the operating system files and actual database content (i.e. table and index file) on the same virtual disk, this question is somewhat simpler. The minimal performance gain for pre-allocating the operating system disk is generally offset by the improved portability of not requiring a specified minimum size. But with cheap disk space and such a relatively small size here, it is your call. There is just not enough ?blood in the turnip? to overly concentrate on optimizing this aspect further.

Now you have created your basic virtual machine.  Note that not only are VMware virtual machines portable across any of their virtualization products, but numerous competitors offer the ability to import VMware virtual machines into their products? technology due to VMware's commanding market share.

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