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.


Solution 1:

"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.

Fran.

Solution 2:

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).

Solution 3:

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 :)