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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //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@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
