Some time back I had a blog thread going about Oracle on AMD’s upcoming quad-core “Barcelona” processor. The thread (found here ) took AMD’s published, promotional material that set expectations for TPC-C throughput. At first there were projections from AMD that Barcelona would deliver 70% better throughput than Opteron 2200 systems. Later, as I blogged in this blog entry, AMD suggested we should expect as much as a 40% improvement over the Intel Xeon 5355 “Cloverdale” processor. The whole series of Barcelona-related posts was based on my analysis of Oracle licensing cost vis a vis Barcelona since Oracle licenses per core. In that series I used TPC-C results to make my points and at one juncture I used a TPC-C result from an Intel Xeon 5355 with SQL Server in one of my calculations. Folks got up in arms about that.
It seems people aren’t aware that all three major database players get about the same TPC-C per core on commodity hardware because the TPC-C workload has been optimized to the maximum. It’s a hardware benchmark folks.
This blog entry is to draw attention to the error of my ways.
My analysis of the potential for Oracle performance on Barcelona was covered in detail in that series of posts, but the TPC-C result I used in some of my calculations–thus raising the ire of some readers–was this 2-socket Xeon 5355 result with SQL Server. Certain readers thought it was absurd to collude differing database vendors’ TPC-C numbers into my calculations in spite of how many times I’ve blogged about the fact that TPC-C is a hardware benchmark, not a software benchmark. Oh well, you can’t win them all.
Confession is Good for The Soul
But what does this have to do with the Barcelona thread. Well, the Barcelona thread is just how we got here. So now I admit the error of my ways. During my series on Barcelona, I used this TPC-C result showing that Xeon 5355 can do 30,092 TpmC per core—with SQL Server. I factored that TPC-C number into Oracle cost per core comparison to AMD’s prediction on what Barcelona might do. After all, AMD is predicting they’ll beat out Xeon 5355 by 40% so I needed a Xeon 5355 number. Egad! Using a TPC-C number, without regard for database product, to compare hardware platforms! Shame on me. It turns out I was wrong. How wrong?
A Lower TPC-C Result Proves Oracle is Better
Yes, it’s true. A lower result can be a better result. It turns out that Oracle did eventually publish a TPC-C result on Xeon 5355-based gear. The result came in at 100,924 TpmC or 25,231 TpmC per core—19% lower than the SQL Server result of 30,092 TpmC/core. SQL Server simply must be a better database!
Not even close. Yes, the SQL Server number is 19% better on a per-core basis, but the cost to produce that result was $1.85 per TpmC whereas Oracle’s result was only 42% of that cost or $.78 per TpmC and it’s easy to see why. The SQL Server result was obtained with 64GB main memory whereas Oracle’s result used only 24GB. But that isn’t all. The SQL Server result came from a configuration that included, get this, 552 disk drives compared to the Oracle result that only required 104 drives.
The Tale of the Tape
You heard it here first! SQL Server is a better database than Oracle. All you have to do is throw in 5.3 fold more disk drives and an additional 2.6 fold main memory, shake vigorously and out plops a 19% performance improvement. Not bad for 2.4 fold additional cost!
Summary
SQL Server is not better than Oracle. By the way, AMD Barcelona most likely won’t deliver 40% more throughput measured in TpmC than Intel Xeon 5355.
For more fun, browse this list:
http://tpc.org/tpcc/results/tpcc_results.asp?print=false&orderby=availability&sortby=asc
It shows systems ordered by date of availability. Look how fast and cheap they’ve become…
There is as I point out in my blog another way of making the Oracle result so much cheaper – make sure you buy a limited term license of SE1 and not EE.
Why has Oracle refused to submit a TPC-E benchmark result? Is it because their database is coded to optimize TPC-C instead of a real worrld workload?
Hello Zsolt,
I’m not so sure that is the reason. Oracle is indeed optimized for real workloads–there is no doubt.