Management have OK'd a migration of our main Oracle DBs to a virtual machine platform.
Operations say they'll dedicate heavy-duty hardware and only run the DB VMs on it.

I've heard that running DBs on a vm is a no-no because of the extra layer (virtual io + physical io), but the OPS guys say it's super-fast hardware so no problem.

Should a DBA be overly concerned about this move to virtual?

thanks /j-p.

6 Answers 6


"and only run the DB VMs on it"

I've worked at two different shops in which I managed Oracle on VMware, and in both of them sysadmins made the same promise (and, eventually, they did not keep it :)

Apart from wzzrd's warning about oracle not 'officially' supporting instances on virtualized hardware if VM Server is properly configured, powerful enough and does not get bloated with dozens of other VMs performance penalty should not be really noticeable by end users.

It also depends on the type of databases you're virtualizing. OLTPs are usually better suited for virtualization than DSS/DWHs where I/O performance is critical.

I strongly suggest you to ask your manager to let you test the new servers before moving to production, in order to catch possible performance problems early.

Anyway, good luck.



I've run databases in VM with no significant problems (both small live databases and large test/dev ones, though no large live databases to date). Other than the potential official support issue you key, as with a physical DB server, is going to be I/O performance and RAM.

For I/O performance, my experience is that virtual drive never perform quite as well as relevant technology stakeholders claim, but never nearly as badly as the ney-sayers claim. As long as you have a good physical I/O subsystem serving the VMs (a nice shiny RAID10 array of fast drives, for instance) all should be well. All the normal performance tweaks hold out for VMs, like keeping data and logs on separate arrays (or separate drives if using single drives instead of RAID) and temporary data (assuming Oracle has an equivalent to MSSQLs tempdb on another array (some suggest RAID0 for performance, though I'm wary of RAID0 in production use even for temporary data as I don't want the downtime when a drive fails) if you can too. Do your RAID either completely in hardware (with a good RAID controller) or in software on the physical host machine. As daft as it sounds I have seen people recommend doing RAID in the VMs instead...

For RAM, just give the DB VMs as much as you can and make sure it is dedicated to them and won't be swapped by the host.

IMO: databases work in VMs and certainly perform well enough if you have the hardware to serve them and don't overcommit the hardware (two database running VMs that see significant load will cause more I/O load then one database server handling the same content as the two instances can't manage RAM and I/O ordering between themselves, where a single DB server instance can juggle resources between jobs as needed).


In addition to @Fran's comment, make sure that your application vendor will support it, too.

I know that the vendor I worked for before my current job will not support the entire product if Oracle is not installed on a "supported" platform. That makes a multimillion-dollar tool more-or-less useless if you need help.

Just a word of caution :)


As long as the IO under the database is fast enough, and you've got access to enough vCPUs and RAM you'll be fine. If you have a SAN behind the VMware systems and you need faster speed they can present LUNs directly to the guest either via iSCSI, or via raw device mapping where the LUN is presented to the hosts, then the hosts give the raw device to the guest OS directly. This lets the guest format the LUN as it needs and takes away the extra device layer.

(This works for all databases.)


Not because the fact that the virtual hardware is possibly a bit slower: that's only a couple of percents, if we may believe the benchmark people from Red Hat and VMware (etc.) or throwing at us.

Maybe though because the Moloch Oracle does not support virtualized hardware beneath their databases. Otoh, I hear that they can be 'coerced' into supporting it, given the proper tactics. Let us know what you end up doing.

We actually have a lot of Oracle databases running on ESX, but those are not production databases.


If you're able, try and keep the actual data and logs on a physical drive. Other than that, Go with wzzrd's suggestion.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.