Creating the empty virtual machine was the quick and easy part. Now as a DBA deploying an Oracle database in a virtual world, it is the customization of the VM configuration parameters that we need to address next. Like the section before, limits posed at the VM settings level often cannot be overcome by operating system or database tuning efforts. Once again, it is extremely important to get these settings right the very first time, so do not skip or make light of this step either!

There are a lot of configuration settings to cover - so here we go!

The first virtual machine setting that must be defined is how much memory to allocate to the virtual machine. In this case, you can see the minimum (32MB), recommended (384MB), and maximum permissible (3580MB) memory allocations shown below in Figure 5 (note that the maximum is based upon the host server's memory setting covered in the prior chapter).  Since I know that I want this Red Hat Linux guest OS to support running two Oracle instances, their background processes and the requisite number of dedicated server process for my development and test databases, I have set aside two gigabytes for my virtual machine.

Figure 5:  Virtual Machine Settings

Some other key performance related settings to note and adjust for your specific hardware environment and business database needs are:

•  ?Hardware? tab

  • ?Hard Disk? type=SCSI (more portable than IDE)

  •  ?Hard Disk? mode=independent & persistent (no overhead for snapshot & disk I/Os occurring immediately)

  • Defragment the virtual disk via the VMware defragment utility once the OS and Oracle are installed

  • CD-ROM ?Connect at power on?=unchecked (default =checked can slow down both VMware host &  guest)

  •  ?Number of processors? - remember this during guest OS install in case options exist (e.g. Linux SMP kernel)

•  ?Options? tab

  • If only one guest active at any time on host, then set ?Enter full screen mode after powering on?=checked (requires less resources to manage just one active GUI)

  •  ?Disable Snapshots?=checked (default=unchecked can slow down VM, it's like running database with archive log mode enabled - i.e. more I/O on the virtual server)

  • ?Disable memory page trimming?=checked (default=unchecked may impact I/O intensive workloads on guests, such as that by Oracle databases)

  • ?Run with debugging information?=unchecked (default and recommended for optimal performance)

  • ?Log virtual machine progress periodically?=unchecked (default and recommended for optimal performance)

You are not done just yet. So far you have created the base virtual machine and customized it for some very universal database usage scenarios. But now you need to add disk space to actually contain your databases? data. In other words, you now need disk drives to provide tablespace allocation regardless of whether  you are using file systems, clustered file systems, virtual file systems, raw devices or Oracle ASM.

You can utilize the hardware tab's ?Add?? button to create those additional virtual disks, resulting in the key screen snapshot shown below in Figure 6, as well as a few others much like the disk setting screens that have already been shown while creating the virtual machine's first disk drive.

Figure 6:  Creating a New Virtual Disk

You simply choose to create a ?Hard Disk?, choose its nature (physical vs. virtual), its type (IDE vs. SCSI), its size and allocation strategy (pre-allocate vs. dynamic growth). The only new part is the second question, which is what nature of disk drive. While an old tried and true DBA paradigm has been to prefer physical or raw devices for optimal performance, that choice would fly contrary to your keep it ?generic? and portable ideals. So only if you are hell bent on performance at all costs, no matter what, should you choose physical disk, which permits you to allocate an entire disk or partition to a virtual disk.

However, we do perform one virtual disk creation task differently now that we are allocating disk space for Oracle data files. Namely, we choose to preallocate those virtual disks as shown below in Figure 7.

Figure 7:  Allocating Disk Space

The reason is quite simple - Oracle preallocates or formats disk space allocated to tablespaces with all the requisite blocks to populate the data file for its given size. So if  you know you are going to allocate 30 GB to the tablespace's data file, then you might as well preallocate it at the virtual level since Oracle is just going to format all that space immediately anyhow. And even if you are going to stop short, perhaps by creating the data file at only 20GB, why pay twice for the data file to extend dynamically at both the virtual and Oracle levels? Once is sufficient!

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