This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Running Oracle Production Database on VMware

Darryl Griffiths
NOTE: For research links, see my later post here.

Are you considering running Oracle production databases on VMware?
Obviously you’ve considered the Oracle support policy on this.
How likely is it that you will get asked to “make it physical”?  or How will Oracle support deal with your call if you tell them you’re on VMware?

Well, there are some harsh responses from Oracle towards VMware customers if you have access to Metalink (sorry, My Oracle Support).
First you should read this doc: 1071005.1 (HOTSPOT ERROR DURING 32-BIT 11GR2 CLIENT INSTALL ON 64-BIT (X86_64) SUSE (VMWARE)).
Then read this document: 1075717.1 (Installing 32-bit RDBMS Client software on x86_64 Linux.)
I don’t think the first problem’s resolution is justified.  Do you?
I have found Oracle notes that state the following:

“(1) Make sure you are logged into the Server Console directly, and that you are NOT trying to install the patch over a remote connection (such as Terminal Services, Remote Desktop, Timbuk2, PCAnywhere, VNC, VMWare, etc.) “

“As for installing over a remote connection, we do not support this, because Oracle cannot control the way the permissions are setup, over the remote connection.“

So VMware console is a remote connection…

Then there is this document:
https://www.oracle.com/us/solutions/sap/wp-o10g-rac-config-win-303805.pdf

This doc is an Oracle whitepaper which details SAP Netweaver / Oracle Databse 10gR2 RAC on Windows 2003.
In the doc it shows an example hosts file which is clearly from a VMware hosted server.  Double standards I feel!

This is just not a nice place to be if you’re trying to convince a company that VMware is a solid, supported tool to run production databases, and that Oracle even support RAC on it now.  Maybe some of the notes are old, before the acceptance by Oracle that VMware is becoming big in many companies.  Or maybe Oracle’s RAC support is an illusion of good will, whilst they quietly (or not so) improve the Oracle VM product.
The best way to tell, would be the acceptance of Oracle that VMware’s vCPU allocation is acceptable as a form of hard partitioning, so that you can bring the Oracle DB license cost down by runnining on VMware, in the same way you can on Oracle VM.

2 thoughts on Running Oracle Production Database on VMware

  1. I don't think it's necessary for Oracle to make vCPU allocation a form of partitioning as this would reduce flexibility for customers. There is a major gotcha when configuring Oracle VM for partitioning with the Oracle databases and that is the DB VM's are tied to the host and CPU's and can't be moved or recovered. The whole partitioning argument is completely irrelevant when you buy hosts that are the right size to run your licensed Oracle databases. Then you can run an unlimited number of databases (within resource constraints) on your licensed hosts. This is a much better situation than trying to partition part of a large host. There are plenty of cases where customers have saved a lot of money virtualizing Oracle software on VMware vSphere. But you have to do it smart and you have to know your contract.

    Reply

  2. Hi Michael,

    Thanks for your comment. Your expertise in the virtual world completely overshadows mine.

    I'm not sure vCPU partitioning in VMWare would reduce flexibility for (Oracle) customers. At the end of the day, so long as they only use the CPU allocation they've paid the Oracle license (and support) for, then there *should* be no problem (except Oracle make one).

    The way I see it, the logical granularity of processing power is changing. It's gone from the CPU level, to the server level.
    One can now add/remove whole servers at will from an environment.
    When Oracle restrict our options by making their licensing options impractical and tricky to understand, then it only helps to prevent customer flexibility and choice.

    The "right size" option has it's practicalities and can be applied to certain cases, especially trying to reduce Oracle license costs.
    However, I've been involved in small-scale P2V projects that either don't have the budget to buy new hardware or don't want the short term license cost saving being erased by unknown amounts of (personnel) overhead associated with installing and configuring new kit.
    There's also the worry that they may not have sized it correctly (companies don't really worry about this, they just don't want to do it!).

    A brand new system implementation, on the other hand, may benefit from a "right size" approach in exactly the way you've described.
    It needs the software vendors, architects, system implementors and hardware vendors to properly talk, for an accurately sized environment to be built to achieve the license saving goal. Which as you've shown on your own blog, could be a significant sum for large landscapes.

    I think the future may look differently at right sizing.
    I see a future where amalgamation of different ages of servers into a virtual infrastructure will help make better use of older kit.
    The VI would provide redundancy and agility with regards to hardware maintenance. Permitting additional life from older kit and preventing the constant need to refresh hardware.

    The software vendors just need to find a better, more flexible way of licensing CPU use. Maybe per cycle… or not at all.

    All of that said, certain software vendors are beginning to push the next generation of technologies such as SAP HANA + Sybase, which uses a different licensing model (http://www.asugnews.com/article/sap-hana-pricing-amid-controversy-sap-offers-licensing-clarity).

    I'm not making any comment on how "easy" this license model is to understand compared to Oracle's. But at least it doesn't use the "per processor" method.

    Darryl

    Reply

Add Your Comment

* Indicates Required Field

Your email address will not be published.

*