« Using VMware? Want more perf? Help me help you. | Main | Performance = art not science (with DelayedAck 10GbE example) »

March 01, 2011

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Alex Maidak

I find this misleading in general. The database tier is a 4 node RAC cluster on the UCS hardware, no vmware involved. You did not "virtualize" oracle db, but virtualized the oracle application server tier.

I'm not impressed. A java application server is about 10x easier to virtualize then a large database.

Chad Sakac

@Alex thanks for the feedback.

I'd encourage you to read the post and the document clearly. It's clearly stated several times (in both), that the Oracle 11i apps tier is virtualized, the Oracle 10g RAC DB tier is running on x86 hardware. As I noted in the original blog post, virtualizing EMC's DB tier is one of the key scaling goals of VMware's next major release.

I will tell you this - large scale Java workloads are actually very hard on VMware (and require careful BP planning) based on how they handle memory. Many large scale DBs are successfully virtualized (not EMC's - NOT YET).

Betsey Bolton, EMC Global Marketing Programs

You can register for the March EMC Solutions for VMware webcasts here: http://info.emc.com/mk/get/DBM10514-17091_raf_lp?reg_src=PA_Vmware

nate

I don't know, I guess it depends on the workload, but my personal preference for Oracle would be to stick to physical hardware for real production systems.

Mainly to get around the limitation of 8 vCPUs in VMware. A 4-socket 48-core(AMD) (or even 32-core Intel) Oracle SE system will just scream, and be dirt cheap compared to Oracle EE. Most folks can get by just fine with SE and I love the per-socket licensing (though there is a limit of 4 sockets in a system or 4 sockets in a RAC last I checked - but with so many damn cores it's not a big deal).

VMware certainly gives a lot of flexibility though if you want a lot of independent instances.

twitter.com/that1guynick

A different viewpoint of my own, after reading this yesterday.

http://that1guynick.blogspot.com/2011/03/oracle-on-vmwareyes-again.html

Would love feedback and continued discussion!

If nothing else, thanks for keeping this topic active, Chad!

-Nick

Jay Weinshenker

I'd be more than happy to talk to any people who are worried about virtualizing their Oracle environments on VMware. Sure, in VMware currently you are limited to 8 vCPUs per VM (hopefully that'll get resolved soon), but I'd argue most of the Oracle databases out there don't need 8 (or more CPUs). For most of those, virtualizing under VMware and then leveraging VMware's features like snapshots, HA, DRS, etc make TONs of sense.

My main client runs the following Oracle on VMware:
Oracle EBS, Oracle Agile, Oracle UCM, Oracle UPK, Oracle Hyperion, Oracle GRC, Oracle OEM, and a number of other products requiring Oracle databases. At last check, and I need to re-calculate, the client saved over $2.2M in Oracle licensing costs by being able to run all their databases on only a few vSphere hosts.


Mark

Intel Xeon Nehalem EX is simply the most cost-effective platform for Oracle EE today. The per-core performance of Nehalem EX is on par with the per-core performance of POWER7 on many benchmarks, but Oracle's core factor for Nehalem EX is 0.5, and for POWER7 it is 1.0.

Nehalem EX crushes SPARC64 and Tukwila in per-core performance.

A 4-socket Nehalem EX system can produce around 2 million tpmC, and can support 1TB of physical RAM.

You do not need RISC/EPIC "big iron" servers to support the databases for a Fortune 500 company. You can run a large company on Oracle RAC clusters of Nehalem EX servers. EMC and Cisco are proving this.

The comments to this entry are closed.

  • BlogWithIntegrity.com

Disclaimer

  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.