Re: Oracle Expert

From: Mogens Nørgaard <mln_at_miracleas.dk>
Date: Mon, 07 Jun 2004 15:19:38 +0200
Message-ID: <40C46B6A.7020105@miracleas.dk>

Ah yes, the pricing model of EM itself carries a great story with it (told to me many years ago by someone where was there):

The EM team had prepared very carefully for the meeting with Larry in which they were to discuss how to price the various options. You always prepare carefully before a meeting with Larry, or you're doomed, so the rumour has it.

The EM team had several ideas, and the discussion went on for almost an hour, with Larry mostly remaining quiet.

Then, suddenly, Larry slammed his hand down and said "Ninety-five dollars per user" and left the meeting.

Nobody had suggested 95 dollars, nor the per concurrent/named user. So everybody looked at each other in bewilderment, then spent the next couple of days trying to figure out a) what Larry had really meant and b) how to implement it.

Today, it's 60 dollars per named user plus or 3000 dollars per cpu, so hey, it's fallen in price :-))).

Mogens

Niall Litchfield wrote:

> Comments in-line
> On Mon, 07 Jun 2004 11:20:58 +0200, Mogens Nørgaard <mln_at_miracleas.dk> wrote:
>

>>And just to set the license record straight:
>>
>>Yes, you pay either $60 per Named User Plus license or $3000 per CPU
>>license for each of the OEM Packs. That's always been the case.

>
>
> With the rather important caveat that you pay for them on the same
> basis that you pay for the DBMS. 8 processor licence for EE implies 8
> processor license for each pack that you take).
>
> And I've never really understood the rationale behind this (other than
> the give us more cash rationale) - with the possible but unlikely
> exception of Change Management. It seems to me that performance tuning
> and monitoring are done by one or more DBAs, but per database/instance
> not per user or per processor. I'd be far happier with a flat price,
> or a price per monitored target.
>
>

>>With 10g there's a new twist, since some of the really cool performance
>>and patch features in that relase can only be used if you buy the OEM
>>Packs.
>>
>>In short, AWR, ADDM, ASH, Advisors, etc. on the performance side must
>>only be used if you have purchased both the Performance and Tuning
>>packs.

>
>
> And that seems to include rolling it all yourself by writing scripts
> etc against the exposed views. IMO that should mean that the views
> only get installed when you install the pack! In addition Oracle
> always used to include a Standard Management pack, which wasn't that
> much use, but it allows you to use the event test and alert system
> with your own scripts (and some predefined tests as well). I haven't
> done that much looking at 10g EM yet (work keeps getting in the way
> and I have something else cool to do on the train now) but this
> functionality seems to have gone. Now my Oracle Sales rep tells us
> that no functionality that was there in 9i will have been taken away
> in 10g but I'm still waiting to hear if he or anyone else in Oracle
> can find it. And yes I am peeved - if the self managing database means
> the added chargeable extras database this is not a step forward .
>
>

>>It makes the packs much more useful. It also makes Oracle more
>>expensive, which will hinder the sales of these packs.

>
>
> And provides a great market for tools and consultancy companies.
>
>

>>As for the historic facet: Yes, they came from the Rdb world, and they
>>(expecially the DEC Expert product) would deliver reports several
>>hundred pages long where each parameter setting, and all sorts of other
>>in-conclusive data, were presented to the great bewilderment (but often
>>satisfaction) of the customer/end-user.

>
>
> LOL
>
> Niall Litchfield
> Oracle DBA
> http://www.niall.litchfield.dial.pipex.com
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Mon Jun 07 2004 - 08:16:29 CDT