Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Enterprise Edition vs. Standard Edition 3

Status
Not open for further replies.

tekdudedude

Technical User
Sep 29, 2007
79
0
0
Hello,

I need to build a case to management to get the Enterprise Edition (EE) of Oracle. We are using the Standard Edition (SE) now.

Though the Oracle docs have good coverage of the difference in licensed options, would you mind please posting the main areas that you have benefited from the EE edition?

Thanks,

TD
 
TekDude[sup]2[/sup],

I once asked an Oracle Technical Support representative to clearly and concisely explain the functional differences between Oracle Standard versus Oracle Enterprise editions.

His response was that Enterprise-Edition architecture supports employment of multiple CPUs (in parallel) to resolve a query whereas Standard Edition supports only single-threaded processing of a query.

So, if your machines are equipped with single CPUs only, then you would not notice a performance difference between Standard versus Enterprise editions; Conversely, if your machines have multiple CPUs, then the performance differences could be monumental.

[santa]Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
 
Thanks for asking this question tekdudedude as I am after the same type of information. We currently have three standard edition databases (six if you include development versions) and are looking to get another. The current databases are 80GB, 70GB, and 50GB. The new database is expected to be 150GB and the others will likely grow 20GB this year.

My question is does anyone know of any best practices regarding database size and when to move to enterprise edition? I know there is no license limit to the database size in standard edition, but I am more interested in what should be done rather than what can be done.

Whether anyone has that information or not, could you at least provide a. How big your database is and b. whether you are on Standard or Enterprise edition so I can get a feel for where most people draw the line?

Thanks for all replies.
 
I think it really depends on how your database is used. The server load should provide some insight as to if the standard edition is sufficient. Or maybe some stats. A large number of CPU waits probably means you need to upgrade. If you have none, its probably a waste of money.
 
I don't know, but I believe that partitioning is only available in the enterprise edition. If you're heading into large data volumes, this might become essential to maintain performance.

T

Grinding away at things Oracular
 
Thanks for these answers. Partitioning is one of the big reasons I want to move to enterprise edition, but there are many other reasons including online index rebuilds, flashback table, block level media recovery, Fine-Grained auditing, and several other things. We don't have a large number of CPU waits.

thargtheslayer, what do you mean by large data volumes? I know that enterprise edition features including the extra partitioning option would help with performance, but I am most interested in a general guideline for how big a database gets before these features become essential. We do a mix of online transaction processing and data warehouse functionality.
 
Light,

there's no definitive answer in Megabytes, (or even Terabytes) to your question. I would say that partitioning is never essential, unless it is needed to bring performance up to a level acceptable to the users.

As far as users are concerned, a system which takes too long to do their job is broken, and nigh on useless. Abysmal performance is as bad as a bug - some would argue it is a bug.

So, if your performance is poor due to data volumes (regardless of OLTP or DW activity) then partitioning is there to divide and conquer. However, it isn't a magic bullet, and if the underlying design of the tables, and/or the application is poor, this must be fixed first. Partitioning a disaster just makes a more complicated disaster.

If you deploy it by design, and prevent performance issues ever arising, then great. Use it well, and where needed. Don't expect it to automagically solve all your problems.

Regards

T

Grinding away at things Oracular
 
>> However, it [partitioning] isn't a magic bullet,

As Tom Kyte has said over and over partitioning does not = better performance. In many cases it may make things worse.

Partitioning should be thought of as making it easier in some environments to manage.

I had a multiple terabyte database, got rid of all the partitions (moved them to BFTS) and performance increased 30%.

In the ancient Oracle 7 days partitioning was also used to get around table\row contention (locking) but since then Oracle has completely rewritten their locking mechanism.

Everything can (and should) be proven. Prove the case for your environment.

TD
 
All good advice. I agree with these comments and the point of view from which they were written. I understand that enterprise edition is not a silver bullet, but I believe it would be extremely useful in our environment. I also know there is no definitive answer to the size question and that the answer would depend on a great number of factors. What I was looking for was a general statement; a guideline that ignores all the extreme cases and makes a lot of assumptions. In other words, something I can take to management to say "most databases over xGB are run on enterprise edition". This would of course be a minor piece of my presentation, but it seems that a discrete number representing a broad generalization of edition limits might have more impact than just saying that companies with requirements like ours use enterprise edition.

Now that I've said that, I'm beginning to reconsider my approach. Oh, well. Thanks for the input.
 
Light,

managers are strange beasts at the best of times. However, one annoying/endearing trait which most posess, is the love of nice figures, pie charts and graphs to make a business case.

I would therefore suggest that you take a look at the problem, and then see if any Enterprise features look as though they might help. Then ask the managers something like this:-

"Preliminary investigations indicate that we might benefit from using features only available in the enterprise edition, such as partitioning. I want authorisation to expend two man weeks of effort, to load a copy of our db onto an enterprise version, and carry out proof-of-concept tests to see if the anticipated gains are made.

During the trial, I will explore various enterprise-only features, and present information from precisely timed test cases, showing the performance gains (if any).
Whilst we are trialling the software, and not using it for commercial purposes, we are not obliged to pay a licence fee, so there are no licencing costs."

This is suitably simple for managers, and might get you somewhere.

What think ye o master of the light fantastic?

T

Grinding away at things Oracular
 
thargtheslayer is right on.

Find a feature(s) your company cannot live without. Another good place to cover is Security.

Companies\management are too quick to dismiss easier to manage as "soft dollars". Give them some hard security facts.

Also, there are many Disaster Recover options that are only available with the EE (Flashback, Streams, automated Data Guard, RMAN block recovery [yep only available if you have EE] etc.)

Another useful point is to ask them what their RTO (Recovery Time Objectives) are for data recovery. How long can the business survive if there is a hardware failure and you have no database. etc. ;-)

Good luck Light. Let us know of your success so we can learn from your experiences too. :)

TD

 
These are great ideas. Thanks thargtheslayer and tekdudedude. I'll see if I can carve out some time to do just as you suggest. It will be difficult to pin them down on recovery time objectives, but I may be able to give them some scenarios for comparison showing our current recovery times compared to those if we had enterprise edition.

Thanks for the help.
 
Perhaps you intelligent oracle guys can help me. Related to deciding on EE vs SE. To save a load of money can I run EE in the production system and SE for disaster recovery (dr) and dev? Will I be able to update the dr database, manually once per day, from the EE database? or will they both need to be EE. EG. dump a log file and some modified records from the EE system and ship them to the SE system. Isn't the engine and the database the same just the features around it different?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top