Oracle's database performs better under VMware than in a more expensive Real Application Cluster (RAC). This point has been noted in several web locations, and EMC's blogger-in-chief, Chuck Hollis, has discussed the topic. Oracle's RAC is a cluster of Intel X86 servers operating as a single processing resource pool with a …
I don't really get how you can replace RAC with VMWARE ....
1. if I have a query in data warehouse and fire it with PARALLEL (4,4) - 4 slaves on 4 nodes Oracle really spits the execution into several nodes and slaes, how can you do this in VMWARE?
2. there is alot going in the interconnect communication, you cannot just start 4 instances and connect them to the same datafiles (unless it's readonly transportable tablespace).
can anyobdy comment on this?
not up to it
Also I remember when dealing with Oracle their licensing folks misunderstood their own licensing for Oracle SE on several occasions and tried to charge us the same licensing scheme as Oracle EE(using the ratios). They fixed it in the end..
The license document is kind of confusing but it is there in not-so-plain-english:
"The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table"
"When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket. "
The multi-chip module language is new I think, not sure what that means, I don't believe multi-chip and multi-core are the same thing though.
Oracle standard edition RAC is restricted to 4 CPU sockets in the cluster and not 2 cores as per your article. Full details in link below
Not a clue
Whoever wrote this ?the author? guy from EMC? has no idea what he is talking about.
You cant equate SE with EE because EE comes with a raft of additions, plus allows extra (payable) options that any serious DP shop will need, plus SE doesn't run on anything more than about (from memory) 4 cores, so if you need more performance than that its a moot point anyway.
And you cannot equate VM failover with RAC because RAC doesn't need to failover, it keeps running when a node crashes. In the meantime your noddy VM instance might be rebooted quickly, but crucially then you need to recover the database, rolling forward through logs etc. How are you meant to share trade, run your mobile network, process orders while its doing that?? Oh, you can't. So how is VM highly available then?Oh, you measure when the instance in memory restarts, not when YOU CAN ACTUALLY ACCESS YOUR DATA ??
A simplistic and highly misleading article for anyone who want to run a high performance highly available system, who wants partitioning for ILM and performance, Spatial data for geographic analysis,detailed performance monitoring and tuning, data mining and bit mapped indexes for data warehouses, encrypted data and segregated data access to prevent civil servants leaving accessible data on memory sticks or old disk drives, etc etc ...etc. All these are EE features not SE. But I guess the EMC blogger only sees data as a bunch of bits on disk and doesn't worry too much what you might want to use the bits for?
RAC is now included in Oracle 11g Standard Edition, so tha RAC tax is no more. The Oracle tax, on the other hand, shows no sign of abating and there is nothing VMware can do about that.
Sounds like we have a few Oracle resellers that read the reg or else their buddies emailed them this article. I hadn't thought of it but Oracle buying Sun is terrible news for many IT budgets. Oracle seems immune to antitrust action for whatever reason and you are probably spot on that they are moving not only blackmailing their customers for more $ but dictating to them what environment they have to run as well. Meanwhile they are laughing all the way to the bank.
Vmware doesn't equal RAC
They're completely different approaches!
Vmware will give you a HA/failover capability, albeit a nicely managed & relatively quick one.
However its much the same in principal as a SQL Server active/passive cluster.... node fails, ah well - go start the DB up on the other node.
RAC's true active-active with both nodes handling data processing if you have a 2-node cluster, and if one breaks connections tend to be shuffled over to the surviving node potentially without the users noticing there's a problem.
Also all in 11G SE for "free" - no extra costs but you're limited to a maximum of 4 SOCKETS in the cluster.
VMware HA is not seemless
Like Joe pointed out - VMware HA restarts a VM on another host when your host fails. It is like a reboot, not at all like the RAC experience.
However, ESX 4 (vSphere) has a fault tolerant mode in which a VM runs on two hosts simultaneously and if one fails, the other seamlessly handles the load. Again though, you can only handle the same workload as one machine.
You would need a cluster file system and lots of fast interconnects for storage i/o access as well as for RAC itself. Even then, you would not want to be sharing i/o paths into and out of the individual physical servers with any other VMs. So what would be the point? Pay for VMWARE as well as Oracle licensing?
VM failover is not clustering.
Much as I agree that *all* vendors should support hypervisor-based deployment of their software, this is a case of comparing apples with onions.
RAC provides horizontal scalability and fault tolerance in the event of a database crash or a hardware failure. VMware HA is a restart mechanism. These articles and blogs are full of verbal gymnastics, trying to equate two very different technologies that have very different use cases, mostly for the sake of playing childish vendor one-upmanship games.
Those of us who actually design, build and operate the stuff aren't fooled. Alas, non-technical users might be.
RE: Not a clue & RE: RAC licensing
RE: Not a clue
If you paused to read the article, Chris Mellor did point out the difference as "RAC is fault-tolerant whereas VMware is high-availability", which does not quite match your correct point of continued operation versus recovery, but does imply this is a solution for those looking for a second-tier solution without the first-tier expense of RAC. This is not supposed to be a replacement for all RAC instances, but an extra, in-between option. Seeign as RAC reaches right into the enterprise high-end where VMware doesn't, there is little chance of RAC curling up and dying from a lack of VMware love anyway. Of course, if the VMware option also provides better performance (not sure on that claim) then it may protect smaller Oracle instances from comparison with other DBs such as M$ SQL, which already ties in neatly with M$'s own clustering out-of-the-box and at a cheaper price.
RE: RAC licensing
This is interesting as it could turn into a popularity contest - which is more wide-spread and valued, Oracle DB or VMware? Are EMC really worried that Oracle intend building a closed and proprietary stack and want customers to object now before the mortar sets in the brickwork, or are they just scoring cheap shots by painting themselves as the champion of choice against Larry's Licensing Machine and the RAC Tax? We use RAC in the high-end and happily pay RAC Tax for what it gives us - business continuity. Lower down the ladder, in the areas we would consider VMware, we wouldn't use RAC.
Personally, I don't think Oracle is even close to building it's walled garden just yet, even if they managed to cobble together OVM, Xen and Slowaris Containers into a viable multi-OS virtualisation package to replace VMware in most customers' affections. RAC is secure in the high-end enterprise, where VMware doesn't play anyway. And lower down where VMware does become a major factor Oracle is already under attack from M$ SQL and MySQL. If Larry really does want his walled garden then I think he will need to offer a lower-priced one based around virtualised and clustered MySQL or an "Oracle Lite". Maybe this more a case of VMware trying to garner attention in the face of mounting competition from other virtualisation packages.
Oracle on VMWare
Oracle on VMWare also needs you to license /all/ the CPUs in the virtual environment. Or you'll be in breach of their licensing terms.
Which is why we're keeping ours outside of our brand spanking new virtual environment.
VMware script kiddies at it again!
I think this is an example of the increasing prevalence of VMware type fanbois to try and make grandiose claims without actual empirical evidence. I’ve yet to meet a VMware admin who doesn’t try and make a claim that VMware is "revolutionary" and that its HA/DRS technologies are new. There is a reason that people still run true enterprise systems using technologies like RAC and on proper fault tolerant hardware/software stacks.
I think previous posters have explained why Chris Mellor’s poor comparison is lacking! (Something I’ve noticed more increasingly of your so called "assessments" recently) so I wont repeat them but its something I am seeing in the industry more and more. People attempting to shoehorn systems that previously running on the systems with the appropriate levels of RAS onto "cheap" x86/virtualised stacks, all looks good until they have a genuine outage, you never realize what you used to have until you need it!
Remember people you get what you pay for! VMware has some good technologies and it has certainly bought a good useable virtualized platform to the masses, but it lacks in some of the higher availability features.
You guys didn't read my comment on Chuck's blog I suppose. Oracle SE can go to 4 sockets, SE One goes to two. (I hadn't checked since I did my EE-SE migration but I just checked again now)
And Oracle SE is unlimited cores per socket, unlike EE which you pay based on the CPU ratio math stuff that Oracle has.
VMWare certainly can simplify setting up high availability with Oracle, though if your using Oracle I hope you have at least some expertise either in house or consultants.
Though VMware won't really help in scaling an Oracle SE instance beyond one system since that would need RAC.
The limitation of 4 sockets for a SE RAC with unlimited cores I think is fine even today, that's a MASSIVE amount of compute power for a DB, it could run circles around the $120k+ 8-way Itanium HPUX servers that I used a couple of jobs ago that ran Oracle(2005-2006), and that DB had 10s of TB of data in it). As with most databases the bottleneck is often I/O, not CPU. Having 16-24 cores today in a single schema with tens of gigs of memory is a steal compared to pricing of Oracle EE.
(4x6 core) 24 core Oracle EE w/RAC = $846k (list)
(4x6 core) 24 core Oracle SE w/RAC = $70k (list)
I would not use VMware myself if it was a highly loaded DB and your concerned about costs, just go bare metal and leave the VMWare licensing behind, don't forget if you want good MPIO in VMware, you need vSphere 4's highest end version which is $3500/socket, so that's an extra $14k, plus you need to throw in the cost of the 3rd party MPIO(don't know how much that costs yet). Spend what you save on EE on a good storage system, good servers, and good network connectivity. Also set some of that saved $ from EE aside for when 8 core CPUs come out, upgrade your system again.
MPIO prior to vSphere 4 isn't all that great, and if your serious about DB use your going to be using fiber attached(maybe FCoE if your feeling lucky..), not NAS or iSCSI.
There are more limitations to SE than just how many CPUs it will scale to, such as not supporting any of the other advanced HA features or scaling features of EE like partitioning and stuff. Also you can't perform online RMAN backups from a standby SE, and if you want a standby server you have to set it up by hand(copy logs, apply etc), it's not automatic like it can be in EE.
There are others as well, if your lucky it will be fairly easy to migrate to, my company at the time did not have to make any application level changes to support going from EE to SE. Also Oracle Enterprise manager isn't available for SE, even though you can install it, technically you can't get a license for it(doesn't stop it from working though).
Also note that if you downgrade to SE from EE Oracle won't let you "convert" your EE licenses(at least they didn't with us) you have to buy new ones.
@Not a clue
Actually, with vi4 you would not even need to do this, they have new features above HA level which will keep your VM's up with zero downtime (no reboots at all required) even when you loose the node entirely due to say, a fire or other disaster.
I've seen it in action and it really does work very well.
Too many mistakes
There are just too many mistakes and items taken out of context in this article to go through them. It looks like a barely changed regurgitation of some press release from EMC based on a very specific and unrealistic scenario. Software licensing costs of Oracle and how to optimise them is a serious subject, worthy of looking into. An item headlined like Oracle 'faster, cheaper' with VMware is not doing it. Oracle running under VMWare can never be faster than on raw hardware of the same specification. Possibly, there is some quirk of licensing rules that can be exploited to make it cheaper, but I only say possible. This article doesn't demonstrate it.
Watching for the indians...
...from the wrong side of the fort.
The biggest challenge to Oracle's DB market dominance isn't VMWare, MySQL, SQL Server, DB2 or any of the established order. There's about to be a paradigm shift in the way data is stored and processed. Some organisations are already leading the way, some are big commercial enterprises processing huge volumes of data, some are shadowy government agencies cracking encryption keys in double quick time.
It is coming, it will envelop and smother the traditional DB technology like Gray Goo...
Bad summary of an OK article...
The Original article was OK. The guy understood the differences between RAC and VMware and was basically saying if you are using RAC for High availability, not performance, you can get "almost" the same availability from VMware, at a reduced cost. This is true.
The writer of this summary doesn't have a clue what he's talking about and has badly summarized the original article and come up with something that is not representative of it.
The use of "it is said" as justification for statements is not the best reporting I've heard. I'm sure some of those statements were said, by people who don't understand RAC or VMware.
I find it highly amusing that OracleVM is described as, "poor - less robust and mature - compared to VMware." I admit the management tools are a way behind VMware, but the hypervisor, which afterall is the main bit of the virtualization solution, is bang on the money.
He then goes on to mention Sun's virtualization solution. Well their bare-metal solution is Xen based like Oracle's. Perhaps he means VirtualBox, which is not Bare-Metal and so not suitable for server virtualization.
So the writer knows nothing about Oracle and nothing about virtualization. Sounds like the perfect person to write an article summarizing someone elses work on those subjects...
Please read the original article, not this summary.
At the Semantic NEUKlearer Level in HyperRadioProActivity .
"some are shadowy government agencies cracking encryption keys in double quick time." .... By Anonymous Coward Posted Saturday 9th May 2009 16:21 GMT
Some are Non-State Actors/Virtual AIMachinery Supplying Cloud Control CodeXXXX to the Above.
When this nonsense of oracle's new license model hit we talked to oracle. And talked some more. And in the end decided to tease our developers away from oracle. It was expensive enough on physical boxes and it's insane on any decent sized vmware environment.
A lot of projects are done on oracle for no real reason except that the developers are used to doing things with oracle.
Article poorly researched and edited
Anyone deploying RAC is not looking for a HA solution. There is oracle datagaurd.
RAC offers load balancing and scalability with its many HW-nodes acting as a single
instance. A node failure on RAC is transparently handled by redirecting your queries
to the surviving instances.
VMWare cannot offer this . Writing a marketing spiel trying to compare
the two clearly shows the poor research which went into this article.
This article is not upto the register standards.
Oracle Sockets & Multi-Chip Modules
Database licensing guide, "When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket. "
Nate Amsden posts, "The multi-chip module language is new I think, not sure what that means, I don't believe multi-chip and multi-core are the same thing though."
Wikipedia has a quick section on it. Many Intel chips and most modern IBM Power chips are multi-chip modules. A couple of old SPARC vendors made multi-chip modules.
When these vendors glued multiple chips into the same socket using multi-chip module technology - each chip on the same socket gets charged as a socket.
RE: avoid oracle
"....A lot of projects are done on oracle for no real reason except that the developers are used to doing things with oracle."
Actually, it's because they know it will work reliably in Oracle, so they trust it and hence prefer to use it (especially when someone else is paying for the licences). Developing knowledge and comfort with an alternative means training and time out, which adds immediate expense to the developer. It's exactly the same with commercial UNIX - it may be expensive compared to Linux alternatives, but people feel comfortable with it, trust the support structure behind it, and hence will trust their bizz critical services to UNIX rather than "chancing" Linux. Linux doesn't have a capability problem, just a perception problem. Even in oranisations like mine where we use a lot of Linux, we still put the must-stay-up-or-the-company-dies apps on UNIX.
But it's not a hopeless case - once, mainframes ruled and cheaper UNIX was the new product no-one really trusted. In time, I'm pretty confident Linux will gradually erode what is left of the UNIX base, and opensource databases like MariaDB will erode the marketshare of commercial databases like Oracle DB. Oracle will probably fight it by making their money off the middleware and bundling in the DB for "free".
- Nokia: Read our Maps, Samsung – we're HERE for the Gear
- Kaspersky backpedals on 'done nothing wrong, nothing to fear' blather
- Episode 9 BOFH: The current value of our IT ASSets? Minus eleventy-seven...
- Too slow with that iPhone refresh, Apple: Android is GOBBLING up US mobile market
- Analysis Uber, Lyft and cutting corners: The true face of the Sharing Economy