Virtualization Suggestions

Assuming that you have the typical recent or last generation notebook PC (i.e. one with a dual core CPU and say a max 4 GB of RAM). Here’s what can we do to the database in order to obtain optimal performance (for this platform only that is).
  1. Make sure that your notebook's firmware or BIOS has “virtualization support” turned on. This will enable your CPU and virtualization software to work more efficiently together.
     
  2. Upgrade your notebook's memory to the maximum allowed – e.g. 4GB. It's a sub $100 upgrade that's quite easy to do and will yield the greatest improvement possible.
     
  3. Upgrade your notebook's hard disk to a 7200 RPM model. This too is a sub-$100 upgrade that's very easy to do and will yield a fairly noticeable overall speed increase.
     
  4. Run a 64-bit host operating system such as Windows XP 64-bit. When you instead run a 32-bit host operating system such as Windows XP 32-bit, your machine will only see and use between 3.0 and 3.5 GB of RAM (depending on your notebook's chip set). That means you're effectively wasting anywhere from 13% to 25% of your memory.
     
  5. Consider eliminating the host operating system's swap file and instead live inside your memory available. You may only be able to run one or two VM's, but they will operate much faster than if they had to swap on a single notebook disk drive.
     
  6. Eliminate all unnecessary host operating system services or daemons. Do a web search for your specific host operating system's excesses and turn them off. For example disable the “Window's Indexing” service. There are numerous such services and daemons that are all on by default.
     
  7. Do not run your VM's off a USB disk drive – USB's bandwidth is too slow. If you must utilize an external drive, then use e-SATA. Otherwise just place the VM on your notebook's disk drive.
     
  8. Exclude your virtual machine home directory and all subdirectories from your host's Anti Virus scanner. The Real Time Anti Virus protection doesn't really need to scan any of the VMs' files.
     
  9. Set the host operating system's file system to not update files' attribute or property for the last access in order to minimize the actual underlying physical IO's that must occur to support an IO request
     

    1. For Windows:  HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\FileSystem\NtfsDisableLastAccessUpdate = 1

    2. For Linux: Edit the /etc/fstab and ass the NOATIME attribute 
       
      1. /dev/sda6 /      ext3 defaults,noatime 1 1
      2. /dev/sda1 /boot  ext2 defaults,noatime 1 2
  10. Use VMware Workstation version 6.5.x (~$189) instead of the freeware VMware Server or even an older version of Workstation. The recent version of Workstation offers significantly better performance for both IO and network traffic. If you simply cannot spend the money for VMware Workstation, then my advice would be to instead try using the freeware Virtual Box. Note: I'm not recommending these virtualization products in general versus Oracle's VM. But for the basic notebook setup we're talking about – both these alternatives are dirt simple and good enough. For a real database server deployment, my advice would be quite different.

   11. For the Virtual Machine Settings, don’t set the VM CPU count too aggressively. For example if your test notebook has a dual core processor, thus you should not set the CPU count for any VM greater than one. When the host OS is managing "time slices" for concurrent process execution, it waits until the idle CPU count equals the client CPU setting. If you multi-task a lot or have host virus scanning real time protection, then you could see artificially induced delays.
       
   12. For the Virtual Machine Settings, don’t set the VM memory size too aggressively. For example if your test notebook has 4 GB of RAM, thus you should not set the VM memory size greater than half that. When the host OS is performing its memory management for concurrent process execution, the host (and the client too) could both be swapping/paging a VM’s memory at the same time. This also can introduce artificially induced delays.
       
   13. Review and rethink issues #1 and #2 based upon how many concurrent VM’s you’re going to run. The more concurrent VM’s obviously the lower then the CPU and RAM allocations you should make.  If you’re notebook PC is tight on memory, better to run fewer VM’s than to suffer the performance hits when over allocated.
       
   14. For the Virtual Machine Settings, be careful about your network model decision. I see many people simply choosing NAT (Network Address Translation) even though there can sometimes be significant translations delays introduced because it’s so easy. Yet I’ve seen where an Oracle Database connection from host or another concurrent VM application can take 10 seconds or longer. Some applications might even time out. I personally use "bridged" when on my home network and "host only" when traveling.
       
   15. If you’re VM’s OS is going to use a graphical user interface (GUI) then make sure to install the VMware tools. In fact, I’d recommend simply always adding the tools - because you never know when circumstances might change. And when your host is running Windows with the necessary hardware, make sure to check the display option for accelerate 3D graphics.
       
   16. If you won’t need to backup and restore VM images known as snapshots - then turn this option off. It adds overhead for something I’m never going to use. I simply zip up my VM files when I want to make a backup - so that I can move them between hosts.
       
   17. Keep all your VM’s VMware Tools version up to date. It’s simple to do and will offer performance improvements worth the brief time required to update. You can even set it to auto upgrade as newer version become available.
       
   18. If you’re not going to use hardware such as floppy disk, CDROM or USB - then turn them off. There is polling and other overheads that can be reduced or eliminated. And the cumulative effects when running more than one VM might be quite worthwhile.
       
   19. If you have multiple hard disks (remember that we don’t want to use slow USB disk drives for the VM’s), then place the host OS on one drive and the VM’s on the second drive. Spreading the disk IO between the host and the client will always be worthwhile. If you’re lucky enough to have an SSD drive it won’t matter.
       
   20. Make sure to regularly defragment and shrink your VM disk drives. The shrink is performed via the client VMware tools and the defragment is done via the Virtual Machine Settings for the disks.
 
   21. Keep the Oracle SGA memory allocation to a reasonable minimum. Assuming that we’ve 4 GB of RAM and allocate 50% or 2 GB to the VM, then keep the SGA size between 600 MB (an acceptable minimum that I’ve mentioned in a prior blog) and 50% or 1 GB.
      
   22. During database creation, if you’re not going to use Oracle Enterprise Manager then make sure to uncheck OEM in two places – the Database Creation Assistant (DBCA) screens for Configure OEM (uncheck the box), and Database Content (uncheck the OEM Repository box).
      
   23. During database creation, eliminate overheads most likely unnecessary for a notebook posed by flashback and archive log mode – the Database Creation Assistant (DBCA) screen for Database Content (uncheck both the flashback and enable archive boxes).
      
   24. Since we’re going to keep the SGA size to a minimum, make sure to use the Oracle version’s automatic memory allocation options (for 10g and 11g).
      
   25. Consider using a database block size of 4K rather than the 8K default. Remember that a notebook PC generally has a fairly constrained IO system.
      
   26. Manage Oracle disk IO efficiently through proper initialization parameter settings (i.e. DISK_ASYNC_IO=TRUE and FILESYSTEMIO_OPTIONS=SETALL).
      
   27. Since many notebooks perform basic IO operations in 64K chunks, be sure to set the database IO sizing options to leverage this. So for a 4K block size (from # 25 above), set DB_FILE_MULTIBLOCK_READ_COUNT=64K / block size (i.e. 64 / 4=16).
      
   28. Minimize certain Oracle internal IO overheads where possible. For example, set the AUDIT_TRIAL=NONE to eliminate auditing (the default in 11g). Also keep Oracle trace and dump files to a reasonable size (remember notebooks have a very limited IO bandwidth) by setting MAX_DUMP_FILE_SIZE=1M (or something likewise small).
      
   29. Disable certain "optional must pay for" OEM tuning and diagnostic pack overheads built into every database (even when you don’t pay for or use them). I recommend Mike Ault’s blog about Avoiding Oracle Licensing Landmines. For example disable automatic workload Repository snapshots by calling DBMS_AWR.DISBALE_AWR.
      
   30. Consider using "shared" server (i.e. MTS or multi-threaded) connection model. When you need to have the database VM handle significant multiple concurrent connections then lower the OS overhead per connection by sharing the server processes.