Oracle RAC sucks... But don't despair, Larrry: drill, baby, drill!!l!!
I love this thread! I'm learning a lot! Thanks to all sunshiners and ibmers for their passionate bellicism... Needless to say that I'm in one of these two camps [ehem.. is it clear enough??]
So, after a good laugh around the tricks with the pricing of this pooooor benchmark, I asked a friend to have a professional look at this Oracle RAC. This is his professional diagnosis:
- **Oracle Turned Off the Oracle RAC Cache Fusion** - Despite using Oracle RAC technology, Oracle actually turned off Cache Fusion (a key component of Oracle RAC) by setting gc_files_to_locks=“\1217-1276=42EACH”. Quite simply, Oracle isn’t passing data pages over the network between nodes, instead they are operating in Oracle Parallel Server (OPS) mode - a precursor to RAC – and pinging the pages off disk between the nodes.
wOW! wOULD YOU DO THAT to YOUR ORACLE RAC?? (this is me, not him... you just can't imagine the laughs when he shared this pearl ...)
- Excessive Logging Hurts Performance: DB2 Logs 1/8th of Oracle RAC per Transaction. TPC-C full disclosures include a measurement of the amount of log space consumed during an 8 hour run of the OLTP workload. This allows us to determine the number of KB of log space that is consumed per transaction. Why is this important? Logging is the most critical I/O factor in high volume OLTP applications. Assuming that systems are expertly tuned (and they are for TPC-C), then the logger can be the choke point for higher and higher performance levels. Quite simply, reduced logging means increased performance. DB2 has the most efficient logger in the business. The best DB2 TPC-C result logs about 2.4 KB per transaction. Oracle ran a TPC-C workload in a non-RAC Oracle 11g environment and logged about 4.9 KB per transaction. The recently announced Oracle RAC 11g TPC-C result logged a whopping 19.5 KB of log space per transaction.
- Oracle Partitioned the Data and Routed Transactions to Individual Nodes in the RAC Cluster. Despite the marketing message that you don’t need to change your applications to efficiently run on an Oracle RAC cluster, in their latest TPC-C result, Oracle directed transactions to specific nodes using a mastering technique. It wasn’t enough that Oracle used partitioning to create data zones to get around the inefficiencies of Oracle RAC, they changed the application! If you want true application transparency, DB2 pureScale delivers near-linear transactional scalability without application change.
- Oracle Turned Off Page Integrity Checking. No one ever said that TPC-C is “real-world” – but there are things that Oracle does in this benchmark that makes this down right dangerous in the quest for performance. For example, Oracle set db_block_checking=false and db_block_checksum=false. By turning these parameters off, Oracle does not check the integrity of a database page. Per the Oracle documentation, “block checking can often prevent memory and data corruption.” It’s interesting to note that you can’t turn page integrity checking off in DB2 – even in benchmarks. Very few [not insane] customers would run a production environment without page integrity checks; however, we can see why Oracle would want to in a benchmark: Oracle's documentation claims performance degradation for block checking between 1% and 10%. I especially like the fact that they set they set _gc_integrity_checks=0 which turns off integrity checking for global cache services.
Not bad... I hope you enjoyed your show, Larry, but this is much worse than what we expected.
We're very disappointed!!!