* Posts by JuanMaBlue

9 publicly visible posts • joined 23 Mar 2008

HP sics Spaniards on Larry Ellison

JuanMaBlue
Facepalm

Spanish politicians at work

I'm Spanish and I love my country: olive oil, flamenco, jamon, (ham), nice weather (too dry sometimes..). Above all, friendly people. That's my little old home. There is only one pesky detail I hate of Spain: the politicians. This stupid idea of making a headline in the anti-competitive front is so typical of them...

Cambridge IT guy 'was the Spanish Guy Fawkes', say cops

JuanMaBlue

He's just a terrorist

There was no shootout. He killed a policeman in cold blood who was trying to identify this gentle and regular dad. The vicious murder was rewarded by ETA with a sort of promotion to CIO of bombings and similars. He's been "inventing" new tricks to make the bombs harder to detect and easier to detonate

Disconsolate Spanish smokers driven out into blizzard

JuanMaBlue

Smoking in Canary Islands

Not true. Smoking in enclosed places is as forbidden as in the rest of Spain. They have special rules for selling tobacco (less taxes and so..). That is what is not changing.. so far

Spanish fascist decries Franco Eurovision slur

JuanMaBlue
Pirate

Franco is dead and forgotten in Spain

I'm Spanish. Believe me: Franco is as dead here as Stalin is in Russia and just in a little better shape than Hitler in Germany. BTW: Our democracy stinks but that doesn't make me miss the old mot**rfu**er

Gosling gusher sinks Oracle's Java cred

JuanMaBlue
Megaphone

DB2 works great in cluster

# jlocke:

DB2 can be run in a cluster of cheap machines --> http://www.xkoto.com/index.php/blog/index/

DB2 can also be run in an endless cluster of small (4U) Power7 machines (Power 750). They are not exactly inexpensive, but you can mount a brutally big OLTP cluster, by chaining low mid range Power servers. It's called DB2 PureScale --> http://it.toolbox.com/blogs/db2luw/db2-purescale-scalability-part-1-35173

Oracle defrosts EC concerns over Sun takeover

JuanMaBlue
FAIL

Sun is dead anyway

Glad to hear the deal is unlocked. MySQL was never a valid reason to stop it. It's been a test of wills since the beginning. Oracle didn't show "the due defference" to the regulators and Neelie Kroes reacted making them feel her power. The whole thing was degenerating into a dangerous US vs. EU problem... So, welcome rational solution!... Anyway, Sun is still dead. Sparc is a rotten corpse. Solaris is the O.S that runs on Sparc. Java is a standard that can't be squeezed out more than it is now or the other solution providers [apart from Oracle] will kill it. The first question about this deal is still here: is it worthy to pay so much money for Sun?

Ellison whips out his Sparc TPC-C test

JuanMaBlue
Terminator

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!!!

IBM readies Exadata killer

JuanMaBlue
Grenade

DB2 PureScale is an Oracle RAC Killer.

RAC is something that merits being killed. Exadata is just a headline for Larry-Needs-To-Tell-Something-Good-Around-Snoracle.

I mean, DB2 PS is almost linear scalability vs. very poor scalability, application transparency vs. cluster-aware applications with constant architecture tuning and code modifications, automatic workload balancing, instantaneous recovery from node failure.... and much more.

And yes, it runs on Power Systems

Don't compare with Exadata. , which is just an abortion ("A waste of time", by rch)

IBM waterboards PA-RISC Superdome from HP

JuanMaBlue

My two cents

1. IDC Server Tracker FY07 - Vendor: HP, Processor Type: PA-RISC, Server Class: High-End Enterprise Server. Sum of Units: More than 500 (I'm afraid I must respect some "confidentiality"). Hard to believe, but Superdome PA-RISC is still alive.

2. "And IBM's tricks with TPC are old and notorious, like using $5m of back-end storage with an unrealistically and massively partitioned database to try and make a mid-range server look good"

Everybody uses a crazy mountain of storage with the TPC-C audits, not only IBM. One example: 320.974GB with the last and **heavily partitioned** Superdome Integrity.

3. "Integrity allows you to host Windows, hp-ux and Linux virtual machines (yes, just like VMware!) on the one system, right from the bottom of the Integrity range to the top" -

Windows on Superdome? What a terrible idea!...

SAP SD 2-Tier (you see? I don't need to use TPC-C):

Superdome 9050. 64 cores. Windows: 46.380 SAPS

p5-595 @ 2,3GHz. 64 cores. AIX: 117.520 SAPS

TPC-H 3TB (TPC but not C, ok?)

Superdome 9050. 64 cores. Windows: 60.359 QphH

p5-595 @ 2,3GHz. 64 cores. AIX: 100.512 QphH

And the Big Fella is coming!!

BTW: good article, Ashlee.