Re: Db2, Oracle, SQL Server

Serge Rielau apparently said,on my timestamp of 12/02/2005 12:03 AM:

>>
>> See how different the statements are from the "transparency"
>> bit?  When "partitioning" requires one to code FROM with
>> parameters that define which partition you want to go to
>> (because the CBO is so brain-damaged it can't figure that out
>> for you), you got a serious problem maitaining "transparency"...

Serge, do yourself a favour and READ THE C CODE used in the benchmark. It's there, black on white:
select .... from TABLE(blah (variable,variable)) where yadda yadda. Where the two variables are the warehouse number and sector and the tables are partitioned on those.

IOW, like I said: the SQL is dependent on parameters to select from one or the other of the partitioned tables. Nothing to do with the requirement for transparency, which is VERY CLEAR.

> and it absolutely complied with the slide quotes above.

I couldn't friggin care less what it did moons ago. I said, VERY SPECIFICALLY: for THIS benchmark, the code used does NOT comply with the transparency requirements of TPC.

Capice?

Cripes you folks just cannot stay on subject, can you?

> Does it makes sense to connect (!) to the node with the data if you know
> before hand?
> Yes, absolutely. Just like it makes sense in a RAC cluster to avoid
> thrashing of pages between the nodes.

Of course it makes sense. It also makes sense to fabricate results that don't match the most basic requirements of transparency.

Like I said: the TPC is a wasted effort when this sort of thing is allowed. You might as well have 100 independent systems all doing their own thing and call it one single database because they all share the same schema. It works: Microsoft does it all the time. Is it a good measure of clustered performance? Not unless you divide the results by the number of independent nodes being used... That would bring these results to what? Ah yes: around 300K tps. Nothing to write home about.

>
> Is that what you call the complete outage while remastering the
> ownership of pages?

Well it's a lot better than the complete shutdown of the ENTIRE system to recover from loss of one data file, as described - once again - VERY CLEARLY in the benchmark detailed document. What's the matter? Can't db2 do a live recovery without having to shutdown the entire database? If it can, then WHY THE HECK didn't they do that in the benchmark?

>
> Just presuming you were right with the select (which I challenge)

Go read the code. What else can I say,
when you "challenge" black on white?

> Why would the node stay offline? This is exactly what I was talking
> about. You have to kiss goodbye to the notion that nodes go down and
> stay down. We have customers doing node failover in < 20 sec.

Going by the benchmark figures in the recovery section, that 20 seconds sounds mighty optimistic....

> Evicting a node in RAC is in the same ballpark.

No it isn't. Do yourself a favour: setup a RAC test system and verify it yourself. It's got NOTHING to do with "20 seconds". It needs 0 - yes, ZERO - seconds to continue to operate. Got it?

> Different approach same outcome.

Like hell it is.

> If it's a software problem db2start on the same physical node. If the
> machien is dead. db2start on a different machine. HACMP does that just
> fine.

Whoop-tee-doo. WTF does that prove? That HACMP can start a command to start a database? Do you realise the absolute stupidity of using db2start to prove a recovery point in a cluster?

Cripes, people: it doesn't take a genius to figure out the crap that went through in this particular benchmark. That's the only good thing about TPC: it forces marketing types to disclose EXACTLY what they did. A reading of the detailed document uncovers so much rubbish it beggars disbelief. Anyone running a system like that in real life would be shot. You gotta be joking if you think this improves the credibility of db2...

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam