« What the Oracle / VMware support statement really means...and why | Main | Oracle Wants To Win The Virtualization Wars – But Will Customers Lose? »

May 07, 2009

Comments

Fazal Majid

I'm sorry but the comparison is misleading. RAC provides load-balancing, not just HA, unlike VMware. It doesn't actually work as advertised for many workloads, to be sure, but it's still a major difference.

--------------------

Response:

Actually, VMware provides load balancing as well, just in a different manner. The load balancing is provided by the Distributed Resource Scheduler (DRS) component of VMware cluster. This is very different from the way in which RAC load balancing works, however. I will probably do a blog post on this soon to point out the differences.

Regards,
TOSG

denisg

Hey Jeff,

According to the following blog by the Chris Wolf over @ the Burton Group, Non-Oracle x86 Hypervisors are Now Supported.

http://dcsblog.burtongroup.com/data_center_strategies/2009/05/oracle-honors-its-new-years-resolution-non-oracle-x86-hypervisors-are-now-supported.html

http://www.chriswolf.com/?p=359

http://blogs.oracle.com/stevenChan/2009/04/ebs_support_policies_for_virtualization_technologies.html

So go start virtualizing your Oracle DB's on the most proven and stable virtualization platform in the market today and tomorrow.


Cheers,
Denis

----------------------

Response:

This is very good news, but unfortunately, it does not apply to the database server, only to the application server as well as the Fusion middleware server. The use of VMware virtualization for these servers has become so common, that Oracle made the support position on these server official at this point.

Thanks very much for pointing this out though.

Regards,
TOSG

Roy Olsen

To say that a single node Oracle database under VMware outperforms a RAC cluster is quite the claim. I'd love to see what you base it on.

To be honest, an old saying relating to apples and oranges comes to mind.

Oracle RAC is a very specialized technology that offers high performance and a minimalistic fault tolerance for specific applications.

I might add that in my experience, most people who consider RAC to be a viable HA-solution works in Oracle's marketing department.

I don't see any way that VMware can provide comparable performance without implementing true load balancing technology - just as I don't see how RAC can provide comparable redundancy without implementing full node to node failover such as offered by Veritas Cluster or even Oracle DataGuard.

Regards,

Roy Olsen

------------------

Response:

I base that on real-world TPC-C-like performance testing using Quest Benchmark Factory for Databases on identical hardware, running both physically-booted and virtualized configurations.

You seem to have some objections to RAC as an HA solution, which I am not willing to endorse. I have never said that RAC is not a viable HA solution. In fact, RAC can be up and running for many years without any downtime on the overall database, in my experience.

Regards,
TOSG

yveke321

You should compare CRS with VMWare HA, not RAC. Also a question:are you advocating single schema/single instance oracle VM's? Will this not create a proliferation of DB instances that would eb difficlut to manage with VMWare? Also it looks to me like you are putting the management burden with the VMWare/server folks, right?

What are your views on consolidation with multiple schema's on single/multiple instances running on single machines but with CRS?

Thanks yveke.

-------------------------

Response by TOSG:

When I discuss the clustering layer of RAC, I am referring to CRS, yes.

The scale-out model is one which is frequently referred to by Larry Ellison. This occurred in the context of the Exadata II launch last week. It is the case that there are management issues with running many smaller instances, rather than one large instance. However, there are also management issues for having many logical schemas within a single instance. Overall, I would say it depends on what you want to do. If you want to run something like SaaS, many small instances is a good way to go.

Running many instances within a single OS environment (i.e. physically booted) is also an option. It can get confusing though. Also, memory management is a challenge. All SGAs are pulling from the same pool of memory. VMware helps with this.

There is less overhead on multiple OS images that you might think in a VMware context. Transparent page sharing recoups much of the memory of similar OS images.

Colon Cleanse

This is very nice one and gives indepth information. Thanks for this nice.I am looking for my own blog.

pg

Oracle SE with RAC is indeed 'noddy' but I believe that it extends to 2 *sockets* per machine not two cores. You can actually get some reasonable performance if you invest in fast multi-core (but single die) CPU architecture.

Orly Andico

I'm looking at footnote 5 on page 10 of the EPL.PDF (Oracle Technology Global Price List, March 16, 2011).

This states:

Oracle Standard Edition One may only be licensed on servers that have a maximum capacity of 2 sockets..Oracle Database Standard Edition can only be licensed on servers that have a maximum capacity of 4 sockets.

I know a lot of customers who go through all sorts of contortions, under-sizing their hardware so that they can "get away" with Standard Edition rather than Enterprise Edition.

But.. there are a lot of other capabilities (example, Transparent Data Encryption/TDE, Partitioning, the ever-popular Diagnostics & Tuning) which are simply unavailable on SE. For certain customers (e.g. folks who want a SOX, HIPAA, or PCI-DSS compliance framework for their DB) Standard Edition would not suffice.

So I would not agree with any statement that EE+RAC penalizes customers. Is it expensive? yes, it is. Does it make sense for many customers? yes, it does. Besides there's always the ULA..

The views expressed on this post are my own and do not necessarily reflect the views of Oracle.

The comments to this entry are closed.

Powered by TypePad
View Jeff Browning's profile on LinkedIn

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.