Re: New TPC benchmarks

Matthew,

SAN's incur (much?) more codepath. If that makes things run faster that's excellent and fantastic. If removing a bunch of code and 8 or 9 layers between a server and a disk plate makes things slower there's something else wrong. Time and again we see how a laptop or desktop PC disk can outperform some fancy disk arrangement. That might be because the disk arrangement is not set up correctly, but that again requires a lot of effort and thought - and expensive consultants, which is very cool for me :).

Before SAN's there were still some very high performance systems out there. After SAN's there are still some very poor performance systems out there. I work with some of them in the Terabyte range, and - oh lord - they become so expensive that they become political. And then you have the RAID-F's and/or the poorly configured monsteres that no-one can understand or handle anymore.

What I think doesn't really matter, because SAN's promise - by adding 8-9 layers of complexity - to simplify the world and automate a lot of things. They do to some extent. But is it always worth the money?

With small and medium businesses a number of things have become clear to me (and this is of course different from the monster systems):

1. They end up spending a large proportion of their IT budgets on disk technology. They didn't do that before.
2. They end up having a few servers attached to relatively many disks. Those disks are much more expensive than the ones you can put in, say, products from IFT.
3. They complain that no technician can handle the whole SAN stack. They end up blaming the previous technician.
4. When we do our SANity check - how many reads and writes are actually requested from the servers towards the disks - the picture is often one of far too many disks.

The TPC benchmark is useful for comparing what?

The TCO is useless precisely because every vendor can prove - using TCO - that they're the best solution. Too many things can be tweaked and twisted - just look at the way they calculate licensing stuff in the TPC benchmarks - it's kind of hard to find out how they arrived at those prices, isn't it?

When Oracle puts out features that are excellent and useful for UPS or Amazon, that's nice. It's usually not useful for the rest of the world :).

Of course, everything I've said only applies to Denmark.

Mogens

Matthew Zito wrote:

>Mogens,
>
>I wanted to clear something up - I keep seeing you post that SANs are slower
>than direct attached - I've said it before and I'll say it again:
>
>simply not true.
>
>There is zero, zero, zero reason why a SAN must be slower than a direct
>attached. In fact, in the fastest benchmark described in these results, the
>10g on Itanium one, they're using a SAN. The only reason to direct-attach
>is to keep the cost down when you have a situation where you can run
>multiple I/O paths from a single node. There is a fixed limit on the number
>of direct paths you can run to an array - usually 2-4 - which makes things
>hard if you want an 8-node cluster.
>
>In general, the TPC benchmark is not a perfect process. However, having
>dealt with it in great detail, it is vastly superior to any of its
>predecessors in terms of simulating a real-world environment. While
>configurations like 2400 disks seem absurd to those of us in the field, the
>fact alone that you are required to include the total cost of the solution,
>plus disclose the complete configuration, and are not allowed to use any
>hidden or secret functionality is a huge step forward from previous
>benchmarks.
>
>Thanks,
>Matt
>
>--
>Matthew Zito
>GridApp Systems
>Email: mzito_at_gridapp.com
>Cell: 646-220-3551
>Phone: 212-358-8211 x 359
>http://www.gridapp.com
>
>
>
>>-----Original Message-----
>>From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On
>>Behalf Of Mogens Nørgaard
>>Sent: Monday, December 15, 2003 5:44 PM
>>To: Multiple recipients of list ORACLE-L
>>Subject: Re: New TPC benchmarks
>>
>>
>>I love to read the Full Disclosure Reports:
>>
>>"There were 672 x 18GB15krpm HDD Ultra320 HP, 1344 x 36GB15krpm HDD
>>Ultra320 HP and 224 x 146GB 10krpm HDD
>>Ultra320 HP in the benchmarked configuration."
>>
>>FYI: 672+1344+224 = 2240.
>>
>>IBM is considering a 1.6M benchmark, and the only problem
>>these days is
>>to find a sponsor for all the hardware you need. It might
>>require 4000
>>disks - maybe mirrored to a total of 8000? The number of
>>disks involved
>>is becoming a problem for two reasons: One of them will
>>probably fail.
>>And since they're directly attached (for performance, SAN's
>>in general
>>suck compared to direct attach, as you know) it could take
>>three hours
>>to boot the machine. So they're considering going 1+0 aka
>>MASE, not the
>>inferior 0+1 or SAME, of course :). Simply to avoid the reboot time...
>>
>>Today it's only a question of finding a sponsor for the
>>benchmark. Then
>>you can break any report.
>>
>>All the database vendors run their software in special debug modes
>>during benchmarking - in case they hit something nasty :).
>>
>>Notice that they never use anything but shutdown abort in
>>their scripts
>>(Connor - you'll love this). IBM (with DB2) uses a slightly different
>>technique: They take the power. Very fast, they say.
>>
>>Mogens
>>
>>Michael Boligan wrote:
>>
>>
>>
>>>http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
>>>
>>>Finally, Oracle reclaims the lead!!!!! That Sqlserver isn't as
>>>scalable argument doesn't work too well when Sqlserver has a
>>>
>>>
>>higher TPC
>>
>>
>>>benchmark.
>>>
>>>
>>>
>>>
>>>
>>--
>>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>>--
>>Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
>> INET: mln_at_miracleas.dk
>>
>>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>>San Diego, California -- Mailing list and web hosting services
>>---------------------------------------------------------------------
>>To REMOVE yourself from this mailing list, send an E-Mail message
>>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
>>and in the message BODY, include a line containing: UNSUB
>>ORACLE-L (or the name of mailing list you want to be removed
>>from). You may also send the HELP command for other
>>information (like subscribing).
>>
>>
>>
>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
  INET: mln_at_miracleas.dk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).