Re: tough choices

Mark Townsend <markbtownsend_at_comcast.net> wrote in message news:<VVNBc.157111$Ly.81952_at_attbi_s01>...
> datab0y_at_yahoo.com wrote:
>
> 1) You are comparing IBM's workgroup server unlimited edition ( IBM DB2
> WUSE, limited to 4 CPUs and 32 bits, targeted at small web serving
> environments) with Oracle's Enterprise Edition. A better
> apples-to-apples comparison would be IBM's workgroup server unlimited
> edition pricing, with Oracle's Standard Edition One (limited to 2 CPUs)
> or Standard Edition (limited to 4 CPUs, inlcuding RAC support for up to
> 4 CPUs in a cluster).

yep, you're right.

> 2) IBM has no equivalent to Oracle's Partitioning or RAC option, so I'm
> not sure why you would even try to include them in a comparison. They
> also require an additional Tivoli product to provide the same capability
> that Advanced Security option provides.

Actually, right now I've got several oracle & db2 systems that are using range partitioning. The oracle database required additional licensing for partitioning - but the db2 databases didn't. One is using MDC and the other union-all views. Of the three techniques Oracle's is the most sophisticated and has the most features probably, though MDC is working fine. Union-alls are the most similar to the Oracle technique though aren't nearly so polished. I assume that we'll see them steadily improved over the next couple of years.

So, actually I'm getting table partitioning for free from DB2 but have to pay for it from Oracle. If I want to add database partitioning to the table partitioning - only then do I have to pay for it from db2.

I included these features in the estimate since they were implied as needed by the Daniel's description.

> > However, keep in mind that this is a huge drop in price for oracle.
> > Imagine if it still used its power-unit licensing cost - and you were
> > going to use four 3 ghz CPUs. That would cost about $300k / CPU - or
> > about $1.2m for to fully license the quad. Based upon this - oracle
> > has dropped its price around 75% in four years!
>
> Where did you get this price from ? It sounds completely made up -
> AFAIK, Oracle never published power unit pricing for 3 GHz machines.

No it didn't publish based upon 3ghz machines in 2001, but it did publish based upon the following formula:

• intel based: $1 / mhz / cpu
• risc based: $0.67 / mhz / cpu

At the time I was mostly specing out sun risc boxes - around 450 mhz to 800 mhz IIRC. You could I assume get an intel 1 ghz machine at that time. If that same licensing was being used today, then yes - the cost would be $300k / CPU for a 3 ghz server.

The only reason that this pricing scheme was dropped in late 2001 was due to a noticable drop in sales growth. I'm sure that it'll be back if Oracle ever gets as confident as it was in 2000.

> > Now, I'm not sure how DB2 UDB was licensed in 2000 - but I think it
> > was actually less than it is now. So, at the same time oracle has
> > dropped its price 75% db2 has raised its price 10% I believe (please
> > correct me on the older db2 prices).
>
> I'm not sure that IBM has indeed raised prices. This quote is taken
> directly from the IBM website "DB2 WSE and DB2 WSUE have undergone
> significant licensing changes when compared to DB2 V7. If you licensed
> DB2 WSE V7 with the Internet Processor license, you must migrate to DB2
> WSUE V8. The cost of DB2 WSUE V8 has been reduced by 47% when compared
> to DB2 V7 prices."

ah, ok - thanks.

> > So back to my original question - any one have tips on using
> > competitive pricing to drive oracle down to more competitive pricing?
>
> 1) Get your figures straight 2) Negotiate

ok, but how much room do the oracle sales guys have to negotiate? Can you pit resellers against one another? etc, etc.

BTW, one techniques that I've found to work well is to always ensure that my application could theoretically use either oracle or some other viable competitor - db2, informix, sybase, etc. This means keeping portability in mind in the design stage, and avoiding any unnecessary proprietary functionality. This goal encourages avoidance of such vendor-specific components as etl, data mining, application server, gateways, etc. That's not much of a limitation since most of the database vendor-supplied solutions are gross anyways. Received on Tue Jun 22 2004 - 11:51:31 CDT