Re: Oracle Standard Edition & RAC

Instead of deleting awr, why don't you disable it with statistics_level=basic ? There are other things that have to be consider using "basic" like the stats gathering, but most people like collecting stats when they want and not when oracle wants them. I would be wary about dropping the objects. I bet patches and upgrades expect the objects to be there and would cause some problems. 


On Jan 2, 2007, at 10:01 PM, Mark Brinsmead wrote:


Hmmm....  Where to start with this one?
Okay. First, Standard Edition. Yes, I have lots of clients who use Standard Edition. Many use Standard Edition (or Standard Edition One) exclusively. With multi-core processors, Standard Edition One can cost as little as about 1/16th as much as Enterprise Edition (per processor). If you don't happen to need (really need) features available only in Enterprise Edition, the cost differential (for both licensing and maintenance) can be quite compelling. In some cases, this difference can run to millions of dollars!
In the past 5 or 6 years, I have seen much more SE than EE. And for very solid reasons.
Standard Edition with RAC? I have never had a client who used this combination. While it is true that RAC is "free" with Standard Edition (but not available at all with Standard Edition One) you are severely limited. You must use (only) ASM storage and Oracle clusterware. Much more significantly, the maximum capacity of your entire cluster cannot exceed 4 CPUs (CPU cores, actually). Note that this is "capacity", not installed processors. As true single processor (single-processor-core) systems are getting harder and harder to find, this effectively limits you to a maximum of 2 nodes in your cluster. 2-node clusters under certain configurations (not sure whether OCS/ASM is one of them) can be subject to severe stability issues, as failure of one node can result in "split- brain" conditions that cause failure of the entire cluster.
Standard Edition RAC can be useful, I am sure. And I have little doubt that somebody is using it. Somewhere. But I would think that an application that genuinely requires the "high availability" offered by RAC while simultaneously living comfortably within the limits of a 4 CPU cluster would be a very rare combination.
Now, finally, as to the lack of Diagnostics Pack / AWR data in Standard Edition...
Well, that's not at all true. Well, not entirely true, anyway. AWR is definitely present in Standard Edition, and the tables are (by default) populated. The same is true for most Diagnostic Pack tables/views that I can think of. There's just one catch, though. You are not allowed to access it! Specifically, it seems that accessing this data (even from SQL*Plus) requires licenses for Diagnostics Pack (and/or Performance Tuning Pack) which cannot be obtained for Standard Edition.
I presently have an SR open with Oracle Support, requesting instructions for a suported method of removing AWR from Standard Edition databases. So far the only answer I have received has been "go talk to your sales rep". For the life of me, I cannot understand why. Why would I talk to a sales rep about a licensing option that we both know is unavailable to me?
Anyway, if you happen to have an application that requires RAC (but not TAF -- I'm not certain, but I don't think you can get that with SE), will never need more than 4 CPUs, and can live without all of the cool nifty features of EE, you can save about $200,000 per cluster by using Standard Edition, plus about $30,000 per year in support. Over time, though, the lack of EE features might make you pay back a big chunk of that in (maybe) increased downtime and personnel costs.
Before you go down this path, be certain you know what you are sacrificing! Make sure you are completely aware of all the features that are unavailable with SE. 



On 1/2/07, Job Miller <jobmiller@xxxxxxxxx> wrote:
found one inaccuracy in my quick read of that comparative feature by version:
there is a feature it describes as automatically maintaining global indexes when DDL is executed against partitioned tables. It lists it as Y Y Y Y, but partitioning is only supported in 2 of the 4.. so I am not sure you can say 'Y' in Standard when the feature is referring to an underlying EE feature. :) 

I'll report that inaccuracy.
The biggest downside to SE that I see is no Diagnostics Pack (AWR) data available to you.
so now if you throw in RAC, you have any more of a need to understand/diagnose the underlying wait data, but no convenient mechanism like AWR to collect all of that for you. 

Job




Robert Freeman <robertgfreeman@xxxxxxxxx> wrote:
Check out metalink note 271886.1 for a full comparitive list of the
different features.

RF

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Matthew Zito
Sent: Tuesday, January 02, 2007 4:39 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Oracle Standard Edition & RAC?



Folks,
Had a quick question for the folks out here - how many people are using, 
or looking at using Standard Edition with RAC in lieu of EE? Are the
cost savings worth the annoyance of the limitations? Why is/isn't
everyone doing this? I have a customer that is asking for why they
shouldn't be using Standard Edition - I'm an old EE bigot who thought
standard edition was for integrating into software and laptops, but I've been hearing more and more people talk about using SE w/ RAC instead of 
EE for smaller environments. Thoughts?

Thanks,
Matt

--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito@xxxxxxxxxxx
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com




--
Cheers,
-- Mark Brinsmead
   Senior DBA,
   The Pythian Group
   http://www.pythian.com/blogs

Other related posts: